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

Как настроить StrongSwan для работы в качестве клиента IKEv1?

Заказчик нашего бизнеса по разработке предоставил доступ к своей IPSec VPN, предоставив необходимые учетные данные (анонимно):

Они также предоставили параметры, настроенные на их стороне:

Фаза 1

  • Аутентификация: SHA1
  • Шифрование: AES 256
  • SA Life: 1 час
  • Ключевая группа: Diffie Helman group 2
  • NAT Traversal и DPD включены
  • Интервал сохранения активности: 20 секунд

Фаза 2

  • Тип: ESP
  • Аутентификация: SHA1
  • Шифрование: AES 256
  • Срок действия принудительного ключа: 1 час

Тип подключения - IKEv1, и они настроили доступ через туннель VPN только на определенном IP 1.2.3.4, потому что это единственная машина, с которой мы должны связаться.

Цель и попытка

Я пытаюсь понять, как настроить StrongSwan для подключения к их VPN. Мне нужно, чтобы это работало на VPS с Ubuntu Server 16.04.

Я пытался следовать нескольким руководствам, но некоторые из них были для более старых версий StrongSwan, поэтому они не работали. Наконец я отредактировал /etc/ipsec.conf со следующей попыткой настройки:

config setup

conn myconn
    authby=xauthpsk
    dpdaction=restart
    esp=aes256-sha1
    ike=aes256-sha1-dh2
    ikelifetime=1h
    keyexchange=ikev1
    leftauth=psk
    leftauth2=xauth
    leftgroups=MYGROUP
    leftid=@MYUSER
    right=example.fake
    rightsubnet=1.2.3.4/32

Я создал /etc/ipsec.secrets:

: PSK "MYPSK"
MYUSER: XAUTH "MYPASSWORD"

Желаемое конечное состояние и сообщение об ошибке

Желаемое конечное состояние состоит в том, что наша машина подключается к VPN клиента, и мы можем достичь этого единственного IP-адреса 1.2.3.4. Остальной трафик должен быть разделен и не проходить через VPN.

Несмотря на то, что myconn определяется в /etc/ipsec.conf, это сообщение об ошибке появляется при попытке подключения:

# ipsec restart
Stopping strongSwan IPsec...
Starting strongSwan 5.3.5 IPsec [starter]...
# ipsec up myconn
no config named 'myconn'

Лог-файлы

Эти строки добавлены к /var/log/syslog после бега ipsec restart:

Jun  5 16:45:01 server charon: 00[DMN] signal of type SIGINT received. Shutting down
Jun  5 16:45:03 server charon: 00[DMN] Starting IKE charon daemon (strongSwan 5.3.5, Linux 4.8.0-53-generic, x86_64)
Jun  5 16:45:03 server charon: 00[CFG] disabling load-tester plugin, not configured
Jun  5 16:45:03 server charon: 00[LIB] plugin 'load-tester': failed to load - load_tester_plugin_create returned NULL
Jun  5 16:45:03 server charon: 00[CFG] dnscert plugin is disabled
Jun  5 16:45:03 server charon: 00[CFG] ipseckey plugin is disabled
Jun  5 16:45:03 server charon: 00[CFG] attr-sql plugin: database URI not set
Jun  5 16:45:03 server charon: 00[CFG] loading ca certificates from '/etc/ipsec.d/cacerts'
Jun  5 16:45:03 server charon: 00[CFG] loading aa certificates from '/etc/ipsec.d/aacerts'
Jun  5 16:45:03 server charon: 00[CFG] loading ocsp signer certificates from '/etc/ipsec.d/ocspcerts'
Jun  5 16:45:03 server charon: 00[CFG] loading attribute certificates from '/etc/ipsec.d/acerts'
Jun  5 16:45:03 server charon: 00[CFG] loading crls from '/etc/ipsec.d/crls'
Jun  5 16:45:03 server charon: 00[CFG] loading secrets from '/etc/ipsec.secrets'
Jun  5 16:45:03 server charon: 00[CFG]   loaded RSA private key from '/etc/ipsec.d/private/myKey.der'
Jun  5 16:45:03 server charon: 00[CFG] sql plugin: database URI not set
Jun  5 16:45:03 server charon: 00[CFG] opening triplet file /etc/ipsec.d/triplets.dat failed: No such file or directory
Jun  5 16:45:03 server charon: 00[CFG] eap-simaka-sql database URI missing
Jun  5 16:45:03 server charon: 00[CFG] loaded 0 RADIUS server configurations
Jun  5 16:45:03 server charon: 00[CFG] no threshold configured for systime-fix, disabled
Jun  5 16:45:03 server charon: 00[CFG] coupling file path unspecified
Jun  5 16:45:03 server charon: 00[LIB] loaded plugins: charon test-vectors unbound ldap pkcs11 aes rc2 sha1 sha2 md4 md5 rdrand random nonce x509 revocation constraints acert pubkey pkcs1 pkcs7 pkcs8 pkcs12 pgp dnskey sshkey dnscert ipseckey pem openssl gcrypt af-alg fips-prf gmp agent chapoly xcbc cmac hmac ctr ccm gcm ntru bliss curl soup mysql sqlite attr kernel-netlink resolve socket-default connmark farp stroke updown eap-identity eap-sim eap-sim-pcsc eap-aka eap-aka-3gpp2 eap-simaka-pseudonym eap-simaka-reauth eap-md5 eap-gtc eap-mschapv2 eap-dynamic eap-radius eap-tls eap-ttls eap-peap eap-tnc xauth-generic xauth-eap xauth-pam xauth-noauth tnc-tnccs tnccs-20 tnccs-11 tnccs-dynamic dhcp whitelist lookip error-notify certexpire led radattr addrblock unity
Jun  5 16:45:03 server charon: 00[LIB] dropped capabilities, running as uid 0, gid 0
Jun  5 16:45:03 server charon: 00[JOB] spawning 16 worker threads

