Фаза 1 (АЙК) выполняется без проблем (проверено на целевом хосте).
Фаза 2 (IPSec), однако, в какой-то момент ошибочен (по-видимому, из-за неправильной конфигурации на localhost).
Это должно быть IPSec-только подключение. Я использую OpenSwan на Debian. В журнале ошибок указано следующее (фактический IP-адрес удаленной конечной точки был изменен):
pluto [30868]: "x" # 2: запуск быстрого режима PSK + ENCRYPT + PFS + UP + IKEv2ALLOW + SAREFTRACK {с использованием isakmp # 1 msgid: 5ece82ee offer = AES (12) _256-SHA1 (2) _160 pfsgroup = OAKLEY_GROUP_DH
pluto [30868]: "x" # 1: игнорирование информационной нагрузки, введите NO_PROPOSAL_CHOSEN msgid = 00000000
pluto [30868]: "x" # 1: информационное сообщение получено и проигнорировано
плутон [30868]: "x" # 1: участник предложил: 0.0.0.0/0:0/0 -> 0.0.0.0/0:0/0
pluto [30868]: "x" # 3: ответ на предложение быстрого режима {msgid: a4f5a81c}
плутон [30868]: "x" # 3: us: 192.168.1.76 <192.168.1.76> [+ S = C]
плутон [30868]: "x" # 3: их: 222.222.222.222 <222.222.222.222> [+ S = C] === 10.196.0.0/17
pluto [30868]: "x" # 3: переход из состояния STATE_QUICK_R0 в состояние STATE_QUICK_R1
pluto [30868]: "x" # 3: STATE_QUICK_R1: отправлен QR1, установлен входящий IPsec SA, ожидается QI2
pluto [30868]: "x" # 1: игнорирование информационной нагрузки, введите NO_PROPOSAL_CHOSEN msgid = 00000000
pluto [30868]: "x" # 1: информационное сообщение получено и проигнорировано
pluto [30868]: "x" # 3: следующий тип полезной нагрузки ISAKMP Hash Payload имеет неизвестное значение: 97 X pluto [30868]: "x" # 3: искаженная полезная нагрузка в пакете
плутон [30868]: | полезная нагрузка искажена после IV
Я позади NAT и все это исходит от wlan2. Вот подробности:
по умолчанию через 192.168.1.254 dev wlan2 proto static
169.254.0.0/16 dev wlan2 scope link метрика 1000
192.168.1.0/24 dev wlan2 proto kernel scope link src 192.168.1.76 metric 2
Выход ipsec проверить:
Проверка вашей системы на предмет правильности установки и запуска IPsec:
Проверка версии и ipsec по пути [OK]
Linux Openswan U2.6.37 / K3.2.0-24-generic (сетевой ключ)
Проверка поддержки IPsec в ядре [OK]
Поддержка ядра SAref [N / A]
NETKEY: проверка значений процедуры, связанных с XFRM [OK]
[ХОРОШО]
[ХОРОШО]
Проверка того, что плутон работает [OK]
Плутон прослушивает IKE на udp 500 [OK]
Плутон прослушивает NAT-T на udp 4500 [OK]
Обнаружены два или более интерфейса, проверяется переадресация IP [OK]
Проверка NAT и MASQUERADEing [OK]
Проверка команды "ip" [OK]
Проверка / bin / sh не / bin / dash [ВНИМАНИЕ]
Проверка команды 'iptables' [OK]
Поддержка оппортунистического шифрования [ОТКЛЮЧЕНО]
Вот что происходит, когда я бегу ipsec auto --up x:
104 "x" # 1: STATE_MAIN_I1: инициировать
003 "x" # 1: полученный метод Vendor ID [RFC 3947] имеет значение = 109
106 "x" # 1: STATE_MAIN_I2: отправлено MI2, ожидается MR2
003 "x" # 1: получены полезные данные идентификатора поставщика [Cisco-Unity]
003 "x" # 1: получены полезные данные идентификатора поставщика [обнаружение мертвого узла]
003 "x" # 1: игнорирование полезной нагрузки неизвестного идентификатора поставщика [502099ff84bd4373039074cf56649aad]
003 "x" # 1: получены полезные данные идентификатора поставщика [XAUTH]
003 "x" # 1: NAT-Traversal: результат с использованием RFC 3947 (NAT-Traversal): я NATed
108 "x" # 1: STATE_MAIN_I3: отправлено MI3, ожидается MR3
004 "x" # 1: STATE_MAIN_I4: ISAKMP SA установлена {auth = OAKLEY_PRESHARED_KEY cipher = aes_128 prf = oakley_sha group = modp1024}
117 "x" # 2: STATE_QUICK_I1: инициировать
010 "x" # 2: STATE_QUICK_I1: повторная передача; будет ждать ответа 20 секунд
010 "x" # 2: STATE_QUICK_I1: повторная передача; будет ждать ответа 40 секунд
031 "x" # 2: максимальное количество повторных передач (2) достигло STATE_QUICK_I1. Неприемлемый ответ на наше первое сообщение в быстром режиме: возможно, партнер не любит предложения
000 "x" # 2: начало попытки ввода 2 из не более 3, но выпуск удара
Дополнительная информация об отладке из ipsec auto --status:
000 с использованием интерфейса ядра: netkey
000 интерфейс lo / lo :: 1
000 интерфейс wlan2 / wlan2 192.168.1.76
000 интерфейс wlan2 / wlan2 192.168.1.76
000% myid = (нет)
000 отладка raw + crypt + parsing + emitting + control + lifecycle + klips + dns + oppo + controlmore + pfkey + nattraversal + x509 + dpd + oppoinfo
000
000 virtual_private (% priv):
000 - разрешено 2 подсети: 10.196.0.0/17, 192.168.1.0/24
000 - запрещены 0 подсетей:
000 ПРЕДУПРЕЖДЕНИЕ: Запрещенные подсети в virtual_private = пусто. Если у вас есть
000 во внутреннем использовании, его следует исключить!
000
000 статистика db_ops: {curr_cnt, total_cnt, maxsz}: context = {0,4,36} trans = {0,4,1536} attrs = {0,4,2048}
000
000 "x": 192.168.1.0/24===192.168.1.76 [+S=C ]...222.222.222.222<222.222.222.222> [+S=C impression===10.196.0.0/17; без маршрутов; Владелец eroute: # 0
000 «x»: myip = unset; hisip = не установлено;
000 «х»: ike_life: 28800с; ipsec_life: 28800 с; rekey_margin: 540 с; rekey_fuzz: 100%; нажатий клавиш: 3
000 «x»: политика: PSK + ENCRYPT + PFS + UP + IKEv2ALLOW + SAREFTRACK + lKOD + rKOD; приоритет: 24,17; интерфейс: wlan2;
000 «x»: dpd: action: clear; задержка: 0; тайм-аут: 0;
000 «x»: новейшая ISAKMP SA: # 0; новейшая IPsec SA: # 0;
000 "x": требуются алгоритмы ESP: AES (12) _256-SHA1 (2) _000; pfsgroup = DH22 (22); flags = -strict
000 "x": загружены алгоритмы ESP: AES (12) _256-SHA1 (2) _160
Еще больше отладочной информации (plutodebug = "все") приходящий из /var/log/auth.log:
плутон [26439]: | одноранговый клиент - это подсеть 0.0.0.0/0
плутон [26439]: | протокол / порт однорангового клиента - 0/0
плутон [26439]: | наш клиент - подсеть 0.0.0.0/0
плутон [26439]: | наш клиентский протокол / порт 0/0
плутон [26439]: "x" # 1: участник предложил: 0.0.0.0/0:0/0 -> 0.0.0.0/0:0/0
плутон [26439]: | find_client_connection, начинающийся с x
плутон [26439]: | ищу 0.0.0.0/0:0/0 -> 0.0.0.0/0:0/0
плутон [26439]: | проверка бетона на соответствие sr # 0 192.168.1.0/24 -> 10.196.0.0/17
плутон [26439]: | match_id a = 222.222.222.222
плутон [26439]: | б = 222,222,222,222
плутон [26439]: | результаты совпадают
плутон [26439]: | доверенный_ca вызывается с a = (пусто) b = (пусто)
плутон [26439]: | fc_try пытается x: 0.0.0.0/0: 0/0 -> 0.0.0.0/0:0/0 против x: 192.168.1.0/24: 0/0 -> 10.196.0.0/17:0/0
плутон [26439]: | наш клиент (192.168.1.0/24) не входит в нашу_нет (0.0.0.0/0)
плутон [26439]: | fc_try завершается без ответа [0]
плутон [26439]: | fc_try x не дает
плутон [26439]: | find_host_pair: по сравнению с 192.168.1.76:500 222.222.222.222:500
плутон [26439]: | проверка пары хостов 192.168.1.0/24 -> 10.196.0.0/17 не найдена
плутон [26439]: | заключение с d = none
плутон [26439]: | использование (что-то - надеюсь, IP-адрес, к которому мы или они подключены NAT) для соединения в транспортном режиме "x"
Я включил NAT обход в ipsec.conf соответственно. Вот настройки, относящиеся к рассматриваемому соединению:
версия 2.0
настройка конфигурации
plutoopts = "- perpeerlog"
plutoopts = "- interface = wlan2"
dumpdir = / var / run / pluto /
nat_traversal = да
virtual_private =% v4: 10.0.0.0/8,%v4: 192.168.0.0/16,%v4: 172.16.0.0/12
oe = выкл
protostack = netkeyconn x
authby=secret pfs=yes auto=add phase2alg=aes256-sha1;dh22 keyingtries=3 ikelifetime=8h type=transport left=192.168.1.76 leftsubnet=192.168.1.0/24 leftprotoport=0/0 right=222.222.222.222 rightsubnet=10.196.0.0/17 rightprotoport=0/0
Вот спецификации, предоставленные другим концом, которые должны быть выполнены для Фаза 2:
алгоритм шифрования: AES (128 или 256 бит)
алгоритм хеширования: SHA
локальный идентификатор1 (адрес / маска / прот / порт): (10.196.0.0/255.255.128.0/0/0)
локальный идентификатор2 (адрес / маска / прот / порт): (10.241.0.0/255.255.0.0/0/0)
удаленный идентификатор (адрес / маска / прот / порт): (x.x.x.x / x.x.x.x / 0/0) (внутренняя сеть или локальный хост)
Время жизни ассоциации безопасности: 4608000 килобайт / 3600 секунд
PFS: DH группа2
Итак, наконец, в чем может быть причина проблемы, с которой я столкнулся? Спасибо.
Вы захотите, чтобы удаленный конец также включал 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). Последнее сообщение - проверить живость респондента. Это просто для того, чтобы сообщить респонденту, что предыдущие сообщения были получены и обработаны правильно.