форумы  помощь  поиск  регистрация  майллист  ВХОД  слежка

Вариант для распечатки		Архивированная нить - только для чтения!  Пред. тема | След. тема
Форумы OpenNET: Виртуальная конференция (Public)
Изначальное сообщение		[Проследить за развитием треда]

"Опять гребаный FreeS/WAN"
Сообщение от shaman on 02-Июл-03, 20:37  (MSK)
Hi. Господа, прошу помощи. Уже мозги закипели. Итак: есть 2 linux-сервера, между ними шифрованный канал freeswan. До недавних пор все работало, потом вдруг канал стал работать только в одну сторону, т.е. из локальной сети 1 я пингую лок. сеть 2, а наоборот - нет. Вчера канал перестал работать вообще. Начал смотреть пакеты на интерфейсах и обнаружил непонятную вещь. При заргузке сервера автоматом запускается firewall, пинги наружу идут, а при пинге лок. сети 2 на вирт. интерфейсе ipsec0  наблюдаются пакеты с внешним ip. НАТ осуществляется следующим правилом: $IPTABLES -t nat -A POSTROUTING -s $LAN_1 -j SNAT --to-source $IPADDR Вывод iptables -t nat -L Chain POSTROUTING (policy ACCEPT) target     prot opt source               destination SNAT       all  --  192.168.99.0/24      anywhere        to: $IPADDR Если после этого принудительно очистить таблицу nat и подгрузить вручную _тот_ _же_ скрипт фийрволла, то и пинги наружу идут, и на ipsec0 пакеты с нормальным внутренним адресом. При старте freeswan в логах запись: jul  2 20:09:41 mail ipsec_setup: ...FreeS/WAN IPsec started Однако уже через минуту: ipsec__plutorun: 104 "moscow-istra" #1: STATE_MAIN_I1: initiate ipsec__plutorun: 106 "moscow-istra" #1: STATE_MAIN_I2: sent MI2, expecting MR2 ipsec__plutorun: 108 "moscow-istra" #1: STATE_MAIN_I3: sent MI3, expecting MR3 ipsec__plutorun: 010 "moscow-istra" #1: STATE_MAIN_I3: retransmission; will wait 20s for response ipsec__plutorun: 003 "moscow-istra" #1: discarding duplicate packet; already STATE_MAIN_I3 ipsec__plutorun: 010 "moscow-istra" #1: STATE_MAIN_I3: retransmission; will wait 40s for response ipsec__plutorun: 003 "moscow-istra" #1: discarding duplicate packet; already STATE_MAIN_I3 ipsec__plutorun: 031 "moscow-istra" #1: max number of retransmissions (2) reached STATE_MAIN_I3.  Possible authentication failure: no acceptable response to our first encrypted message ipsec__plutorun: 000 "moscow-istra" #1: starting keying attempt 2 of an unlimited number, but releasing whack ipsec__plutorun: ...could not start conn "moscow-istra" Видно, что не может обменяться ключами. Переустановил freeswan, взял другое ядро, играл с поддержкой iptables в ядре - один хрен. Принимаются ЛЮБЫЕ предложения.
	Рекомендовать в FAQ | Cообщить модератору | Наверх

Индекс форумов | Темы | Пред. тема | След. тема

Сообщения по теме

1. "Опять гребаный FreeS/WAN"
Сообщение от Mikhail on 03-Июл-03, 10:03  (MSK)
Что именно изменилось, когда перестало работать (какие настройки, чего, на какой машине etc.)?
	Рекомендовать в FAQ | Cообщить модератору | Наверх

2. "Опять гребаный FreeS/WAN"
Сообщение от shaman on 03-Июл-03, 10:04  (MSK)
Обновил freeswan до 1.99  - канал устанавливается, но с файрволлом проблема осталась. Итак, что я имею: цепочки INPUT и OUTPUT - работают. Вопрос по цепочке FORWARD. Выход в инет осуществляется при помощи: $IPTABLES -t nat -A POSTROUTING -s $LAN_1 -j SNAT --to-source $IPADDR ДО этого правила есть правила для freeswan: $IPTABLES -A FORWARD -p all -s 192.168.99.0/24 -d 192.168.0.0/24 -j ACCEPT $IPTABLES -A FORWARD -p all -s 192.168.0.0/24 -d 192.168.99.0/24 -j ACCEPT но опять же на интерфейсе ipsec0 пакеты с внешним адресом. Т.е. похоже, что все соединения принудительно маскируются. Если не сложно, дайте рабочие настройки с linux-шлюза! Или ткните носом, где не прав!
	Рекомендовать в FAQ | Cообщить модератору | Наверх

	3. "Опять гребаный FreeS/WAN"
	Сообщение от Mikhail on 03-Июл-03, 10:44  (MSK)
	Это разные таблицы, одна другую не исключает... Эти пакеты просто не нужно snat'ить? $IPTABLES -t nat -A POSTROUTING -s 192.168.99.0/24 -d 192.168.0.0/24 -j SNAT --to-source 192.168.99.0-192.168.99.254 $IPTABLES -t nat -A POSTROUTING -s $LAN_1 -j SNAT --to-source $IPADDR - может, так попробовать?
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	4. "Опять гребаный FreeS/WAN"
	Сообщение от shaman on 03-Июл-03, 10:53  (MSK)
	>Это разные таблицы, одна другую не исключает... Эти пакеты просто не нужно >snat'ить? >$IPTABLES -t nat -A POSTROUTING -s 192.168.99.0/24 -d 192.168.0.0/24 -j SNAT --to-source >192.168.99.0-192.168.99.254 >$IPTABLES -t nat -A POSTROUTING -s $LAN_1 -j SNAT --to-source $IPADDR >- может, так попробовать? Да! Все заработало. Большое спасибо!
		Рекомендовать в FAQ | Cообщить модератору | Наверх

	5. "Опять гребаный FreeS/WAN"
	Сообщение от Mikhail on 03-Июл-03, 11:00  (MSK)
	Точнее, конечно, нужно просто из $IPTABLES -t nat -A POSTROUTING -s $LAN_1 -j SNAT --to-source $IPADDR исключить нужный диапазон, вроде $IPTABLES -t nat -A POSTROUTING -s $LAN_1 -d ! 192.168.0.0/24 -j SNAT --to-source $IPADDR - так более по-русски ;-)
		Рекомендовать в FAQ | Cообщить модератору | Наверх

Удалить

Индекс форумов | Темы | Пред. тема | След. тема

Пожалуйста, прежде чем написать сообщение, ознакомьтесь с данными рекомендациями.