Они добавляются после запуска ipsec up myconn:

Jun  5 16:45:21 server charon: 15[CFG] received stroke: initiate 'myconn'
Jun  5 16:45:21 server charon: 15[CFG] no config named 'myconn'

Они выглядят согласующимися с вышеупомянутым сообщением об ошибке.

Вопрос

Почему ipsec up myconn говорят, что такой конфигурации нет? Я впервые пытаюсь разобраться с IPSec VPN ... имеет ли смысл конфигурация, которую я пытался написать?

Что мне нужно изменить, чтобы он заработал?

Обновить после добавления auto=add

Как было предложено в комментариях, я добавил auto=add в мою конфигурацию. Теперь я понял:

# ipsec up myconn
initiating Main Mode IKE_SA myconn[1] to <IP of example.fake>
configuration uses unsupported authentication
tried to check-in and delete nonexisting IKE_SA
establishing connection 'myconn' failed

Эти строки добавляются к файлу журнала:

Jun  5 17:07:19 server charon: 12[CFG] received stroke: initiate 'myconn'
Jun  5 17:07:19 server charon: 14[IKE] initiating Main Mode IKE_SA myconn[2] to <IP of example.fake>
Jun  5 17:07:19 server charon: 14[CFG] configuration uses unsupported authentication
Jun  5 17:07:19 server charon: 14[MGR] tried to check-in and delete nonexisting IKE_SA

Обновить после удаления esp=, ike= и keyexchange=

После удаления трех упомянутых выше строк попытка подключения трижды повторяется следующим образом (фрагмент показывает только первую, остальные идентичны):

Jun  5 17:18:44 server charon: 06[CFG] received stroke: initiate 'myconn'
Jun  5 17:18:45 server charon: 04[IKE] initiating IKE_SA myconn[1] to <IP of example.fake>
Jun  5 17:18:45 server charon: 04[ENC] generating IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) N(HASH_ALG) ]
Jun  5 17:18:45 server charon: 04[NET] sending packet: from <our server IP>[500] to <IP of example.fake>[500] (1500 bytes)
Jun  5 17:18:49 server charon: 03[IKE] retransmit 1 of request with message ID 0
Jun  5 17:18:49 server charon: 03[NET] sending packet: from <our server IP>[500] to <IP of example.fake>[500] (1500 bytes)
Jun  5 17:18:56 server charon: 15[IKE] retransmit 2 of request with message ID 0
Jun  5 17:18:56 server charon: 15[NET] sending packet: from <our server IP>[500] to <IP of example.fake>[500] (1500 bytes)
Jun  5 17:19:09 server charon: 01[IKE] retransmit 3 of request with message ID 0
Jun  5 17:19:09 server charon: 01[NET] sending packet: from <our server IP>[500] to <IP of example.fake>[500] (1500 bytes)
Jun  5 17:19:32 server charon: 16[IKE] retransmit 4 of request with message ID 0
Jun  5 17:19:32 server charon: 16[NET] sending packet: from <our server IP>[500] to <IP of example.fake>[500] (1500 bytes)
Jun  5 17:20:14 server charon: 05[IKE] retransmit 5 of request with message ID 0
Jun  5 17:20:14 server charon: 05[NET] sending packet: from <our server IP>[500] to <IP of example.fake>[500] (1500 bytes)
Jun  5 17:21:30 server charon: 13[IKE] giving up after 5 retransmits
Jun  5 17:21:30 server charon: 13[IKE] peer not responding, trying again (2/3)

Обновление: рабочий конфиг для ShrewSoft VPN

Подключение к VPN клиента было протестировано на настольном компьютере в офисе с использованием ShrewSoft VPN, однако это не подходит для использования на разрабатываемом VPS. Указанная программа экспортировала следующую конфигурацию:

