LINUX.ORG.RU

nat + udp/icmp/other_non_tcp

 , ,


0

1

Объясните пожалуйста, как ответы на ping или, например, на запросы DNS по UDP проходят через NAT? Если с TCP вроде понятно, создавая сессию, NAT в состоянии удерживать открытый порт для клиента за NATом до момента закрытия сессии и транслировать адрес/порт, то как это выглядит в случае с, например, UDP запросом к DNS серверу?

Например в таком setup:

10.0.0.12 (client) <-> 10.0.0.1/NAT_external_ip (gateway) <-> DNS_server_external_ip

Если client посылает UDP запрос к DNS серверу, то DNS сервер ведь пошлет обратно UDP ответ NAT_external_ip и неизвестно как долго ответ будет идти обратно. У gateway есть какой-то timeout? Т.е. например если client посылает пакет с:

from: 10.0.0.12
to: DNS_server_external_ip:some_port

Когда пакет приходит к gateway, gateway переписывает его как:

from: NAT_external_ip:some_other_port
to: DNS_server_external_ip:some_port

И теперь приходит ответ от DNS_server_external_ip:

from: DNS_server_external_ip
to: NAT_external_ip:some_other_port

Теперь NAT_external_ip может содержать у себя локально информацию, что пакеты, которые приходят на NAT_external_ip:some_other_port следует отослать 10.0.0.12, но ведь сессии как таковой нету. Как долго эта информация будет актуальна? У NAT_external_ip есть по этому поводу какой-то конфигурируемый timeout? Если в случае с TCP gateway может «забыть» эту информацию при закрытии TCP сессии, то как быть с UDP/ICMP и тому подобным протоколам где понятий «закрытие/открытие сесси» нету?

Конкретно для UDP есть RFC4787, который рекомендует определённые таймауты. Также есть STUN, есть разные техники hole punching, которые закладываются на определённое поведение натов. Но в общем случае у каждой конкретной реализации могут быть свои настройки, а у каждого админа свои предпочтения на этот счёт.

Laz ★★★★★ ()