Вопросы Теги

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

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

  • Шлюз: example.fake
  • Группа: MYGROUP
  • Пользователь: MYUSER
  • Пароль: MYPASSWORD
  • PSK: MYPSK

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

Фаза 1

  • Аутентификация: SHA1
  • Шифрование: AES 256
  • Срок службы SA: 1 час
  • Группа ключей: Группа Диффи Хелмана 2
  • Включены обход NAT и DPD
  • Интервал сохранения активности: 20 секунд

Фаза 2

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

Тип подключения - IKEv1, и они настроили доступ через VPN туннель только на зр ecific 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.секреты : 

: 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?

2
задан 7 June 2017 в 16:12
1 ответ

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

  • authby устарел, и вы используете leftauth. Явная установка как leftauth / rightauth, так и leftauth2 / rightauth2 может помочь. По моему опыту (и глядя на код C на github) для IKEv1, есть только ограниченное количество проверок if / else, и когда левое и правое не совпадают (кроме any ), вы получить сообщение «неподдерживаемая аутентификация»
  • Как ни странно (и я не смотрел код 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 после того, как вы заработаете Phase 2.
  • Предполагая, что ваша «левая» - это сторона клиента, а «правая» - это удаленный шлюз, вы установили 'leftid' вместо 'rightid' - в основном, rightid должен соответствовать вашему файлу .secrets, если только вы намеренно не хотите, чтобы шлюз аутентифицировал вас?

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

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

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

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

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

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

1
ответ дан 3 December 2019 в 12:36

Теги

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