Назад | Перейти на главную страницу

Использование strongSwan в качестве VPN-сервера для контролируемых (постоянно включенных) VPN-клиентов iOS. Клиенты iOS устанавливают две ассоциации с сервером. Зачем?

Я использую rightsourceip=%dhcp на сервере, поэтому у двух клиентов не может быть одинаковых leftid.

Перед использованием rightsourceip=%dhcp, Я использовал uniqueids=never и 10.0.2.0/24 чтобы позволить нескольким клиентам с одним и тем же leftid, но это не работает с rightsourceip=%dhcp (Я делаю что-то неправильно?).

Похоже, что контролируемые (всегда включенные) VPN-клиенты iOS устанавливают две ассоциации, одну по LTE и одну по Wi-Fi ... что нарушает подключение к серверу VPN. Предположим, сервер не знает, в какую ассоциацию должны быть отправлены пакеты ... и, возможно, iOS не прослушивает оба интерфейса, когда Wi-Fi включен.

Как я могу это исправить? Кроме того, что делает rekeying disabled значит?

Security Associations (5 up, 0 connecting):
       ikev2[7]: ESTABLISHED 65 seconds ago, 159.203.26.109[my-vpn.com]...207.46.13.62[client@my-vpn.com]
       ikev2[7]: IKEv2 SPIs: 0a53e7fec5e65e2b_i 2d03da3fce35f91c_r*, rekeying disabled
       ikev2[7]: IKE proposal: AES_GCM_16_256/PRF_HMAC_SHA2_384/MODP_3072
       ikev2{7}:  INSTALLED, TUNNEL, reqid 5, ESP in UDP SPIs: c468b92b_i 00006960_o
       ikev2{7}:  AES_GCM_16_256, 8795 bytes_i (22 pkts, 0s ago), 4983 bytes_o (19 pkts, 41s ago), rekeying disabled
       ikev2{7}:   0.0.0.0/0 === 10.0.2.13/32
       ikev2[6]: ESTABLISHED 65 seconds ago, 159.203.26.109[my-vpn.com]...157.55.39.61[client@my-vpn.com]
       ikev2[6]: IKEv2 SPIs: e2a7434252a49075_i fe57e34b97ba086e_r*, rekeying disabled
       ikev2[6]: IKE proposal: AES_GCM_16_256/PRF_HMAC_SHA2_384/MODP_3072
       ikev2{6}:  INSTALLED, TUNNEL, reqid 5, ESP in UDP SPIs: cdc9dd9c_i 0ec723e6_o
       ikev2{6}:  AES_GCM_16_256, 8170 bytes_i (122 pkts, 0s ago), 0 bytes_o, rekeying disabled
       ikev2{6}:   0.0.0.0/0 === 10.0.2.13/32

Если одноранговый узел создает несколько IKE_SA с одним и тем же идентификатором, и это не предотвращается политикой уникальности, для правильной работы требуется несколько виртуальных IP-адресов для каждого клиента (как вы отметили, сервер может отправлять пакеты, адресованные виртуальному IP-адресу, только через один из два туннеля).

Таким образом, назначение статической аренды с помощью бэкэндов, таких как DHCP или RADIUS, может быть сложным, поскольку они обычно имеют сопоставление идентичности 1: 1 с IP-адресом. В зависимости от реализации DHCP / RADIUS-сервера может быть возможно позволить им назначать несколько IP-адресов для одного и того же идентификатора (например, путем настройки нескольких статических аренд или с учетом других параметров, помимо идентификатора, см. Соответствующую документацию). В противном случае вам придется изменить конфигурацию внутреннего сервера (а в случае DHCP - плагина), чтобы динамическая аренда назначалась клиентам.

Кроме того, что делает rekeying disabled значит?

Который активный изменение ключей отключено в конфигурации (например, через rekey=no). Демон IKE по-прежнему будет отвечать на запросы смены ключей от клиентов.