LINUX.ORG.RU

Периодически не работает IPsec VPN

 


0

1

Имеется сервер со Strongswan, на котором настроен IKEv2 VPN. Имеется клиентский компьютер с Windows 10, на котором настроено подключение. Иногда оно работает, иногда не работает (без каких-либо изменений). Подозреваю, что проблема в провайдере, но хотелось бы убедиться, что не у меня. На данный момент запустил tcpdump на сервере и wireshark на компьютере, сделал попытку подключения, Windows сказала, что удалённый сервер не отвечает.

Вот лог на сервере (IP подкорректировал во имя никому не нужной секретности, 1.2.3.4 это сервер, 5.6.7.8 это клиент):

# tcpdump -n -i ens3 ip host 5.6.7.8 and udp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on ens3, link-type EN10MB (Ethernet), capture size 262144 bytes
21:47:47.210960 IP 5.6.7.8.500 > 1.2.3.4.500: isakmp: parent_sa ikev2_init[I]
21:47:47.229750 IP 1.2.3.4.500 > 5.6.7.8.500: isakmp: parent_sa ikev2_init[R]
^C
2 packets captured
4 packets received by filter
0 packets dropped by kernel

Вот wireshark с похожим фильтром:

1	0.000000	192.168.1.31	1.2.3.4	ISAKMP	674	IKE_SA_INIT MID=00 Initiator Request
2	0.112984	1.2.3.4	192.168.1.31	ISAKMP	490	IKE_SA_INIT MID=00 Responder Response
3	0.134163	192.168.1.31	1.2.3.4	ISAKMP	626	IKE_AUTH MID=01 Initiator Request (fragment 1/4)
4	0.134271	192.168.1.31	1.2.3.4	ISAKMP	626	IKE_AUTH MID=01 Initiator Request (fragment 2/4)
5	0.134339	192.168.1.31	1.2.3.4	ISAKMP	626	IKE_AUTH MID=01 Initiator Request (fragment 3/4)
6	0.134392	192.168.1.31	1.2.3.4	ISAKMP	290	IKE_AUTH MID=01 Initiator Request (fragment 4/4)
7	1.134337	192.168.1.31	1.2.3.4	ISAKMP	626	IKE_AUTH MID=01 Initiator Request (fragment 1/4)
8	1.134359	192.168.1.31	1.2.3.4	ISAKMP	626	IKE_AUTH MID=01 Initiator Request (fragment 2/4)
9	1.134369	192.168.1.31	1.2.3.4	ISAKMP	626	IKE_AUTH MID=01 Initiator Request (fragment 3/4)
10	1.134380	192.168.1.31	1.2.3.4	ISAKMP	290	IKE_AUTH MID=01 Initiator Request (fragment 4/4)
11	2.134875	192.168.1.31	1.2.3.4	ISAKMP	626	IKE_AUTH MID=01 Initiator Request (fragment 1/4)
12	2.134922	192.168.1.31	1.2.3.4	ISAKMP	626	IKE_AUTH MID=01 Initiator Request (fragment 2/4)
13	2.134945	192.168.1.31	1.2.3.4	ISAKMP	626	IKE_AUTH MID=01 Initiator Request (fragment 3/4)
14	2.134971	192.168.1.31	1.2.3.4	ISAKMP	290	IKE_AUTH MID=01 Initiator Request (fragment 4/4)

Если что, Windows стоит за NAT-ом (обычный провайдерский модем).

Все устройства пробовал перезагружать. Иногда помогает, но не в этот раз. Других сетевых глюков кроме VPN-а я не наблюдаю, всякие игры через UDP работают без нареканий.

Собственно видно, что Windows отправляет пакеты вида «ISAKMP 626 IKE_AUTH MID=01 Initiator Request (fragment 1/4)», а сервер их не получает.

Правда у меня вызывает некоторое непонимание строчка в tcpdump-е:

2 packets captured
4 packets received by filter

Конечно всё равно не сходятся, но не понятно, почему 4 пакета получено фильтром, что это означает. Хотелось бы для общего кругозора разобраться.

Конфиги strongswan-а почти дефолтные, если нужно - выложу, не думаю, что это имеет значение. На nftables всё что нужно разрешено.

Кстати ещё этот VPN настроен на iOS и там тоже подобные проблемы. Но wireshark я там запустить не могу, поэтому тут сложней понять что-либо.

На модеме, если что, я вообще ничего не могу запустить, доступ туда только к веб-интерфейсу, в котором ничего интересного нет.

