LINUX.ORG.RU
решено ФорумAdmin

IPsec VPN через Strongswan: ошибка авторизации

 , ,


0

1

Решение: IPsec VPN через Strongswan: ошибка авторизации (комментарий)

Решение, часть 2: IPsec VPN через Strongswan: ошибка авторизации (комментарий)

Пробую поднять IPsec IKEv2 VPN, на обоих концах Strongswan, авторизация через сертификаты X.509. При подключении приходит отлуп с AUTH_FAILED на IKE_AUTH request 1. Со стороны сервера CA сертификат подгружается нормально, в логах нет явных сообщений про неизвестные сертификаты.

Как это всё пофиксить? IPsec настраиваю второй раз, мб что-то простое пропустил.

Ниже 1.2.3.4 – внешний IP сервера, 5.6.7.8 – внешний IP клиента, 192.168.0.2 – внутренний IP клиента, 192.168.0.100 – внутренний IP сервера.

Конфиг сервера:

connections {
    client {
        version = 2
        proposals = aes256gcm16-aes256gcm16-prfsha256-ecp256-ecp521,aes192-sha256-modp3072,default
        rekey_time = 0s
        pools = vpnpool
        fragmentation = yes
        dpd_delay = 30s
        local {
            certs = server.crt
        }
        remote {
        }
        children {
            client {
                local_ts = 0.0.0.0/0
                rekey_time = 0s
                dpd_action = clear
                esp_proposals = aes256gcm16-aes256gcm16-prfsha256-ecp256-modp3072,aes192-sha256-ecp256-modp3072,default
            }
        }
    }
}
pools {
    vpnpool {
        addrs = 10.1.1.0/30
        dns = 8.8.8.8
    }
}
secrets {
    private {
        file = server.key
    }
}

Конфиг клиента:

conn server
    keyexchange=ikev2
    rekey=no
    leftsourceip=%modeconfig
    leftauth=rsa
    leftcert=/etc/ipsec.d/client.crt
    leftfirewall=yes
    right=1.2.3.4
    rightsubnet=0.0.0.0/0
    auto=add

ca server-ca
    auto=add
    cacert=/etc/ipsec.d/ca.crt

Лог на клиенте:

% sudo ipsec up server
initiating IKE_SA server[2] to 1.2.3.4
generating IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) N(FRAG_SUP) N(HASH_ALG) N(REDIR_SUP) ]
sending packet: from 192.168.0.2[500] to 1.2.3.4[500] (972 bytes)
received packet: from 1.2.3.4[500] to 192.168.0.2[500] (317 bytes)
parsed IKE_SA_INIT response 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) CERTREQ N(FRAG_SUP) N(HASH_ALG) N(CHDLESS_SUP) N(MULT_AUTH) ]
selected proposal: IKE:AES_GCM_16_256/PRF_HMAC_SHA2_256/ECP_256
local host is behind NAT, sending keep alives
remote host is behind NAT
received cert request for "CN=VPN CA"
received 1 cert requests for an unknown ca
sending cert request for "CN=VPN CA"
authentication of 'CN=client' (myself) with RSA_EMSA_PKCS1_SHA2_384 successful
sending end entity cert "CN=client"
establishing CHILD_SA server{2}
generating IKE_AUTH request 1 [ IDi CERT N(INIT_CONTACT) CERTREQ IDr AUTH CPRQ(ADDR DNS) SA TSi TSr N(MOBIKE_SUP) N(NO_ADD_ADDR) N(MULT_AUTH) N(EAP_ONLY) N(MSG_ID_SYN_SUP) ]
splitting IKE message (2131 bytes) into 2 fragments
generating IKE_AUTH request 1 [ EF(1/2) ]
generating IKE_AUTH request 1 [ EF(2/2) ]
sending packet: from 192.168.0.2[4500] to 1.2.3.4[4500] (1248 bytes)
sending packet: from 192.168.0.2[4500] to 1.2.3.4[4500] (948 bytes)
received packet: from 1.2.3.4[4500] to 192.168.0.2[4500] (65 bytes)
parsed IKE_AUTH response 1 [ N(AUTH_FAILED) ]
received AUTHENTICATION_FAILED notify error
establishing connection 'server' failed

