VPN, которую я использую на своем домашнем компьютере под управлением Windows для подключения к серверам моей компании, является клиентом Cisco. Клиент настроен на использование «IPSec over UDP (NAT / PAT)».
Зачем вам использовать UDP, «ненадежный» протокол для безопасного туннеля? Разве ненадежность протокола не вызовет проблемы при отбрасывании UDP-пакетов?
Или протокол использует UDP, но добавляет надежности на прикладном уровне?
Он использует UDP для прохождения глупых устройств NAT. Здесь происходит то, что фактический трафик IPSec инкапсулируется в UDP (Протокол IP 17). Собственный пакет IPSec будет иметь значение заголовка протокола IP 50. Поскольку 50 не является ни UDP (17), ни TCP (6), глупые шлюзы NAT будут отбрасывать пакет, а не передавать его.
Во-вторых, поскольку IPSec не является ни TCP, ни UDP, у него нет номера порта. Так что, если вы находитесь на очень большой конференции, и восемь ваших коллег тоже собираются, только один из вас может включить VPN в любое время, поскольку концентратор VPN выполняет только устранение неоднозначности на уровне IP. Инкапсулируя пакет внутри UDP, он позволяет использовать несколько оконечных точек VPN за устройством NAT.
А почему именно UDP? Это описано в RFC 3715. Раздел 2.1.b:
Несовместимость контрольных сумм и NAT. Контрольные суммы TCP и UDP зависят от IP-адресов источника и назначения за счет включения в расчет «псевдозаголовка». В результате, если контрольные суммы вычисляются и проверяются при получении, они будут признаны недействительными при прохождении через NAT или устройство обратного NAT.
В результате полезная нагрузка IPsec Encapsulating Security Payload (ESP) будет проходить через NAT беспрепятственно только в том случае, если протоколы TCP / UDP не задействованы (как в туннельном режиме IPsec или GRE с защитой IPsec) или контрольные суммы не вычисляются (как это возможно с IPv4 UDP. ). Как описано в [RFC793], в IPv4 требуется вычисление и проверка контрольной суммы TCP. В IPv6 требуется вычисление и проверка контрольной суммы UDP / TCP.
Это может произойти, поскольку в самом стеке IPSec предусмотрена проверка целостности, поэтому использование «ненадежного» протокола для транзитных сетей не приводит к критическому нарушению функциональности. Если пакет зашифрован во время передачи, он не будет правильно деинкапсулироваться, и протокол IPSec будет правильно обрабатывать этот случай.
Некоторые клиенты поддерживают режим TCP, но Cisco к их числу не относится.