Как узнать, что мое TCP-соединение защищено от брандмауэров /NAT?

Находясь в облаке Azure, я обнаружил, что брандмауэры там часто разрывают соединения между веб-сервером и базой данных. В основном, когда была некоторая бездеятельность, я думаю что-то между 5 и 10 минутами. Поэтому я провел небольшое исследование и обнаружил, что это, похоже, общая проблема.

Проблема кажется в основном разрешимой, если заставить некоторых поддерживать жизнь. (1) (2) (3)

Таким образом, все сводится к тому, как брандмауэры обрабатывают TCP-соединения:

Когда вы находитесь за прокси-сервером NAT или межсетевым экраном, это очень распространенная проблема - без причины отключаться. Такое поведение вызвано процедурами отслеживания соединений, реализованными в прокси-серверах и брандмауэрах, которые отслеживают все соединения, проходящие через них. Из-за физических ограничений этих машин они могут хранить только ограниченное количество соединений в своей памяти. Наиболее распространенная и логичная политика заключается в том, чтобы сохранять новейшие соединения и сначала отбрасывать старые и неактивные соединения.

(из TCP Keepalive HOWTO)

Означает ли это, что брандмауэр /NAT может сбрасывать TCP-соединения в любое время? Как после 2 секунд бездействия? Или есть что-то, что мешает нам опасаться, что ни одно соединение не защищено от брандмауэра?

1 ответ

Решение

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

На практике это именно то, что вы цитировали. Чтобы предотвратить это, вы должны убедиться, что на линии есть активность. Например, когда у меня есть сеансы SSH, я запускаю в них сеанс tmux с часами, поэтому каждую минуту происходит некоторая активность.

Кроме того, я склонен использовать ПК с Linux в качестве маршрутизаторов и брандмауэров, поскольку у них достаточно памяти, чтобы никогда не прерывать неактивное соединение. В основном это проблема аппаратного обеспечения потребительского уровня.

Другие вопросы по тегам