Соединение IPsec/L2TP завершается сбоем, когда два клиента имеют один и тот же адрес в локальной сети

Время от времени у нас возникают проблемы с VPN удаленного доступа IPsec/L2TP, предоставляемой strongSwan (charon).

Сегодня пользователю не удалось подключиться. Я просмотрел журнал charon и заметил, что это повлияло на другой существующий сеанс. Общей частью был адрес локальной сети (192.168.0.18).

В charon.log все было тихо. Затем подключился пользователь B (50.xx.xx.xx). Сразу же сеанс для пользователя A (70.xx.xx.xx) создал журналы. Когда попытка пользователя B не удалась (l2tp отключился), все снова стихло.

Выдержка из журнала Харона:

16 июля 01:14:59 01[IKE] <21363> 50.xxx.xxx.xxx инициирует IKE_SA основного режима
16 июля, 01:14:59 08[IKE] <удаленный-доступ|21362> закрытие удаленного доступа CHILD_SA{45249} с SPI c9ea7827_i (59714 байт) 08d6c880_o (43106 байт) и TS abc.61.143.254/32[udp/ l2f] === 70.xxx.xxx.xxx/32[udp/63717]
16 июля 01:14:59 08[IKE] <удаленный доступ|21362> удаление удаленного доступа IKE_SA[21362] между abc.61.143.254[abc.61.143.254]...70.xxx.xxx.xxx[ 192.168.0.18]
16 июля 01:14:59 08[IKE] <удаленный-доступ|21363> Удаленный-доступ IKE_SA[21363] установлен между abc.61.143.254[abc.61.143.254]...50.xxx.xxx.xxx[ 192.168.0.18]
16 июля 01:15:00 06[IKE] <удаленный доступ|21363> CHILD_SA удаленный доступ{45251}, установленный с помощью SPI cc91da0f_i 0e42f461_o и TS abc.61.143.254/32[udp/l2f] === 50.68.170.211 /32[udp/58401]
16 июля 01:15:02 15[IKE] <21364> 70.xxx.xxx.xxx инициирует IKE_SA основного режима
16 июля, 01:15:03 11[IKE] <удаленный-доступ|21363> закрытие удаленного доступа CHILD_SA{45251} с SPI cc91da0f_i (331 байт) 0e42f461_o (300 байт) и TS abc.61.143.254/32[udp/ l2f] === 50.xxx.xxx.xxx/32[udp/58401]
16 июля, 01:15:03 11[IKE] <удаленный доступ|21363> удаление удаленного доступа IKE_SA[21363] между abc.61.143.254[abc.61.143.254]...50.xxx.xxx.xxx[ 192.168.0.18]
16 июля 01:15:03 11[IKE] <удаленный-доступ|21364> Удаленный доступ IKE_SA[21364] установлен между abc.61.143.254[abc.61.143.254]...70.xxx.xxx.xxx[ 192.168.0.18]
16 июля 01:15:03 07[IKE] <удаленный доступ|21364> CHILD_SA удаленный доступ{45252}, установленный с помощью SPI cca08f41_i 0da530b5_o и TS abc.61.143.254/32[udp/l2f] === 70.xxx .xxx.xxx/32[udp/63717]
16 июля 01:15:22 11[IKE] <21365> 50.xxx.xxx.xxx инициирует IKE_SA основного режима
16 июля, 01:15:23 07[IKE] <удаленный-доступ|21364> закрытие удаленного доступа CHILD_SA{45252} с SPI cca08f41_i (12135 байт) 0da530b5_o (8428 байт) и TS abc.61.143.254/32[udp/ l2f] === 70.xxx.xxx.xxx/32[udp/63717]
16 июля 01:15:23 07[IKE] <удаленный доступ|21364> удаление удаленного доступа IKE_SA[21364] между abc.61.143.254[abc.61.143.254]...70.xxx.xxx.xxx[ 192.168.0.18]
16 июля 01:15:23 07[IKE] <удаленный-доступ|21365> Удаленный-доступ IKE_SA[21365] установлен между abc.61.143.254[abc.61.143.254]...50.xxx.xxx.xxx[ 192.168.0.18]
16 июля 01:15:23 12[IKE] <удаленный доступ|21365> CHILD_SA удаленный доступ{45253}, установленный с помощью SPI c28d018d_i 0dbb052e_o и TS abc.61.143.254/32[udp/l2f] === 50.xxx .xxx.xxx/32[udp/58401]
16 июл 01:15:26 15[KNL] 10.255.255.0 появился на ppp1
16 июл 01:15:26 14[KNL] 10.255.255.0 исчез из ppp1

Я не понимаю, как адрес локальной сети может повлиять на сервер.Но конфликт между этими двумя связями постоянен. И лог вполне до и после вышеуказанных логов.

Проблема в том, что клиенты отправляют свой частный IP-адрес в качестве своей личности. Вы можете увидеть тождества в [] в сообщениях журнала:

удаление удаленного доступа IKE_SA[21362] между abc.61.143.254[abc.61.143.254]...70.xxx.xxx.xxx[192.168.0.18]
Удаленный доступ IKE_SA[21363] установлен между abc.61.143.254[abc.61.143.254]...50.xxx.xxx.xxx[192.168.0.18]

Таким образом, оба IKE_SA находятся между идентификаторами 192.168.0.18 и абв.61.143.254.

В зависимости от настройки для уникальный (swanctl.conf) или же уникальные идентификаторы (ipsec.conf), дубликат будет удален. Чтобы этого избежать, отключите эту проверку уникальности, установив для нее значение нет или, если клиент отправляет ПЕРВОНАЧАЛЬНЫЙ КОНТАКТ уведомляет, чтобы никогда.