stderr
-
Posts
4 -
Joined
-
Last visited
Content Type
Profiles
Forums
Gallery
Downloads
Blogs
Events
Posts posted by stderr
-
-
10 часов назад, stderr сказал:
Спасибо, теперь работает так, как нужно - везде используется порт 5440. Вопрос решен.
Как оказалось после более тщательной проверки – вариант с udp-port-preserve неплохой и рабочий, но не идеальный. Опция пытается сохранять все порты в принципе, не учитывая проброшенное в настройках. Возможна (хотя и маловероятна, если ее не вызывают намеренно) такая не очень хорошая ситуация:
1) "Сервер" (условно) в локалке (пусть у него адрес 192.168.1.1) забиндился на свой «проброшенный» в Кинетике порт (который в нашем случае 5440) и начал ждать данные от внешнего хоста (пусть он живет по адресу 1.1.1.1:5440). Кинетик пока ничего об этом не знает – обмена данными ведь еще не было.
2) Какая-то другая машина из локалки (192.168.1.2) отправляет запрос на 1.1.1.1:5440. Кинетик, видя это, записывает себе в "таблицу", что все, приходящее снаружи от 1.1.1.1:5440, надо переадресовывать на 192.168.1.2:5440 (даже несмотря на то, что внешний порт 5440 в настройках проброшен на 192.168.1.1)
3.1) «Сервер» 192.168.1.1 пытается отправить данные на 1.1.1.1:5440 – но кинетик, видя, что «внешний» 5440 уже занят, перебрасывает данные на какой-то совершенно левый свой «внешний» порт.
3.2) При попытке отправки внешним хостом 1.1.1.1 данных на внешний порт 5440 Кинетика они заворачиваются Кинетиком на 192.168.1.2:5440 с полным игнором настроек проброса портов. Логика его поведения понятна, но вот правильна ли она? Ведь пользователь в настройках явно сказал, что абсолютно все, что приходит на порт 5440, он желает получать на своем «сервере» 192.168.1.1.
Хотелось бы как-то подправить и этот момент. Если пользователь сказал, что он хочет отправлять весь трафик с порта 5440 на машину 192.168.1.1, то этот порт хорошо было бы использовать только для передачи данных на 192.168.1.1:5440 и никуда иначе, и ничто кроме данных с 192.168.1.1:5440 больше не перенаправлялять на «внешний» порт 5440 (иными словами, чтобы при включенном пробросе порта в «таблице» Кинетика создавалась своеобразная вечноживущая «сессия», заворачивающая весь траффик с внешнего порта 5440 на 192.168.1.1:5440 и не допускающая использование этого «внешнего» порта кем-либо, кроме 192.168.1.1:5440).
То, что происходит сейчас, по сути является в некотором роде даже проблемой безопасности, ведь такое своеобразное поведение может быть использовано злоумышленником внутри локалки: захватывая проброшенный "внешний" порт путем отправки разного рода мусора он получает возможность как минимум препятствовать приему данных тем, кому они реально предназначались, а как максимум - вообще перехватывать эти данные.
-
31 минуту назад, r13 сказал:
@stderr попробуйте с командой cli
ip nat udp-port-preserve
Спасибо, теперь работает так, как нужно - везде используется порт 5440. Вопрос решен.
-
Имеем: Keenetic 2 с прошивкой 2.12.B.0.0-4, статический белый IP от провайдера и локальную сеть из нескольких машин за NAT’ом. Возникла необходимость использовать UDP между машиной в локальной сети (за NAT’ом кинетика) и хостами во внешней сети (также с «белыми» IP).
В связи с этим на кинетике были соответствующим образом проброшены порты:
После бинда UDP-сокета на порту 5440 (для примера) локальной машины начинаются странности:
- Если инициатором передачи данных выступает хост из «внешней» сети, то NAT ведет себя ожидаемым образом: пакет приходит на порт 5440 «белого» адреса Кинетика и переадресуется на порт 5440 машины в локальной сети. После чего ответные пакеты от машины локальной сети с «серого» порта 5440 успешно переправляются Кинетиком с «белого» порта 5440 на порт машины в глобальной сети. Сценарий отработал успешно и ожидаемо.
- Если инициатором передачи данных выступает хост из локальной сети, то порт отправителя преобразуется Кинетиком в нечто совершенно странное, что хорошо видно на стороне хоста в глобальной сети (например, он показывает в качестве порта отправителя принятого пакета 35004). Дальше – интереснее:
А) Если хост в глобальной сети отправляет ответ на «внешний» порт 5440 Кинетика (который должен пробрасываться), то до машины в локальной сети доходят данные с еще одним значением порта отправителя (1028, хотя локальная машина ожидает 5440 – ведь она отправляла данные туда)
Б) Если хост в глобальной сети в ответ отправляет данные на указанный в принятом пакете порт отправителя (35004 в примере), то они успешно доходят до локальной машины, и в порте отправителя, как это ни странно, показывается 5440. Но при отправлении данных на этот же порт с другого «белого» IP они до локальной машины просто не доходят.
Возникает ощущение, что NAT на Кинетике пытается использовать TCP’шную логику «сессий» для работы с UDP: если для исходящей дейтаграммы уже существует «сессия» для «серой» комбинации IP:порт, то при трансляции используется соответствующий «внешний» порт, если нет – то «внешний» порт выбирается случайным образом, при этом совершенно не учитывается, есть ли порт в таблице «переадресации» или нет.
P.S. Специально откатил прошивку Кинетика на последнюю «релизную» 2.06 и проверил поведение на ней – данного бага не наблюдается, проброшенный порт всегда остается неизменным, то есть хост во внешней сети видит портом отправителя «правильный» 5440.
Странная работа NAT c UDP
in 2.12
Posted
По сути да, не выпускать с проброшенных портов никого кроме тех, для кого эти порты пробрасывались, было бы наиболее логичным решением по моему мнению. Хотя, безусловно, я не знаю всех деталей текущей реализации, и у разработчиков вполне может оказаться свой взгляд на решение проблемы.