Лог с сервера:

server charon[994]: 08[CFG] loaded certificate 'CN=1.2.3.4'
server charon[994]: 13[CFG] loaded certificate 'CN=VPN CA'
server charon[994]: 15[CFG] loaded RSA private key
server charon[994]: 12[CFG] added vici pool client: 10.1.1.0, 2 entries
server charon[994]: 13[CFG]   id not specified, defaulting to cert subject 'CN=1.2.3.4'
server charon[994]: 13[CFG] added vici connection: client
server charon[994]: 11[NET] received packet: from 5.6.7.8[500] to 192.168.0.100[500] (972 bytes)
server charon[994]: 11[ENC] parsed IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) N(FRAG_SUP) N(HASH_ALG) N(REDIR_SUP) ]
server charon[994]: 11[IKE] 5.6.7.8 is initiating an IKE_SA
server charon[994]: 11[IKE] 5.6.7.8 is initiating an IKE_SA
server charon[994]: 11[CFG] selected proposal: IKE:AES_GCM_16_256/PRF_HMAC_SHA2_256/ECP_256
server charon[994]: 11[IKE] local host is behind NAT, sending keep alives
server charon[994]: 11[IKE] remote host is behind NAT
server charon[994]: 11[IKE] sending cert request for "CN=VPN CA"
server charon[994]: 11[ENC] generating IKE_SA_INIT response 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) CERTREQ N(FRAG_SUP) N(HASH_ALG) N(CHDLESS_SUP) N(MULT_AUTH) ]
server charon[994]: 11[NET] sending packet: from 192.168.0.100[500] to 5.6.7.8[500] (297 bytes)
server charon[994]: 12[NET] received packet: from 5.6.7.8[4500] to 192.168.0.100[4500] (1248 bytes)
server charon[994]: 12[ENC] parsed IKE_AUTH request 1 [ EF(1/2) ]
server charon[994]: 12[ENC] received fragment #1 of 2, waiting for complete IKE message
server charon[994]: 15[NET] received packet: from 5.6.7.8[4500] to 192.168.0.100[4500] (948 bytes)
server charon[994]: 15[ENC] parsed IKE_AUTH request 1 [ EF(2/2) ]
server charon[994]: 15[ENC] received fragment #2 of 2, reassembled fragmented IKE message (2131 bytes)
server charon[994]: 15[ENC] parsed IKE_AUTH request 1 [ IDi CERT N(INIT_CONTACT) CERTREQ IDr AUTH CPRQ(ADDR DNS) SA TSi TSr N(MOBIKE_SUP) N(NO_ADD_ADDR) N(MULT_AUTH) N(EAP_ONLY) N(MSG_ID_SYN_SUP) ]
server charon[994]: 15[IKE] received cert request for "CN=VPN CA"
server charon[994]: 15[IKE] received end entity cert "CN=client"
server charon[994]: 15[CFG] looking for peer configs matching 192.168.0.100[1.2.3.4]...5.6.7.8[CN=client]
server charon[994]: 15[CFG] no matching peer config found
server charon[994]: 15[IKE] peer supports MOBIKE
server charon[994]: 15[ENC] generating IKE_AUTH response 1 [ N(AUTH_FAILED) ]
server charon[994]: 15[NET] sending packet: from 192.168.0.100[4500] to 5.6.7.8[4500] (65 bytes)

edit: добавил лог с сервера

★★★

Конфиг сервера:

Хм, а так можно было оказывается.

Лог на клиенте:

Покажите лог с сервера.

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

Хм, а так можно было оказывается.

Не понял.

Покажите лог с сервера.

Забыл сразу добавить, отредактировал пост.

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

Не совсем понял, это для клиента указать? А куда тогда адрес сервера вбивать?

Если для клиента, то это вроде дефолт для swanctl-стиля (я так понимаю, что left и right соответствуют connections.<conn>.local_addrs и connections.<conn>.remote_addrs). Я практически без изменений брал конфиг с официальной вики (Roadwarrior scenario → swanctl.conf).

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

Я предполагал, что это в порядке вещей, т.к. айпи клиента неизвестен, так что конфиг пира генерируется. Видимо, это не так. Как тогда быть? Получается, надо каким-то образом на сервере указать, чтобы принимался ID типа CN=client?

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

