Профиль Strongswan swanctl для собственного Android IKEv2 IPsec

Android 11, похоже, теперь поддерживает IKEv2 / IPsec, поэтому я пытаюсь создать для него профиль swanctl roadwarrior. Пока добрался до того, что установил SA, но тут же удалил. Что-нибудь посоветуете?

Профиль Android VPN содержит:

  • Тип: IKEv2 / IPsec PSK
  • Сервер: moon.isuldor.com
  • Идентификатор IPsec: strongswan на isuldor.com
  • IPsec PSK: hunter2

В моем vpn-шлюзе:

$ swanctl --version
strongSwan swanctl 5.9.0

$ cat /etc/swanctl/conf.d/android11.conf
connections {
    rw-isuldor {
        local_addrs = moon.isuldor.com
        pools = android11_pool4, android11_pool6
        fragmentation = yes
        send_cert = always
        rekey_time = 0s
        dpd_delay = 30s
        local {
            auth = pubkey
            certs = moon.pem
            id = moon.isuldor.com
        }
        remote {
            auth = psk
            id = strongswan at isuldor.com
        }
        children {
            moon {
                local_ts  = 0.0.0.0/0,::/0
                rekey_time = 0s
                dpd_action = clear
            }
        }
    }
}
secrets {
    ike-isuldor {
        id_isuldor = strongswan at isuldor.com
        secret = hunter2
    }
}
pools {
    android11_pool4 {
        addrs = 192.168.2.0/24
        dns = 1.1.1.1,1.0.0.1
    }
    android11_pool6 {
        addrs = 2607:9cf3:0:ae::6:1300/120
        dns = 2606:4700:4700::1111,2606:4700:4700::1001
    }
}

Соответствующие журналы от charon-systemd:

X.X.X.X is initiating an IKE_SA
IKE_SA (unnamed)[11] state change: CREATED => CONNECTING
selected proposal: IKE:AES_CBC_128/HMAC_SHA2_256_128/PRF_AES128_XCBC/MODP_3072
remote host is behind NAT
...
looking for peer configs matching Y.Y.Y.Y[moon.isuldor.com]...X.X.X.X[strongswan at isuldor.com]
selected peer config 'rw-isuldor'
authentication of 'strongswan at isuldor.com' with pre-shared key successful
...
peer requested virtual IP %any
assigning new lease to 'strongswan at isuldor.com'
assigning virtual IP 192.168.2.1 to peer 'strongswan at isuldor.com'
peer requested virtual IP %any6
assigning virtual IP <redacted> to peer 'strongswan at isuldor.com'
...
CHILD_SA moon{4} established with SPIs cba17603_i 0f8dcc81_o and TS 0.0.0.0/0 ::/0 === 192.168.2.1/32
CHILD_SA moon{4} state change: INSTALLING => INSTALLED
generating IKE_AUTH response 1 [ IDr CERT AUTH CPRP(ADDR DNS DNS) SA TSi TSr ]
splitting IKE message (2416 bytes) into 3 fragments
generating IKE_AUTH response 1 [ EF(1/3) ]
generating IKE_AUTH response 1 [ EF(2/3) ]
generating IKE_AUTH response 1 [ EF(3/3) ]
sending packet: from Y.Y.Y.Y[4500] to X.X.X.X[38733] (1236 bytes)
sending packet: from Y.Y.Y.Y[4500] to X.X.X.X[38733] (1236 bytes)
sending packet: from Y.Y.Y.Y[4500] to X.X.X.X[38733]
sending packet: from Y.Y.Y.Y[4500] to X.X.X.X[38733] (84 bytes)
sending packet: from Y.Y.Y.Y[4500] to X.X.X.X[38733]
checkin IKE_SA rw-isuldor[7]
sending packet: from Y.Y.Y.Y[4500] to X.X.X.X[38733]
checkin of IKE_SA successful
received packet: from X.X.X.X[38733] to Y.Y.Y.Y[4500]
waiting for data on sockets
checkout IKEv2 SA by message with SPIs ce7fea937528e3ca_i 115e7e1303dd7bc4_r
IKE_SA rw-isuldor[7] successfully checked out
received packet: from X.X.X.X[38733] to Y.Y.Y.Y[4500] (80 bytes)
parsed INFORMATIONAL request 2 [ D ]
received DELETE for IKE_SA rw-isuldor[7]
deleting IKE_SA rw-isuldor[7] between Y.Y.Y.Y[moon.isuldor.com]...X.X.X.X[strongswan at isuldor.com]
IKE_SA rw-isuldor[7] state change: ESTABLISHED => DELETING
IKE_SA deleted
generating INFORMATIONAL response 2 [ ]
sending packet: from Y.Y.Y.Y[4500] to X.X.X.X[38733] (80 bytes)
checkin and destroy IKE_SA rw-isuldor[7]
sending packet: from Y.Y.Y.Y[4500] to X.X.X.X[38733]
IKE_SA rw-isuldor[7] state change: DELETING => DESTROYING
CHILD_SA moon{4} state change: INSTALLED => DESTROYING
deleting policy 0.0.0.0/0 === 192.168.2.1/32 out
deleting policy 192.168.2.1/32 === 0.0.0.0/0 in
deleting policy 192.168.2.1/32 === 0.0.0.0/0 fwd
deleting SAD entry with SPI cba17603
deleted SAD entry with SPI cba17603
deleting SAD entry with SPI 0f8dcc81
deleted SAD entry with SPI 0f8dcc81
lease 192.168.2.1 by 'strongswan at isuldor.com' went offline
checkin and destroy of IKE_SA successful

