SIP через NAT (Странно себя ведёт при смене маршрута...)

[BlizZz]

Наблюдал сегодня очень странное поведение NAT.
Вообщем, имеется VoIP сервер на базе Asterisk, который выходит в интернет через NAT.
На шлюзе 2 выхода в интернет: eth1 и tap0.
Проблема заключается в том, что когда на шлюзе меняется маршрут например с eth1 на tap0, пакеты всё равно продолжают идти по старому маршруту через eth1. Причём только SIP, пинги и traceroute, например, идут уже по новому маршруту через tap0, как и положено.
То есть, смотрю tcpdump'ом на шлюзе, а SIP пакеты при маскарадинге получают внешний IP от интерфейса eth1 вместо tap0.

Пробовал и рестартовать SIP на астериске и перезапускать его. Помогает только перезагрузка шлюза.

Кто-нибудь знает как можно объяснить данный феномен?

[BlizZz]

Вот случайно наткнулся на статейку http://www.voip-info.org/wiki-IAX.
Похоже что это ошибка ядра при маскарадинге UDP трафика.

[sash-kan]

imho, дело тут не в nat, и уж ни про какой «баг ядра» и речи нет.
а дело в том, _как_ работает маршрутизация в ядре linux.
afaik, «решение о маршрутизации» не принимается для _каждого_ отдельного пакета. это было бы слишком накладно.
опять-таки, afaik, ядро держит некий «кэш решений о маршрутизации». как я пониаю, в кэше сохраняется такая информация как srcip, dstip, наверно, еще srcport, dstport, и, возможно, еще что-то.
когда-то я тоже сталкивался с последствиями этого кэширования при динамической смене маршрутов. не помню уже как именно решил. вроде бы, как-то ядру можно скомандовать очистить этот кэш. сейчас, к сожалению, не располагаю ни временем, ни желанием повторять те поиски. надеюсь, сможете найти сами

[BlizZz]

imho, дело тут не в nat, и уж ни про какой «баг ядра» и речи нет.
а дело в том, _как_ работает маршрутизация в ядре linux.
afaik, «решение о маршрутизации» не принимается для _каждого_ отдельного пакета. это было бы слишком накладно.

Собственно к маршрутизации у меня претензий никаких и нет.
Повторил недавно этот эксперимент.
Что имеем: сначала UDP пакеты маскарадятся на один интерфейс tap0 и получают внешний IP от него (10.8.0.1).

Код: Выделить всё

[0:0] -A POSTROUTING -s 192.168.1.0/24 -o tap0 -j MASQUERADE
 [0:0] -A POSTROUTING -s 192.168.1.100 -o eth1 -j SNAT --to-source 217.XXX.XXX.XXX

Далее, переключаю маршрут на второй интерфейс eth1. При этом, пакеты маршрутизируются правильно в eth1, но внешний IP получают от tap0, т.е. в интернет уходят пакеты с src ip = 10.8.0.1 и режуться на первом же шлюзе.
То есть баг именно в маскарадинге.

В вышеприведенной статье описывалось, что это можно решить указав явно SNAT, но в моем случае это не помогло
Единственное решение, которое я нашел, это временно прекратить эту UDP сессию, после этого все маскарадится нормально.

опять-таки, afaik, ядро держит некий «кэш решений о маршрутизации». как я пониаю, в кэше сохраняется такая информация как srcip, dstip, наверно, еще srcport, dstport, и, возможно, еще что-то.

Скорее всего так и есть, только поведение то всё-равно не корректное, верно? Если маршруты поменялись, то можно было бы и кэш SNAT'а обновить.

когда-то я тоже сталкивался с последствиями этого кэширования при динамической смене маршрутов. не помню уже как именно решил. вроде бы, как-то ядру можно скомандовать очистить этот кэш. сейчас, к сожалению, не располагаю ни временем, ни желанием повторять те поиски. надеюсь, сможете найти сами

Спасибо, попробую поискать.