Имеется указанный модем в роли маршрутизатора (прошивка RU_1.24). Имеется специализированное устройство (прибор охраны), работающий с внешним сервером по UDP. Если происходит разъединение и последующее восстановление связи с провайдером (с присвоением нового динамического IP адреса на ppp_0_1_32_1 интерфейсе), то UDP данные с устройства больше не в состоянии проходить через модем до перезагрузки модема.

С целью выявления проблемы с помощью iptables в модеме были добавлены два правила:



До разъединения пакеты проходят через оба правила. После разъединения и повторного соединения с провайдером, прохождение пакетов фиксируется только первым правилом.

Дальнейший анализ выявил, что запись в файле /proc/net/ip_conntrack модема, описывающая связь устройства с внешним сервером, после смены на ppp_0_1_32_1 интерфейсе модема внешнего IP адреса не обновляется. В этом файле продолжает оставаться запись с выставленным флагом [ASSURED], но со старым внешним IP адресом модема.

Выглядит это так (лишнее заменено '...', IP адреса заменены вымышленными):

Устройство: 192.168.1.5
Сервер: 82.207.130.120
Интерфейс ppp_0_1_32_1 модема: 93.74.111.111

Запись в /proc/net/ip_conntrack:


Произошло переподключение, теперь интерфейс ppp_0_1_32_1 модема получил адрес 93.74.222.222. Смотрим в /proc/net/ip_conntrack, а там запись осталась прежней, с адресом модема dst=93.74.111.111:


Судя по всему, это и препятствует прохождению UDP трафика от нашего устройства через модем. Стоит заметить, что TCP сессии в этой ситуации продолжают работать. Пробовали настроить DNAT переадресующий на устройство, но результатов это не дало.

Как решить данную проблему? Очень не хотелось бы заносить ваши модемы в список несовместимых с нашими устройствами для наших клиентов (к примеру, модемы ZyXEL работают в данной ситуации без нареканий).

наверно, достаточно будет пробросить нужный udp-порт в Virtual Servers, на внутренний адрес устройства (конечно, если номер udp-порта фиксированный)

Пробовали, не работает.

Из приведенного описания видно, что инициатором соединения является хост внутри сети (охранное устройство, 192.168.1.5), так что проброс UDP из внешней сети на 192.168.1.5 не приведёт к желаемому результату хотя бы потому, что сам сервер (82.207.130.120) не знает нового динамического IP клиента.

По-хорошему, при смене внешнего IP таблица NAT (/proc/net/ip_conntrack) должна очищаться, ведь на некоторое время PPP-интерфейс уходит (должен уходить) в состояние DOWN.

Не вдаваясь в глубокий анализ, считаю, что после смены IP у клиента (с 93.74.111.111 на 93.74.222.222) сервер продолжает высылать UDP на старый адрес 93.74.111.111 (подозреваю, что никаких подтверждений от клиента он при этом не ожидает). И продолжаться это будет до тех пор, пока сам клиент не заявит о себе с нового адреса. При этом возможны 2 исхода: 1й - сервер принимает клиента с его нового IP (93.74.222.222); 2й - сервер отвергает клиента, аргументируя тем, что "ты у меня уже залогинился с IP 93.74.111.111".

Ваша система предусматривает механизм поддержки активности соединения между сервером и клиентом по принципу keep-alive? Если "да", то его было бы неплохо включить.

Далее, строка

говорит о том, что в обратную сторону (от сервера к клиенту) ожидаются пакеты "src=82.207.130.120 dst=93.74.111.111", но приходить будут после смены внешнего IP "src=82.207.130.120 dst=93.74.222.222", так что срабатывать правило не будет. И удалено оно будет из таблицы NAT по причине отсутствия активности через 587 секунд.

Кстати, если инициатором соединения является хост внутри сети (192.168.1.5), то могу предложить в настройках WAN установить птицу в "Dial on demand (with idle timeout timer)" (если у вас PPPoE или PPPoA). Что ожидается? После принудительного разрыва PPP-сессии, например, со стороны провайдера, маршрутизатор сам не пытается восстановить PPP-соединение, а ждёт инициативы изнутри сети (хост 192.168.1.5 хочет связаться с хостом 82.207.130.120). Вполне возможно, что за время, пока PPP-соединение будет неактивно, произойдёт очистка таблицы NAT. В этом случае может понадобиться увеличение таймаута в настройках клиента (192.168.1.5) на установку связи с сервером. Это больше похоже на пляску с бубном, но тем не менее, попробуйте.

Как вариант 2 - попробуйте более ранние версии прошивок.

Алгоритм обмена нашего устройства с сервером построен так, что динамическое изменение IP адреса на стороне устройства не препятствует дальнейшей работе. То есть, как только приходит пакет от устройства с новым адресом источника, дальнейший обмен происходит уже с учетом этого нового адреса. Алгоритм обкатан, поэтому проблема не в этом.

Проблема в том, что после переустановки соединения с провайдером, модем больше не пропускает через сербя UDP пакеты от устройства, а просто их отбрасывает. Следовательно сервер уже ничего не получает от устройства и не может сам начать обмен, так как не знает нового адреса за которым теперь находится устройство.



Все так, но с одним "но". Активность присутствует, так как устройство продолжает попытки отправки данных. Но пакеты через модем не проходят, вероятно как раз по причине того, что в этом правиле dst=93.74.111.111 (старый адрес модема). А так как присутствует активность, то и запись не будет удалена до перезагрузки модема. Даже если бы она была удалена через 587 секунд, это долго с точки зрения охраны.



Увы, скорее всего не применимо. Даже если увеличить таймаут на устройстве, через тот же самый модем может осуществлятся другая сетевая активность (серфинг, и т.п.), следовательно получим такой же результат.



Изначально пробовали с заводской прошивкой 1.00, сейчас 1.24. Почему-то сомневаютсь, что в какой нибудь промежуточной версии это исправлено

сбросить таблицу возможности нет, если только не добавить в прошивку утилиту conntrack
можно попробовать снизить таймаут ниже интервала, с которым работает та программа, типа:
echo "10" > /proc/sys/net/ipv4/netfilter/ip_conntrack_udp_timeout

Я плохо знаком с прошивками D-Link, поэтому у меня следующий вопрос. Можно ли прописать данную строчку в скрипты загрузки и как? Или для этого потребуется самому модифицировать прошивку?

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

к сожалению, для этого придётся модифицировать прошивку
по умолчанию интервал 30сек, так что если бы то устройство работало с большей паузой между пакетами, проблем бы не было
других идей нет

Похоже, в данном случае отрабатывает

а не

нет
на udp-сессии работают 2 таймаута: ip_conntrack_udp_timeout(=30) и ip_conntrack_udp_timeout_stream(=180)

кстати, так в принципе можно и сбросить таблицу:

Согласен, но почему же тогда таймаут ближе к 600 ?

udp 17 587 src=192.168.1.5 dst=82.207.130.120 ...

Кстати, ходят слухи, что иногда в похожей ситуации помогает снять/установить "Advanced Setup" --> "NAT" --> "ALG" --> "SIP Enabled". Это по мотивам http://forum.ixbt.com/topic.cgi?id=88:3022#9

Не помогло.

Написал в адрес техподдержки. Они написали в ответ, что "модели DSL-2600/2640 имеют некоторые особенности в работе UDP/NAT", однако сроков выхода исправлений не уточнили . Порекомедовали попробовать использовать DSL-25xx или DSL-2650, при этом не гарантируя отстутствия в них таких же проблем, лишь заметив, что "данных особенностей там с большой вероятностью нет".

DAurum и ergot, спасибо за попытку оказать помощь.