LINUX.ORG.RU
ФорумAdmin

SNAT на неверный source-адрес udp-пакетов SIP после смены маршрута по-умолчанию на маршрутизаторе


0

1

Имеется система-маршрутизатор (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-пакетов происходит по инерции на адрес резервного провайдера.


Потому, что connection tracking.

no-dashi ★★★★★
()

Проще всего поставить SIP-прокси и сказать астериску использовать его.

no-dashi ★★★★★
()

При смене маршрута и SNAT-правила удаляйте запись (записи) о SIP-потоках из таблицы командой conntrack.

mky ★★★★★
()
Ответ на: комментарий от kruft

эмс, а разве у UDP-пакетов есть трекинг соединений ?

Да.

no-dashi ★★★★★
()
Ответ на: комментарий от kruft

Да.. только нету понятия состояния соединения ESTABLISHED

Tok ★★
()
Ответ на: комментарий от kruft

> эмс, а разве у UDP-пакетов есть трекинг соединений ?

Нет. Но и iptables, и pf, и может быть ещё кто-то для удобства ведут себя так, и настраивать их можно так, как будто он есть.

dj_slack
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.