Провайдер режет TCP/UDP сессии через 240 сек неактивности, что делать?

Question

[Winseven]

Добрый день!
Ситуация такая: подключаюсь к серверу по SSH и если ничего не делать, то через 240 сек соединение зависает, хотя с обоих сторон состояние "ESTABLISHED". Если подключить услугу "Выделенный IP", то такой проблемы нет. Я считаю, что NAT провайдера чистит NAT-таблицу от неактивных соединений через 240 сек, отсюда и потеря связи. Техподдержка провайдера так не считает, отвечает:
- Ваша заявка обработана, было рекомендовано изменить keepalive interval в настройках ssh клиента.
- С нашей стороны на текущий момент ни каких ограничений не видим.

Уже второй месяц пытаюсь найти правду - где теряются мои TCP/UDP-сессии... даже ролик записал на примере NetCat - https://youtu.be/k4B77s4detk

На мой взгляд это нарушение "RFC793 Протокол управления пересылкой - TCP", если FIN пакета не было, то сессия должна быть активна.
Проверял через мобильный интернет - проблемы с потерей связи нет.
Может у кого-нибудь есть опыт решения данной проблемы, кроме как подключить услугу "Выделенный IP", использовать VPN или прописывать повсюду "keepalive interval"?

Comments

[Valentin Barbolin]

пора переходить на mosh.

[shurshur]

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

Однако в случае с stateful nat по дороге всё совсем не так. Каждый коннект - это нагрузка на маршрутизаторы. А если, например, оба хоста просто помрут без прежупреждения, вечно хранить их коннекты, что ли? Помимо того, что nat-таблицы всегда будут пухнуть, в такой ситуации возможна очень простая атака на маршрутизаторы с nat путём открытия множества незакрываемых коннектов к случайным сайтам.

Поэтому требование использовать keepalive закономерно и полностью законно. Если не нравится, то всегда можно перейти stateless tcp без nat с личным выделенным IP.

До кучи есть множество других нюансов. Например, при использовании SO_LINGER_TIME=0 при закрытии коннекта посылается не FIN, а RST, а практика показывает, что некоторые несознательные админы RST-пакеты тупо режут, пытаясь так решать некоторые свои проблемы. В итоге пользователи с опцией SO_LINGER_TIME=0 могут создавать висящие коннекты совершенно неосознанно.

[Winseven]

shurshur, Спасибо! Буду использовать выделенный IP.

[Денис Юрьев]

keepalive то все таки настроили?

[Winseven]

Денис Юрьев, Нет, я подключил выделенный IP, так проще...

Answer 1

[Владимир Дубровин]

В любой NAT/PAT таблице всегда есть таймаут, иначе если бы оба конца соединения отвалились из-за сетевых проблем или из-за ребута или плохо настроенных фаерволов, запись оставалась бы в таблице навечно. В UDP вообще нет ни одного механизма удаления записи из NAT/PAT кроме таймаута.

С одной стороны, ваш провайдер прав - в любом случае при раборе через NAT/PAT необходимо настроить TCP KEEPALIVE, он настраивается в любом ssh-клиенте, например https://songhuiming.github.io/pages/2019/02/28/how... и это единственный гарантированный способ решения вашей проблемы.

С другой стороны, 240 секунд очень маленький таймаут (обычно используется время порядка 10 минут для UDP и порядка часа для TCP) а TCP KEEPALIVE умеют слать не все клиенты, поэтому стоит продолжить ругаться с техподдержкой чтобы таймаут или размер таблицы или диапазон NAT-портов увеличили дo разумных значений.

Comments

[Winseven]

Спасибо, продолжу)

Answer 2

[Армянское Радио]

Висящие сессии TCP и UDP вкусно кушают провайдеру порты NAT (видимо, он совсем мелкий и местечковый), так что ему надо как-то выкручиваться.

Никакого RFC он не нарушает - это Интернет, отрыв соединения является нормой.

Что делать - настройте KeepAlive, или примените autossh, он постоянно шлет байтики в дополнительном соединении

Comments

[Exe Onid]

провайдер вам ничего не обещал... провайдер гарантирует работу услуги до своего пограничного шлюза. Дальше не проблемы провайдера. Вы договор и соглашение читал?

Answer 3

[pfg21]

Использовать mosh
он использует для связи UDP-посылки и не завязан на поддержание tcp-канала.
точнее tcp-канал нужен только в начале чтобы простучаться на сервер через ssh и запустить прогу слушать порт.
обещают что mosh выдерживает даже переключение "интернет-канала" c wifi на сотовый канал и т.д.

Answer 4

[Кот Абсолютный]

Если подключить услугу "Выделенный IP", то такой проблемы нет

Уже второй месяц пытаюсь найти правду

Услуга статического IP стоит фантастически дорого?

Comments

[Winseven]

Так и сделал, подключил статику...

Answer 5

[Exe Onid]

очень странные пожелания от отвечающих...
делать дебаг на основе слов и предположений... очень инженерно (нет)
почему никто не предложил снять дамп сессии и просто тупо посмотреть...
или как логируется происходящее на сервере (или что там у вас)?
строить догадки на основе предположений