Объясните пожалуйста, как ответы на 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 и тому подобным протоколам где понятий «закрытие/открытие сесси» нету?
