При использовании NAT на устройствах, имеющих к одному назначению несколько маршрутов (основной и резервные) через разные интерфейсы, необходимо иметь следующую особенность работы NAT в ОС Linux. После того, как поток идентифицирован и для него создана запись NAT, эта запись функционирует независимо от маршрутизации и, соответственно, от текущего выходного интерфейса и его IP-адреса. Если устройство переходит, например, с основного канала Ethernet на резервное сотовое соединение, или наоборот, то процедура NAT не меняется и пакеты начинают уходить в новый интерфейс с адресами, NAT-ированными по-старому, уже не адекватно реальности. В результате пакеты не доходят до назначения, или ответные пакеты не могут вернуться на устройство, и соединение теряется. Например, единожды запущенный ping перестаёт проходить.

Алгоритм работы NAT в ОС Linux предполагает, что эта потеря связи будет обнаружена средствами прикладного уровня (или туннеля — keepalive, echo request/reply, dead peer detection и т.п.) или вручную, после чего прикладное соединение будет переустановлено, идентифицировано механизмом NAT как новый поток, и для него будет создана новая запись NAT. Таким образом, поведение сети с точки зрения её конечной функции — передачи данных — определяется в данном случае особенностями и алгоритмами работы каждого конкретного приложения в отдельности.

Поскольку в первую очередь для проверки доступности узлов сети используется ping, то необходимо особо обратить внимание на его работу в вышеописанной ситуации. NAT идентифицирует пакеты ICMP Echo Request/Echo Reply как поток, основываясь на идентификаторе ping-а (ICMP ID), которое утилита ping вставляет в пакет. В одном запуске утилиты идентификатор во всех пакетах одинаковый. Однако алгоритм его назначения может быть разным в разных реализациях ping, что приводит к существенно различному поведению:

• Реализации ping для Linux при каждом новом запуске утилиты используют новый идентификатор. Таким образом, если через устройство NSG проходит ping с ПК или иного хоста под управлением Linux на третье устройство, то после смены канала связи он перестаёт проходить. Необходимо остановить его и запустить заново. Новые пакеты пойдут с новым идентификатором, механизм NAT идентифицирует их как новый поток, и ping будет успешно проходить.
• Реализация ping в Windows, наоборот, использует один и тот же идентификатор и старается сохранить его до последней возможности. Перезапуск утилиты ping и даже переоткрытие консольного окна не гарантируют изменения идентификатора (хотя и приводят к этому в отдельных случаях, вероятно, по совокупности с расположением созвездий, курсом доллара США и какими-то иными неучтёнными факторами); единственным способом изменить идентификатор пинга в Windows, известным автору сего руководства, является перезагрузка Windows.

Как можно видеть, в данном случае ping не является достоверным показателем работоспособности сети и судить об успешности переходов на резервный канал и обратно следует исключительно по работе конкретных приложений.

При переключении каналов связи рекомендуется задействовать утилиту conntrack (в скриптах netping или обработчика событий) для полной очистки таблицы NAT. В этом случае для следующего пакета будет создана новая запись и либо работа продолжится (если это допускается приложением — например, ping), либо приложение получит ответ, что пакет принадлежит к несуществующей сессии (с нового IP-адреса и т.п.) и сможет инициализировать новую сессию немедленно, а не по тайм-ауту. Пример:

services
: netping
: : route_swap
........................
: : : failure-script = "ip route del default via 98.76.54.29; conntrack -F;"
: : : restore-script = "ip route add default via 98.76.54.29; conntrack -F;"

Подробно о параметрах данной утилиты см. conntrack --help или соответствующую man page.

Обратно в узел .ip.nat...