2.23. Работа через NAT
Использование шлюзов с трансляцией сетевых адресов (NAT) является спорным вопросом. В этом параграфе кратко описаны такие шлюзы и их действия по отношению к трафику IKE. Многие враждебно относятся к NAT и считают, что не следует разрабатывать протоколы для улучшения работы через системы трансляции адресов. IKEv2 задает некоторые не вполне очевидные правила обработки для улучшения работы через NAT.
Основной причиной использования NAT является нехватка адресов IPv4. Узлы IP, находящиеся за шлюзами NAT используют адреса IP, которые не являются уникальными в глобальном масштабе и могут совпадать с адресами, которые применяются за другими шлюзами NAT. В общем случае узлы, расположенные за NAT, могут взаимодейтсвовать с другими узлами за тем же шлюзом NAT и узлами с уникальными в глобальном масштабе адресами, не не с узлами, расположенными за другим шлюзом NAT. Из этого правила есть ряд исключений. Когда узлы, расположенные за NAT, соединяются с узлами в реальной сети Internet, шлюз NAT «преобразует» (транслирует) IP-адрес отправителя, меняя его на адрес, который будет маршрутизироваться обратно на этот шлюз. Полученные из Internet сообщения «транслируются» шлюзом с заменой адреса получателя на внутренний адрес соответствующего конечного узла.
Система NAT разрабатывалась с учетом обеспечения прозрачности для оконечных узлов. Ни программы находящегося за NAT узла, ни узлы Internet не требуется менять для работы через NAT. Обеспечение такой прозрачности для обних протоколов сложнее, чем для других. Протоколы, включающие IP-адреса конечных точек в данные (не только в заголовки), будут сталкиваться с проблемами, пока шлюз NAT не начнет понимать протокол и соответствующим образом изменять данные в пакетах. Такое решение является изначально ненадежным, нарушает целостность сетевого уровня и часто приводит к возникновению трудно обнаруживаемых проблем.
Организация соединений IPsec через NAT вызывает определенные проблемы. Если соединение работает в транспортном режиме, изменение адресов IP в пакетах будет приводить к изменению контрольных сумм, которые NAT не сможет скорректировать, поскольку они криптографически защищены. Даже в туннельном режиме вознкают проблемы с маршрутизацией, поскольку прозрачная трансляция адресов в пакетах AH и ESP требует реализации в NAT специальной логики, которая по своей природе эвристична и ненадежна. По этим причинам IKEv2 использует инкапсуляцию пакетов IKE и ESP в UDP. Такой вариант слегка снижает эффективность, но проще для обработки в NAT. Кроме того, межсетевые экраны могут быть настроены на передачу трафика IPsec, инкапсулированного в UDP, но при этом блокировать ESP/AH и наоборот.
NAT обычно используется для трансляции портов TCP и UDP, наряду с адресами, и использования номеров портов из входящих пакетов для принятия решения об адресе локального узла, которому адресован пакет. По этой причине, хотя пакеты IKE должны отправляться через порт UDP с номером 500, необходимо принимать пакеты, исходящие из любого порта и отклики должны направляться в порт, из которого был получен запрос. Эти требования обусловлены тем, что номера портов могут меняться при прохождении пакетов через NAT. Аналогично, адреса IP конечных точек IKE обычно не включаются в элементы данных IKE, поскольку данные криптографически защищены и не могут прозрачно изменяться устройствами NAT.
Порт 4500 зарезервирован для инкапсуляции ESP и IKE в UDP. При работе через NAT в общем случае лучше передавать пакеты IKE через порт 4500, поскольку некотрые старые реализации NAT обрабатывают трафик IKE через порт 500 некорректно, пытаясь организовать прозрачное соединение IPsec между между конечными точками, которые сами по себе не поддерживают работу через NAT. Такие реализации NAT могут конфликтовать с прямым прохождением через NAT, описанным в этом документе, поэтому конечная точка IPsec, которая обнаружит NAT между собой и своим корреспондентом, должна передавать весь последующий трафик через порт 4500, который NAT не следует обрабатывать специальным способом (как это может происходить для порта 500).