n:version:4
n:network-ike-port:500
n:network-mtu-size:1380
n:client-addr-auto:1
n:network-natt-port:4500
n:network-natt-rate:15
n:network-frag-size:540
n:network-dpd-enable:1
n:network-notify-enable:1
n:client-banner-enable:1
n:client-dns-used:1
n:client-dns-auto:1
n:client-dns-suffix-auto:1
b:auth-mutual-psk:****REMOVED****
n:phase1-dhgroup:2
n:phase1-keylen:0
n:phase1-life-secs:86400
n:phase1-life-kbytes:0
n:vendor-chkpt-enable:0
n:phase2-keylen:0
n:phase2-pfsgroup:-1
n:phase2-life-secs:3600
n:phase2-life-kbytes:0
n:policy-nailed:0
n:policy-list-auto:1
s:network-host:example.fake
s:client-auto-mode:pull
s:client-iface:virtual
s:network-natt-mode:enable
s:network-frag-mode:enable
s:auth-method:mutual-psk-xauth
s:ident-client-type:keyid
s:ident-client-data:MYGROUP
s:ident-server-type:any
s:phase1-exchange:aggressive
s:phase1-cipher:auto
s:phase1-hash:auto
s:phase2-transform:auto
s:phase2-hmac:auto
s:ipcomp-transform:disabled
s:policy-level:auto

Предлагает ли это какие-либо изменения, которые следует внести в ipsec.conf файл, чтобы это работало с StrongSwan?

Возможно, это запоздалый ответ, но вот несколько указателей на проблемы, которые я заметил (но не пробовал / не тестировал):

  • Authby устарел, и вы используете leftauth. Явная установка как leftauth / rightauth, так и leftauth2 / rightauth2 может помочь. По моему опыту (и глядя на код C на github) для IKEv1, есть только ограниченное количество проверок if / else, и когда левое и правое не совпадают (кроме любой), вы получите сообщение "неподдерживаемая аутентификация"
  • Как ни странно (и я не смотрел код C, чтобы убедиться в этом), есть утверждения, что вы должен имейте по обе стороны от ':' в ваших файлах секретов (например, 'MYUSERS: XAUTH "MYPASSWORD"', на вашем, у вас не было места в MYUSER :)
  • В зависимости от вашего дистрибутива некоторые методы шифрования могут не поддерживаться (например, 3DES) - просмотрите журнал charon на предмет наличия плагинов, чтобы узнать, что загружено.
  • Тот, кто сказал удалить «keyexchange», пропустил ваш вопрос о том, что вам нужен IKEv1. Для IKEv1 необходимо явно указать keyexchange = ikev1 ; по умолчанию - «ike», что означает и IKEv1, и IKEv2 на стороне сервера, а не на стороне клиента (то есть в качестве сервера VPN я буду принимать как v1, так и v2 моих клиентов). В вашем случае ваш ролл - это клиент, поэтому вам нужно быть откровенным.
  • Я не согласен с удалением esp = и ike =, так как вы явно указали в своем OP, что такое Phase1 (dh2 или aes256-sha1-modp2048?) И Phase2; Если у вас есть инструмент ike-scan для своего дистрибутива, используйте его. Он даже подскажет, поддерживает ли ваша конечная точка IKEv2. Обычно из ike-scan я узнаю, поддерживает ли конечная точка 3DES или нет, поскольку в некоторых дистрибутивах они больше не распространяются с 3DES как часть двоичного файла.
  • Я заметил, что для вашей конфигурации Shrewsoft вы установили agressive = yes, что вы также можете попробовать на ipsec.conf, как только вы получите работу phase2.
  • Предполагая, что ваша «левая» - это клиентская сторона, а «правая» - это удаленный шлюз, вы установили «leftid» вместо «rightid» - в основном, rightid должен соответствовать вашему файлу .secrets, если только вы намеренно не хотите, чтобы шлюз был аутентифицировать вас?

Еще несколько советов:

  • Установите для своего журнала charon в 'NET' и 'CFG' (выберите и выберите) более высокий уровень журнала в зависимости от того, что вы отлаживаете (при достаточно высоком уровне журнала вам даже не понадобится tcpdump)
  • Как упоминалось выше, очень важно, чтобы обе левое и правое совпадение auth / auth2 (даже если ваша левая сторона - клиентская), чтобы убедиться, что вы не получаете ошибок типа «конфигурация sues unsupported ...» (установка вашего 'cfg' в журнале charon здесь не поможет, у меня посмотреть код C)
  • Как кто-то упомянул, убедитесь, что у вас есть хотя бы 'auto = add' - раздача - это когда вы делаете '$статус ipsec'вы не увидите свой' conn ', если он не был добавлен

В любом случае некоторая недостающая информация, которая должна быть выведена косвенно на основе конфигураций и других журналов, которые вы, возможно, хотели предоставить ранее, чтобы избежать повторения комментариев:

  • Этап 1: PSK (предварительный доступ)
  • Фаза 2: xauth-radius

Я не совсем уверен, что использует ваш удаленный VPN-сервер, но выше предполагалось, что он основан на радиусе, поэтому убедитесь, что правильно настроили ваши xauth-плагины на его основе.

Наконец, внимательно следите за документацией Strongswan 'ipsec.conf' о том, что поддерживается в IKEv1. Кроме того, если ваша конечная точка основана на NTLM, помните, что пароли NTLM закодированы в кодировке MD4 (просто найдите что-то в смысле передачи строки UTF16 в openssl как MD4).