★★★★★

Последнее исправление: Legioner (всего исправлений: 1)

2 packets captured

4 packets received by filter

Пришло 4 пакета. 2 пакета прошли через фильтр.

Это данные статистики, которая получаются от ядра через getsockopt(handle->fd, SOL_PACKET, PACKET_STATISTICS,...)

Запусти без указания фильтра на низкоскоростном интерфейсе и цифры будут совпадать.

На нагруженном интерфейсе «packets received by filter» будет больше, т.к. tcpdump очень долго думает с момента открытия интерфейса до начала чтения.

vel ★★★★★
()

Подпишусь на тред, т.к. похожая проблема встречается у некоторых точек и общее решение пока не нашёл. И в W10, как у ТС, и в W7 (ошибка 809) и баг плавающий, т.е иногда работает, иногда нет.

Если ещё и в логах @Legioner вот такая история:

gateway charon[824]: 06[NET] received packet: from <адрес-хоста>[108] to <адрес-сервера>[500] (632 bytes)
gateway charon[824]: 06[ENC] parsed IKE_SA_INIT request 0 [ SA KE No N(FRAG_SUP) N(NATD_S_IP) N(NATD_D_IP) V V V V ]
gateway charon[824]: 06[IKE] received MS NT5 ISAKMPOAKLEY v9 vendor ID
gateway charon[824]: 06[IKE] received MS-Negotiation Discovery Capable vendor ID
gateway charon[824]: 06[IKE] received Vid-Initial-Contact vendor ID
gateway charon[824]: 06[ENC] received unknown vendor ID: 01:52:8b:bb:c0:06:96:12:18:49:ab:9a:1c:5b:2a:51:00:00:00:02
gateway charon[824]: 06[IKE] <адрес-хоста> is initiating an IKE_SA
gateway charon[824]: 06[IKE] <адрес-хоста> is initiating an IKE_SA
gateway charon[824]: 06[CFG] selected proposal: IKE:AES_CBC_256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_2048
gateway charon[824]: 06[IKE] remote host is behind NAT
gateway charon[824]: 06[IKE] sending cert request for "<данные сертификата>"
gateway charon[824]: 06[ENC] generating IKE_SA_INIT response 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) CERTREQ N(FRAG_SUP) N(CHDLESS_SUP) N(MULT_AUTH) ]
gateway charon[824]: 06[NET] sending packet: from <адрес-сервера>[500] to <адрес-хоста>[108] (481 bytes)
gateway charon[824]: 10[JOB] deleting half open IKE_SA with <адрес-хоста> after timeout

то это тотже случай. Стоит эту же машину переключить на мобильный инет или на РТ-GPON - тутже тоже самое подключение замечательно работает. Подозреваю, что провайдер (РосТелеком в моём случае), что-то периодически мутит с mtu, но это не точно, т.к. проблема всё равно нет-нет да всплывает.

SkyMaverick ★★★★★
()

компьютер с Windows 10, на котором настроено подключение

Сейчас будет глупый вопрос...

«Использовать основной шлюз в удалённой сети» - включен?

И модем не huawei HG8240 от ростелекома?

lawliet
()

Зачем дампы? Включай логирование харона и кури лог.

thesis ★★★★★
()
Ответ на: комментарий от SkyMaverick

Возможно, клиент не находит подходящий сертификат и сбрасывает соединение. Если бы от клиента не приходил ответ, в логе было бы несколько повторных запросов (если не ошибаюсь).

thesis ★★★★★
()
Ответ на: комментарий от thesis

Ну я тоже так подумал сначала, но если, допустим, взять телефон, создать на нём точку и переключить WiFi через неё, ТО ЖЕ САМОЕ VPN-соединение работает стабильно и устойчиво. Казалось-бы тоже NAT и, в общем-то, такая же точка доступа, но работает.

Отсюда возникают мысли, что это или проблемы клиентских роутеров (возможно неявно что-то режут) или где-то мудрит провайдер или я что-то не понимаю.

SkyMaverick ★★★★★
()
Последнее исправление: SkyMaverick (всего исправлений: 3)
Ответ на: комментарий от SkyMaverick

А, я не дочитал до конца.
У железок часто требуется дополнительно разрешать проброс айписеков в настройках. Приколов с фрагментацией удп пока не обсуждаем.

thesis ★★★★★
()
Последнее исправление: thesis (всего исправлений: 1)
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.