Сложности OpenSwan IPSec фазы № 2
Если два различных хоста находятся в ТОЙ ЖЕ СЕТИ, они могут говорить непосредственно.
Если два различных хоста находятся в РАЗЛИЧНЫХ СЕТЯХ, им нужен маршрутизатор для передачи пакетов.
Пример:
- Хост A: 10.0.0.42 находится в сети 10.0.0.0/8 (иначе Сеть класса A)
- Хост B: 172.16.0.42 находится в сети 172.16.0.0/12 (иначе Сеть класса B)
- Хост C: 11.0.0.42 находится в сети 11.0.0.0/8 (иначе сеть класса A)
Так как A и B находятся в различных сетях, им нужен маршрутизатор для разговора.
Так как B и C находятся в различных сетях, им нужен маршрутизатор для разговора.
Так как A и C находятся в различных сетях, им нужен маршрутизатор для разговора.
Длина префикса сети (мы раньше называли это Классом) не имеет НИКАКОГО ЗНАЧЕНИЯ к тому, могут ли говорить два хоста. Различие находится в сети.
Вы захотите, чтобы удаленный конец также включал NAT-T на своем конце соединения.
Связь IPSec криптографически подписывает весь пакет - любое изменение в заголовке IP сделает эту подпись недействительной. NAT работает путем перезаписи полей IP-адреса источника и / или назначения; наличие NAT на обоих концах соединения означает, что заголовок каждого пакета изменяется при передаче; источник изменяется для пакетов, покидающих вашу сеть 192.168 , а место назначения изменяется для входящих пакетов.
NAT-T противодействует этому, инкапсулируя весь пакет ESP в новый пакет UDP. Заголовки UDP-пакета могут быть изменены в соответствии с требованиями любых устройств NAT, в то время как полезная нагрузка ESP не изменит всю поездку. Удаленному узлу необходимо будет включить это, чтобы защитить пакеты, которые они отправляют вам, от изменений NAT, и вам обоим нужно будет разрешить порт UDP 4500.
Это может быть не единственная проблема в конфигурации туннель VPN, но он определенно объяснил бы искаженное сообщение полезной нагрузки; попробуйте и дайте нам знать, если возникнут дополнительные проблемы!
Поддержка NAT Traversal обнаружена в первых двух сообщениях ISAKMP. Если оба устройства поддерживают NAT-T, тогда NAT-Discovery выполняется в третьем и четвертом сообщениях основного режима ISKAMP. Поскольку вы прошли обмен ISAKMP. Я не думаю, что это проблема NAT-T.
Как видно здесь:
003 "x" #1: NAT-Traversal: Result using RFC 3947 (NAT-Traversal): i am NATed
004 "x" #1: STATE_MAIN_I4: ISAKMP SA established {auth=OAKLEY_PRESHARED_KEY cipher=aes_128 prf=oakley_sha group=modp1024}
Судя по журналам IPsec, это ошибка либо в версии * Swan, либо в устройстве шлюза инициатора.
pluto[30868]: "x" #3: STATE_QUICK_R1: sent QR1, inbound IPsec SA installed, expecting QI2
Входящая SA установлена. Обратите внимание, что в конце сообщения 2 быстрого режима туннели готовы к использованию . Ответчик ожидает окончательного подтверждения (Сообщение 3). Последнее сообщение - проверить живость респондента. Это просто для информирования респондента о том, что предыдущие сообщения были получены и обработаны правильно.