Почти. Ему надо на основании «чего-то» решить, что вот этот кусок конфига относиться к этому клиенту. Но наискосок в мане чего-то аналогичного leftid | rightid в ipsec.conf и keyexchange не обнаружил. :(

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

В swanctl.conf можно указать connections.<conn>.remote.id, похоже, он работает как rightid для ipsec.conf. Пробовал указывать конкретный id клиента, но увы, всё та же ошибка.

Видимо, попробую переписать серверный конфиг в ipsec.conf-стиле: я как раз думал, что все уже много лет назад пересели на swanctl, а вот оно что.

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

попробую переписать серверный конфиг в ipsec.conf-стиле

На всякий случай кусок из моего ipsec.conf

keyexchange=ikev2
rightid="C=XXX, O=YYY, OU=ZZZ, CN=*"
* здесь означает любую последовательность

я как раз думал, что все уже много лет назад пересели на swanctl

Точно не все :) Я последний раз правил ipsec.conf всего два дня назад :) И пока его не выпилят окончательно, менять конфиги желания ровно ноль. У меня там достаточно секций под разные соединения, пусть не всё уже нужно, но мало ли...

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

Спасибо! Правда, мне по идее смысла матчить так нет: CA тестовый, поэтому я заполнил только CN и SAN. А для продакшена, конечно, полезно по OU фильтровать.

Кроме того, я переписал почти один в один серверный конфиг:

conn server
    keyexchange=ikev2
    rekey=no
    reauth=no
    fragmentation=yes
    dpdaction=clear
    dpddelay=30s
    ike=aes256gcm16-aes256gcm16-prfsha256-ecp256-ecp521,aes192-sha256-modp3072
    esp=aes256gcm16-aes256gcm16-prfsha256-ecp256-modp3072,aes192-sha256-ecp256-modp3072
    leftsubnet=0.0.0.0/0
    leftcert=/etc/swanctl/x509/server.crt
    leftsendcert=always
    rightsourceip=10.1.1.0/30
    rightdns=8.8.8.8
    auto=add

ca server-ca
    auto=add
    cacert=/etc/swanctl/x509ca/ca.crt

И, о чудо, авторизация заработала. Видимо, этот swanctl это какая-то сырая (несмотря на заверения в официальных доках) штука.

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

А для продакшена, конечно, полезно по OU фильтровать.

Для себя любимого тоже полезно. Я в OU фильтрую по разным реализациям клиентов. Например для blackbery одно, для mac os x другое и т.д.

Видимо, этот swanctl это какая-то сырая (несмотря на заверения в официальных доках) штука.

Может и так. А может документацию не дописали. ;)

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

Ага. Сама проблема в том, что это в лебеде вы можете настроить усе что угодно, а готовые реализации клиентов зачастую содержат захардкоженные наборы параметров. macOS одно, офтопик другое и т.д. Вот и приходиться под них подстраиваться.

anc ★★★★★ ()

Как оказалось, я просто невнимательно читал доки, а решение вполне есть. Разгадка в том, что при ipsec.conf-стиле с обоих сторон клиент отправляет ID сервера по дефолту в виде его IP, а сервер принимает всё. В случае с swanctl, сервер ожидает ID в виде DN его сертификата, что в чем-то более логично. swanctl-клиент также отправит ID сервера как DN серверного сертификата, полученного в результате предыдущего запроса.

Таким образом, если хочется оставить swanctl на сервере и ipsec.conf на клиенте (оригинальная задача), то достаточно на клиенте добавить rightid="CN=1.2.3.4" (1.2.3.4 – IP сервера). Или можно воспользоваться недокументированной особенностью и прописать local.id = %any на сервере. При использовании swanctl с обоих сторон специально прописывать local.id и remote.id не нужно.

Со своей стороны я решил использовать ipsec.conf с обоих сторон, т.к. swanctl выглядит гибче (мне это пока ненужно), но геморнее (например, убунтовый AppArmor по дефолту режет swanctl так, что он не загружает никаких соединений на старте системы, нужно руками делать --load-all).

@anc если вдруг интересно

lu4nik ★★★ ()
Для того чтобы оставить комментарий войдите или зарегистрируйтесь.