Меня интересует сквозная передача PPTP, а не IPsec и т. Д. Я искал в сети, но не могу понять, как это делается. Я сам ИТ-администратор и хорошо разбираюсь в маршрутизации, NAT и т. Д. Я думаю, что знаю, как это работает, но нашел это официально. Мне просто любопытно, и я хотел бы, чтобы кто-нибудь подтвердил мою теорию. вот.
Проблема в первую очередь сводится к NAT при совместном использовании одного публичного IP-адреса. NAT работает с использованием PAT для совместного использования одного общедоступного IP-адреса с несколькими частными IP-адресами. Без портов и PAT это было бы невозможно, поскольку, когда пакеты возвращаются из пункта назначения, все они будут адресованы на общедоступный IP-адрес. Маршрутизатор не сможет отличить разные пакеты друг от друга. Однако, используя исходные порты и PAT, это возможно.
PPTP использует GRE, который сам по себе является протоколом, отличным от TCP или UDP. На самом деле он вообще не использует порты, поэтому возникает проблема с прохождением устройства NAT. Когда пакеты возвращаются из Интернета на маршрутизатор, как можно определить, к какому частному IP-адресу принадлежат эти пакеты, без использования PAT?
Я думаю, что это работает, отслеживая 1723 "канал". Используя PPTP Passthrough, маршрутизатор связывает соединение 1723 (которое будет использовать PAT / NAT) с пакетами GRE, идущими на тот же IP-адрес назначения. Другими словами, когда пакеты GRE возвращаются, он не знает, куда их отправить, поэтому для поиска частного IP-адреса это похоже на соединение 1723. Это правильно, если нет, то как это работает?
Я знаю, что существует NAT-T, но меня заставили поверить, что это отличается от сквозной передачи VPN ...
Я сам это выяснил ... PPTP Passthrough
Как я и подозревал, протокол GRE, используемый для туннеля с PPTP, не использует порты. Это означает, что он не может изначально проходить через NAT-устройство. Однако есть две версии GRE; собственный и расширенная версия под названием Enhanced GRE, используемые специально для PPTP. В расширенной версии в заголовок добавляется идентификатор звонка. Каждый VPN-клиент за NAT создает собственный уникальный идентификатор вызова, который добавляется в заголовок GRE. Маршрутизаторы с возможностью сквозной передачи VPN читают эту часть заголовка и сопоставляют идентификатор вызова с частным IP-адресом за NAT. Устройство NAT должно поддерживать эту функцию. Устройство NAT считывает это, когда пакет проходит его, и проверяет возвращаемые GRE-пакеты на предмет наличия этого параметра, чтобы знать, куда его отправить.
Из http://www.shorewall.net/VPN.htm
Системе с адресом RFC 1918 необходим доступ к удаленной сети через удаленный шлюз. В этом примере мы предположим, что локальная система имеет IP-адрес 192.168.1.12, а удаленный шлюз имеет IP-адрес 192.0.2.224.
Если используется PPTP и вам необходимо иметь две или более локальных систем, подключенных к одному и тому же удаленному серверу одновременно, вы должны быть уверены, что модули вспомогательных средств PPTP загружены (ip_conntrack_pptp и ip_nat_pptp или nf_conntrack_pptp и nf_nat_pptp). Используя файл модулей по умолчанию, Shorewall (Lite) попытается загрузить эти модули при запуске Shorewall (Lite).
Если используется IPSEC, вам следует настроить IPSEC для использования NAT Traversal - при NAT-обходе пакеты IPSEC (протокол 50 или 51) инкапсулируются в пакеты UDP (обычно с портом назначения 4500). Кроме того, сообщения keep-alive часто отправляются, так что шлюзы NAT между конечными точками сохраняют свои записи отслеживания соединений. Это способ, которым я подключаюсь к интрасети HP, и он работает безупречно без чего-либо в Shorewall, кроме моей политики ACCEPT loc-> net. Обход NAT доступен как патч для Windows 2K и является стандартной функцией Windows XP - просто выберите «L2TP IPSec VPN» из раскрывающегося списка «Тип VPN».
В качестве альтернативы, если у вас есть шлюз IPSEC за вашим брандмауэром, вы можете попробовать следующее: только одна система может подключаться к удаленному шлюзу, и существуют следующие требования к конфигурации брандмауэра: