☰

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

tag-icon • tag-icon vpn amazon-web-services ipsec ubuntu-14.04 strongswan
Туннель Strongswan VPN между двумя экземплярами AWS не подключается

Я пытаюсь настроить VPN-туннель с помощью StrongSwan 5.1.2 между двумя экземплярами Amazon AWS EC2 под управлением Ubuntu 14.04.2 LTS. До использования StrongSwan я использовал open(libre)swan на Amazon RedHat AMI, который работал нормально. По какой-то причине я даже не могу заставить 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 (это из Орегона, однако то же самое происходит и в экземпляре Северной Вирджинии, за исключением того, что значения 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 в настройках конфигурации (обратите внимание, что это не должно иметь значения, так как ipsec statusall проверен с помощью 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=yes, не помогло

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

ПРАВКА №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, мне не требовалось вносить какие-либо изменения вручную в таблицу маршрутизации каждого экземпляра.

Вот таблица маршрутизации экземпляра 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/log/syslog:

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) Я не следовал указаниям Майкла по настройке. Я также настроил rightsourceip и leftsourceip вместе, тем самым заставив оба экземпляра считать, что они оба являются инициаторами. Я убедился, что один из них был инициатором, а другой — запросчиком; это исправило проблему IKE.

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

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

Ваше здоровье!

EDIT #4: Проблема (на самом деле) не решена

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

EDIT #5: Проблема полностью решена

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

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

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

Дополнительная правка 11.02.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"

Сторона Б:

# 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"

решение1

В 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

решение2

Проблема устранена.

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

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

Связанный контент