Обновление: проблема стала очевидной сразу после того, как я получил журналы Android. В основном я использовал adb shell для доступа к устройству, затем logcat с соответствующим фильтром. Вероятно, есть терминальные приложения, которые тоже могут это делать. Корень не требовался.

130|sargo:/ $ whoami
shell
130|sargo:/ $ logcat *:S IkeV2VpnRunner:V
--------- beginning of system
--------- beginning of main
[..] IkeV2VpnRunner: com.android.internal.net.ipsec.ike.exceptions.AuthenticationFailedException: Expected the remote/server to use PSK-based authentication but they used: 14

Вывод: профиль swanctl должен иметь auth = psk в разделе local и дополнительную строку, назначающую общий ключ для сервера, например: id_moon = moon.isuldor.com под secrets.ike-isuldor . Это работало исключительно для strongswan swanctl 5.9.0 , но пока мне не удалось воспроизвести успех с более ранней версией 5.7.2 . Я подозреваю, что синтаксис каким-то образом изменился. Но главной проблемой была неправильная аутентификация сервера.

0
задан 2 December 2020 в 03:40
1 ответ

Как подтверждает журнал клиента, он ожидал, что сервер также будет аутентифицироваться с помощью PSK, а не сертификата. Поэтому вместо local.auth=pubkey вам нужно настроить local.auth=psk.

Обратите внимание, что использование сертификата на сервере и PSK на клиенте поддерживается протоколом IKEv2 и защищает от других хостов, которые знают PSK, выдающий себя за сервер (каждый клиент должен это знать и может это сделать). , у него та же проблема, что и у аутентификации PSK IKEv2 в целом: клиент отправляет полезную нагрузку AUTH перед проверкой аутентификации сервера. Активный злоумышленник может использовать это для определения слабого PSK с помощью атак по словарю или грубой силы. Гораздо более безопасным подходом является использование аутентификации сертификата для сервера и методов EAP на основе имени пользователя и пароля (например, EAP-MD5 или EAP-MSCHAPv2) для клиента, потому что тогда клиент отправляет свой хешированный пароль только после проверки сертификата сервера.

2
ответ дан 2 December 2020 в 07:43

Теги

Похожие вопросы