Вопрос или проблема
Я только что посмотрел видео, в котором объясняется UDP holepunching.
В этом видео объясняются некоторые процессы, которые создают записи в таблице NAT маршрутизатора.
Это заставило меня задуматься. Какой процесс или событие может привести к удалению записи из таблицы NAT маршрутизатора?
- Эти записи истекают через определенное время? (TTL)
- Типичный пакет “соединение закрыто” обычно приводит к удалению записи из таблицы NAT? (Не помню, есть ли у UDP такое сообщение. У TCP есть.)
- Какая-то другая причина?
Легко понять, что создаст запись в таблице NAT – это соединение от исходного IP и порта, начинающее передавать данные на удаленный сервер через NAT-маршрутизатор.
Не так очевидно, что удаляет эти записи из таблицы NAT. Предположительно, они не существуют вечно.
Разные реализации NAT имеют разное поведение, но в общем случае они отслеживают состояние соединения для транспортных протоколов, которые это позволяют (TCP, SCTP), и используют короткие тайм-ауты для остальных. (UDP не делает этого; это протокол без соединения – просто уровень мультиплексирования поверх IP.)
(На самом деле, вы найдете много протоколов, имеющих функцию “keep-alive” или “периодический пинг”, в наши дни они не столько предназначены для обнаружения отсутствия партнера, сколько для предотвращения забывания состояния бережливыми NAT- шлюзами после двухминутного тайм-аута.)
Например, Linux ‘conntrack’ – используемый iptables/nftables для фильтрации по состоянию и NAT – имеет встроенную поддержку отслеживания состояний TCP в соответствии с пакетами SYN/FIN/RST, которые он наблюдает (и состояния SCTP, но не все шлюзы включают этот модуль). Он использует значения тайм-аутов, определенные через sysctl net.netfilter, такие как:
# Тайм-аут для потоков, созданных другими необозначенными протоколами (например, GRE)
net.netfilter.nf_conntrack_generic_timeout = 600
# Тайм-аут для подтвержденных TCP-потоков, находящихся в состоянии
ESTABLISHED
# (Большинство шлюзов уменьшают его до нескольких минут)
net.netfilter.nf_conntrack_tcp_timeout_established = 432000
# Тайм-аут для неподтвержденных TCP-потоков, где была замечена только SYN
net.netfilter.nf_conntrack_tcp_timeout_syn_sent = 120
# Тайм-аут для неподтвержденных UDP-потоков, где были замечены пакеты только в одном направлении
net.netfilter.nf_conntrack_udp_timeout = 30
# Тайм-аут для «подтвержденных» UDP-потоков, где был замечен двунаправленный обмен пакетами
net.netfilter.nf_conntrack_udp_timeout_stream = 120
Для дешевых шлюзов на базе Linux (например, вашего домашнего маршрутизатора) обычно не включается модуль SCTP, в этом случае он будет отслеживаться как поток generic IP-протокола xxxx. QUIC, конечно, был разработан, чтобы намеренно скрывать информацию о своем состоянии, чтобы его можно было отслеживать только как обычный поток UDP – но большинство NAT даже не пытаются отслеживать протоколы передачи данных, основанные на соединении, если они передаются по UDP (например, SCTP-over-UDP также рассматривается как обычный поток UDP).
Записи состояния Conntrack также могут быть удалены вручную, например, с помощью conntrack -F для очистки всей таблицы. Если ваше WAN-соединение перезапущено по какой-либо причине, шлюз часто сбрасывает все NAT-состояния, потому что они были связаны с внешним IP-адресом, который у вас больше нет.
Ответ или решение
Процессы, которые могут привести к удалению записи из таблицы NAT маршрутизатора, представляют собой сложное сочетание временных ограничений, протокольных сообщений и вмешательства системного администратора. Рассмотрим этот вопрос в контексте, учитывая особенности протоколов TCP и UDP, а также общие принципы работы NAT.
Теория
NAT (Network Address Translation) — это механизм, используемый маршрутизаторами для преобразования IP-адресов и портов из локальной сети в один или несколько публичных IP-адресов. Это позволяет множеству устройств в частной сети использовать один внешний IP для доступа к Интернету. Как правило, NAT отслеживает активные сессии и создает записи в своей таблице, чтобы корректно перенаправлять входящие и исходящие пакеты.
Для протокола TCP, который является соединенческим, NAT использует состояние соединения, чтобы управлять записями. TCP предусматривает явные сигналы начала (SYN) и завершения (FIN, RST) соединения, что упрощает управление записями в таблице NAT. После получения пакета FIN или RST маршрутизатор может удалить соответствующую запись из таблицы NAT, поскольку соединение завершилось.
UDP, напротив, является бессоединительным протоколом, который не предусматривает установление и завершение соединений. Вместо явных сигналов UDP-сессии управляются с помощью механизмов временных ограничений. Записи в таблице NAT для UDP обычно удаляются после истечения заранее определенного времени тайм-аута, если активность в конкретном потоке данных не наблюдается.
Пример
Возьмем для примера реализацию, которая часто используется в Linux-системах — conntrack. Это инструмент, который управляет состояниями сетевых соединений в рамках iptables или nftables. Конфигурация conntrack определяет тайм-ауты для различных протоколов:
- Для неподтвержденных UDP-потоков, где пакеты были заметны только в одном направлении, тайм-аут составляет 30 секунд.
- Для подтвержденных UDP-потоков, где был обмен пакетами в обоих направлениях, тайм-аут составляет 120 секунд.
Эта конфигурация позволяет conntrack автоматически удалять записи для UDP, если в течение определенного времени не наблюдается никакой сетевой активности.
Применение
Для управления и настройки времени жизни записей в таблице NAT администраторы сети могут вмешиваться вручную. Если необходимо очистить таблицу NAT, можно выполнить команду conntrack -F, которая немедленно удалит все существующие записи. Кроме того, если происходит сброс соединения с внешней сетью, например при перезапуске WAN-интерфейса, все связанные NAT-состояния могут быть удалены, поскольку они ассоциируются с публичным IP-адресом, который может измениться.
Понимание механизмов удаления записей из таблицы NAT важно для сетевых администраторов, поскольку временные ограничения и пользовательские настройки могут влиять на доступность и производительность сети. Например, использование механизма «keep-alive» или периодических пингов может предотвращать преждевременное истечение срока действия UDP-сессий, что особенно важно в условиях, когда NAT «скуп» и агрессивно сбрасывает состояния.
Таким образом, учитывая все особенности, можно сказать, что управление записями в таблице NAT — это сложный процесс, зависящий от протоколов, настроек системы и уровня вмешательства администраторов. Проведение адекватной настройки и мониторинга NAT-параметров позволяет поддерживать эффективность и безопасность сетевых соединений.