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

VPN-туннель Strongswan между двумя экземплярами AWS не соединяется

Я пытаюсь настроить VPN-туннель с помощью StrongSwan 5.1.2 между двумя экземплярами Amazon AWS EC2 под управлением Ubuntu 14.04.2 LTS. До использования StrongSwan я использовал open (libre) swan на AMI Amazon RedHat, который работал нормально. По какой-то причине я даже не могу заставить IKE работать здесь с StrongSwan. Я трижды проверил свои конфигурации AWS, и все выглядит хорошо, значит, проблема с конфигурацией StrongSwan.

Как вы увидите ниже, я получаю сообщение об ошибке «Ошибка записи в сокет: недопустимый аргумент». Я искал в Интернете и действительно не могу найти решение этого. Я убежден, что мой strongswan ipsec.conf настроен неправильно.

Вот с чем я работаю:

Instance #1: N.Virginia - 10.198.0.164 with public EIP 54.X.X.X
Instance #2: Oregon - 10.194.0.176 with public EIP 52.Y.Y.Y

(Простая) топология выглядит следующим образом:

[ Instance #1 within N.Virginia VPC <-> Public internet <-> Instance #2 within Oregon VPC ]

Я подтвердил правильность следующих конфигураций AWS:

Security groups permit all
IP information is correct
Src/Dest disabled on both instances
ACLs permit all
routes are present and correct (route to 10.x will point to that local instance in order to be routed out to the VPN tunnel)

Ниже /etc/ipsec.conf (это из Орегона, однако это то же самое в экземпляре N.Virginia, за исключением того, что значения left | right поменяны местами):

config setup
        charondebug="dmn 2, mgr 2, ike 2, chd 2, job 2, cfg 2, knl 2, net 2, enc 2, lib 2"
conn aws1oexternal-aws1nvexternal
        left=52.Y.Y.Y (EIP)
        leftsubnet=10.194.0.0/16
        right=54.X.X.X (EIP)
        rightsubnet=10.198.0.0/16
        auto=start
        authby=secret
        type=tunnel
        mobike=no
        dpdaction=restart

Ниже приведен /etc/ipsec.secrets * (очевидно, обратный для другого случая):

54.X.X.X 52.Y.Y.Y : PSK "Key_inserted_here"

Ниже находится /etc/strongswan.conf:

charon {
        load_modular = yes
        plugins {
                include strongswan.d/charon/*.conf
        }
}

Ниже находится /etc/sysctl.conf:

net.ipv4.ip_forward=1
net.ipv4.conf.all.accept_redirects = 0
net.ipv4.conf.all.send_redirects = 0

Вот результаты отладки из / var / log / syslog Похоже, проблема в том, что "ошибка записи в сокет: недопустимый аргумент; после всего, что я пробовал, я продолжаю получать ту же ошибку:

Jun 17 17:34:48 ip-10-198-0-164 charon: 13[IKE] retransmit 5 of request with message ID 0
Jun 17 17:34:48 ip-10-198-0-164 charon: 13[NET] sending packet: from 54.X.X.X[500] to 52.Y.Y.Y[500] (1212 bytes)
Jun 17 17:34:48 ip-10-198-0-164 charon: 03[JOB] next event in 75s 581ms, waiting]
Jun 17 17:34:48 ip-10-198-0-164 charon: 16[NET] sending packet: from 54.X.X.X[500] to 52.Y.Y.Y[500]
Jun 17 17:34:48 ip-10-198-0-164 charon: 13[MGR] checkin IKE_SA aws1vexternal-aws1oexternal[1]
Jun 17 17:34:48 ip-10-198-0-164 charon: 13[MGR] check-in of IKE_SA successful.
Jun 17 17:34:48 ip-10-198-0-164 charon: 16[NET] error writing to socket: Invalid argument
Jun 17 17:36:04 ip-10-198-0-164 charon: 03[JOB] got event, queuing job for execution
Jun 17 17:36:04 ip-10-198-0-164 charon: 03[JOB] no events, waiting
Jun 17 17:36:04 ip-10-198-0-164 charon: 08[MGR] checkout IKE_SA
Jun 17 17:36:04 ip-10-198-0-164 charon: 08[MGR] IKE_SA aws1vexternal-aws1oexternal[1] successfully checked out
Jun 17 17:36:04 ip-10-198-0-164 charon: 08[IKE] giving up after 5 retransmits
Jun 17 17:36:04 ip-10-198-0-164 charon: 08[IKE] establishing IKE_SA failed, peer not responding
Jun 17 17:36:04 ip-10-198-0-164 charon: 08[MGR] checkin and destroy IKE_SA aws1vexternal-aws1oexternal[1]
Jun 17 17:36:04 ip-10-198-0-164 charon: 08[IKE] IKE_SA aws1vexternal-aws1oexternal[1] state change: CONNECTING => DESTROYING
Jun 17 17:36:04 ip-10-198-0-164 charon: 08[MGR] check-in and destroy of IKE_SA successful

Вот то, что я пробовал до сих пор:

1) Проверенный слой 3

2) перезагруженные машины

3) Пробовал добавлять в leftid =

4) Пытался выполнить обновление ipsec, затем перезапустить ipsec

5) Пытался добавить nat_traversal = yes при настройке confif (обратите внимание, что это не имеет значения, поскольку статус ipsec все проверяется с помощью IKEv2, который, согласно документации, автоматически использует nat_traversal)

6) Пытался опустить virtual_private <- использовался в соответствии с документацией AWS openswan, поэтому я включил его в конфигурацию strongswan.

7) Попытался отключить net.ipv4.conf.all.send_redirects = 0 и net.ipv4.conf.all.accept_redirects = 0 в /etc/sysctl.conf

8) Пробовал использовать частный IP вместо EIP. Я больше не получаю ошибку сокета, однако очевидно, что два IP-адреса не могут общаться друг с другом для однорангового соединения ...

9) Пытался добавить это в strongswan.conf: load = aes des sha1 sha2 md5 gmp random nonce hmac stroke kernel-netlink socket-default updown

10) Пробовал использовать leftfirewall = да, не сработало

Пожалуйста помоги! Спасибо!

РЕДАКТИРОВАТЬ №1:

Ответ Майкла устранил исходную проблему, однако у меня возникла новая проблема, связанная с маршрутизацией. Оба экземпляра VPN не могут пинговать друг друга. Кроме того, когда я пытаюсь выполнить эхо-запрос от случайного экземпляра в любой подсети к другому случайному экземпляру или удаленному экземпляру VPN, я получаю следующий ответ на пинг:

root@ip-10-194-0-80:~# ping 10.198.0.164
PING 10.198.0.164 (10.198.0.164) 56(84) bytes of data.
From 10.194.0.176: icmp_seq=1 Redirect Host(New nexthop: 10.194.0.176)
From 10.194.0.176: icmp_seq=2 Redirect Host(New nexthop: 10.194.0.176)
From 10.194.0.176: icmp_seq=3 Redirect Host(New nexthop: 10.194.0.176)
From 10.194.0.176: icmp_seq=4 Redirect Host(New nexthop: 10.194.0.176)

Очевидно, это должна быть проблема маршрутизации между двумя экземплярами VPN (скорее всего, из-за конфигурации strongswan или таблицы маршрутизации экземпляра), поскольку хост 10.194.0.80 в подсети Oregon может получить ответ от экземпляра Oregon VPN. Таблица маршрутов + traceroute на экземпляре:

root@ip-10-194-0-80:~# netstat -rn
Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
0.0.0.0         10.194.0.1      0.0.0.0         UG        0 0          0 eth0
10.194.0.0      0.0.0.0         255.255.255.0   U         0 0          0 eth0

root@ip-10-194-0-80:~# traceroute 10.198.0.164
traceroute to 10.198.0.164 (10.198.0.164), 30 hops max, 60 byte packets
 1  10.194.0.176 (10.194.0.176)  0.441 ms  0.425 ms  0.409 ms^C

Когда я использовал openswan, мне не требовалось вносить вручную какие-либо изменения в таблицу маршрутизации каждого экземпляра.

Вот таблица маршрутизации экземпляра Oregon VPN:

root@ip-10-194-0-176:~# netstat -rn
Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
0.0.0.0         10.194.0.1      0.0.0.0         UG        0 0          0 eth0
10.194.0.0      0.0.0.0         255.255.255.0   U         0 0          0 eth0

Я немного озадачен.

РЕДАКТИРОВАТЬ № 2:

Похоже, что маршрутизация между экземплярами VPN не может быть проблемой: / var / log / syslog показывает пакеты, полученные с общедоступного IP-адреса одного экземпляра VPN на другой экземпляр VPN.

Jun 23 19:57:49 ip-10-194-0-176 charon: 10[NET] received packet: from 54.X.X.X[4500] to 10.194.0.176[4500] (76 bytes)

Похоже, это проблема, связанная с ассоциациями детской безопасности:

aws1oexternal-aws1nvexternal:   child:  10.194.0.0/16 === 10.198.0.0/16 TUNNEL, dpdaction=restart
Security Associations (1 up, 0 **connecting**):

/ var / журнал / системный журнал:

Jun 23 19:52:19 ip-10-194-0-176 charon: 02[IKE] failed to establish CHILD_SA, keeping IKE_SA
Jun 23 19:52:48 ip-10-194-0-176 charon: 11[IKE] queueing CHILD_CREATE task
Jun 23 19:52:48 ip-10-194-0-176 charon: 11[IKE]   activating CHILD_CREATE task
Jun 23 19:52:48 ip-10-194-0-176 charon: 06[IKE] establishing CHILD_SA aws1oexternal-aws1nvexternal
Jun 23 19:52:48 ip-10-194-0-176 charon: 10[IKE] received FAILED_CP_REQUIRED notify, no CHILD_SA built
Jun 23 19:52:48 ip-10-194-0-176 charon: 10[IKE] failed to establish CHILD_SA, keeping IKE_SA
Jun 23 19:52:49 ip-10-194-0-176 charon: 14[CFG] looking for a child config for 10.194.0.0/16 === 10.198.0.0/16 
Jun 23 19:52:49 ip-10-194-0-176 charon: 14[CFG] found matching child config "aws1oexternal-aws1nvexternal" with prio 10
Jun 23 19:52:49 ip-10-194-0-176 charon: 14[IKE] configuration payload negotiation failed, no CHILD_SA built
Jun 23 19:52:49 ip-10-194-0-176 charon: 14[IKE] failed to establish CHILD_SA, keeping IKE_SA

*** РЕДАКТИРОВАТЬ № 3: Проблема решена (на самом деле см. РЕДАКТИРОВАНИЕ № 4 ниже ...) ****

Проблема исправлена.

1) Я неправильно следовал указаниям Майкла по настройке. Я также настроил права на исходный код и левый источник вместе, тем самым заставив оба экземпляра поверить, что они оба были инициаторами. Я убедился, что один был инициатором, а другой - инициатором; это устранило проблему IKE.

2) Я понял, что мне также нужно явно указать параметр esp. Несмотря на то, что уже существует значение по умолчанию (aes128-sha1,3des-sha1), параметр esp все равно должен быть установлен, чтобы экземпляр знал, что использовать esp OR ah (но не оба сразу). В итоге я использовал aes128-sha1-modp2048.

Надеюсь, эта публикация поможет следующему новичку Linux настроить это !!

Ура!

РЕДАКТИРОВАТЬ # 4: проблема (не совсем) решена

При устранении отдельной проблемы, связанной с strongswan, я изменил параметр «leftfirewall», протестировал, не исправил мою отдельную проблему, а затем вернулся к исходной конфигурации заранее (закомментировал leftfirewall). Затем я заметил, что теперь не могу пересечь туннель. После нескольких часов сумасшедших попыток выяснить, что произошло, я закомментировал параметр esp, чтобы посмотреть, что произойдет: Я МОГУ СЕЙЧАС ПИНГОВАТЬ ПО ТУННЕЛЮ СНОВА! <- так что есть вероятность, что какие-то призраки ipsec бегают со мной, и что параметр esp на самом деле не является исправлением для ошибок TS_UNACCEPTABLE (хотя другие ресурсы в сети заявляют, что параметр esp является исправлением ...)

РЕДАКТИРОВАТЬ # 5: проблема полностью решена

В итоге я перенес все в тестовую среду и начал с нуля. Я установил из исходников, используя последнюю версию (5.3.2), а не старую версию, которая была в репозитории Ubuntu (5.1.2). Это устранило проблему, с которой я столкнулся выше, и проверило соединение уровня 7 с помощью netcat (отличный инструмент !!) между несколькими подсетями через туннель VPN.

Также: это НЕ требуется для включения имен хостов DNS для VPC (как меня ошибочно предположила Amazon), к сведению>

Надеюсь, все это поможет !!!!!!

Дополнительное редактирование 2/11/2017:

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

Сторона А:

# ipsec.conf - strongSwan IPsec configuration file

# basic configuration
config setup
# Add connections here.
conn %default
 ikelifetime= You choose; must match other side
 keylife= You choose; must match other side
 rekeymargin= You choose; must match other side
 keyingtries=1
 keyexchange= You choose; must match other side
 authby=secret
 mobike=no

conn side-a
 left=10.198.0.124
 leftsubnet=10.198.0.0/16
 leftid=54.y.y.y
 leftsourceip=10.198.0.124
 right=52.x.x.x
 rightsubnet=10.194.0.0/16
 auto=start
 type=tunnel
# Add connections here.


root@x:~# cat /etc/ipsec.secrets 
A.A.A.A B.B.B.B : PSK "Your Password"

Сторона B:

# ipsec.conf - strongSwan IPsec configuration file

# basic configuration
config setup

conn %default
 ikelifetime= You choose; must match other side
 keylife= You choose; must match other side
 rekeymargin= You choose; must match other side
 keyingtries=1
 keyexchange= You choose; must match other side
 authby=secret
 mobike=no

conn side-b
 left=10.194.0.129
 leftsubnet=10.194.0.0/16
 leftid=52.x.x.x
 right=54.y.y.y
 rightsubnet=10.198.0.0/16
 rightsourceip=10.198.0.124
 auto=start
 type=tunnel

root@x:~# cat /etc/ipsec.secrets 
B.B.B.B A.A.A.A : PSK "Your Password"

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

left=10.10.10.10         # instance private IP of local system
leftsourceip=10.10.10.10 # instance private IP of local system
leftid=203.x.x.x         # elastic IP of local system
leftsubnet=10.x.x.x/xx

rightsubnet=10.x.x.x/xx
right=198.x.x.x          # elastic IP of remote system

Проблема исправлена.

1) Я неправильно следовал инструкциям Майкла по настройке. Я также настроил права на исходный код и leftsourceip вместе, тем самым заставив оба экземпляра поверить, что они оба были инициаторами. Я убедился, что один был инициатором, а другой - инициатором; это устранило проблему IKE.

2) Я понял, что мне также нужно явно указать параметр esp. Несмотря на то, что уже существует значение по умолчанию (aes128-sha1,3des-sha1), параметр esp все равно должен быть установлен, чтобы экземпляр знал, что использовать esp OR ah (но не оба сразу). В итоге я использовал aes128-sha1-modp2048.