SNAT на неверный source-адрес udp-пакетов SIP после смены маршрута по-умолчанию на маршрутизаторе?
Имеется система-маршрутизатор (Debian current, 2.6.32-5-686) с двумя аплинками (оба Ethernet, без ppp и pppoe) и еще одним интерфейсом локальной сети, внутри которой есть сервер с pbx Asterisk.
Из аплинков один является основным, на него по-умолчанию ведет default route в основной таблице маршрутизации. Также на маршрутизаторе настроен source-routing для раздельного доступа по Linux Advanced Routing HowTo (чтобы ответные пакеты уходили туда же, откуда пришли запросы).
В данном режиме все работает как надо.
Кроме того, настроен самодельный мониторинг работоспособности аплинков (пинг одного внешнего адрес каждые 10 секунд, в случае недоступности адреса через умолчательный аплинк происходит удаление текущего default-маршрута, ip route flush cache, принудительное разрывание всех активных tcp-сессий в течение 3-х секунд средствами iptables и в конце установка маршрутом по-умолчанию резервного аплинка). При этом у всего, кроме Asterisk-а соединения быстро переподнимаются через нового аплинка.
!!! udp sip-пакеты от Asterisk-а (на регистрацию на вышестоящем sip-прокси) тоже начинают отправляться в новый интерфейс по-умолчанию, согласно правилам, НО - SNAT отрабатывает на старый адрес источника (в качестве исходящего устанавливается адрес интерфейса первого аплинка). После чего, соответственно, ничего не работает, т.к. первый же маршрутизатор провайдера блокирует пакеты с IP-адресом источника, не принадлежащим его подсетям. Такая ситуация происходит до ребута нашего маршрутизатора. Там нат начинает снова работать как надо, но до смены default-маршрута назад на провайдера по-умолчанию, после этого SNAT sip-пакетов происходит по инерции на адрес резервного провайдера.
Прямо не знаю, куда копать и что смотреть, просьба к Хабрачеловекам посильно помочь :-)
Так как не показано правило SNAT, могу догадываться что вам может помочь добавление в ваш «мониторинг работоспособности аплинков» переписывание правила SNAT при падении аплинка, на выход через другой интерфейс.
Думаю, так происходит от того, что NAT работает со старой, уже сформированной NAT-таблицей. После перезагрузки роутера таблица обнуляется, формируется заново — и всё отлично начинает работать.
Выход — после переключения на резерв сбросить NAT-таблицу.
Не знаю, как это сделать в linux, но думаю решаемо перезапуском демона iptables.
Ответ не претендует на истинность, но всё таки проверьте. Например посмотрите таблицу NAT до падения линка, после падения и после перезагрузки.
Удачи! Если найдёте решение — отпишитесь где-ниюбудь ;)
Я вижу тут несколько вариантов:
1. Если я правильно понял, то проблема только с астериском, т.е. остальные приложения отправляют пакеты нормально? Возможно проблема именно в астериске (там есть тонкие моменты в процедуре отправки инвайта в котором указывается внешний ip адрес), а что говорит tcpdump есть там что то интересное?
2. Если прописывать только одно правило SNAT при изменении дефолтного шлюза, вы сможете увидеть действительно отправляемые пакеты попадают не в то правило SNAT.
Проблема очень интересная, если будет желание напишите мне в ПМ или на jabber постараюсь помочь.
Сложный
