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


10

Я намагаюся налаштувати тунель VPN за допомогою StrongSwan 5.1.2 між двома екземплярами Amazon AWS EC2 під управлінням Ubuntu 14.04.2 LTS. До використання StrongSwan я використовував відкритий (вільний) лебідь на 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 (це з Орегону, однак це те саме в екземплярі N.Virginia, за винятком того, що ліві | праві значення перевернуті) :

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 = так у налаштуваннях confif (зауважте, що це не має значення, оскільки статус ipsec перевіряється за допомогою IKEv2, який згідно документації автоматично використовує nat_traversal)

6) Спробував опустити virtual_private <- використовувався відповідно до документації AWS openswan, тому я включив його в configs 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 випадковий не hmac обведення ядро-netlink socket-за замовчуванням updown

10) Спробував за допомогою leftfirewall = так, не вийшло

Будь ласка, допоможіть! Дякую!

ЗРІД №1:

Відповідь Майкла очистила початкову проблему, однак у мене з’явилася нова проблема, пов’язана з маршрутизацією. Обидва екземпляри VPN не в змозі пінгувати один одного. Крім того, коли я намагаюся пінг від випадкового екземпляра в будь-якій підмережі, або в інший випадковий екземпляр, або в інший екземпляр VPN, я отримую наступну відповідь ping:

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 config або таблицю маршрутизації екземплярів), оскільки хост 10.194.0.80 у підмережі Орегон може отримати відповідь від екземпляра VPN Oregon. Таблиця маршрутів + ​​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 / 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

*** EDIT № 3: Проблема вирішена (е. Насправді див. EDIT №4 нижче ...) ****

Виправлена ​​проблема.

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

2) Я зрозумів, що мені також явно потрібно встановити параметр esp. Незважаючи на те, що вже існує за замовчуванням (aes128-sha1,3des-sha1), параметр esp все одно повинен бути встановлений для того, щоб екземпляр знав використовувати esp OR ах (але не обидва). Я в кінцевому підсумку використовував aes128-sha1-modp2048.

Сподіваюсь, що ця публікація допомагає черговому новачкові Linux налаштувати це !!

Ура!

РЕДАКТ №4: Проблема (не дуже) вирішена

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

РЕДАКТ № 5: Проблема повністю вирішена

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

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

Сподіваюся, що це все допомагає !!!!!!

Додаткова редакція 11.02.2017:

Відповідно до запиту JustEngland, скопіюйте робочу конфігурацію нижче (залишаючи деякі деталі, щоб будь-яким чином запобігти ідентифікації):

Сторона A:

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

Чи можете ви опублікувати робочу конфігурацію.
JustEngland

звичайно, додасть конфігурацію як редагування до мого початкового запитання. Зверніть увагу, що у мене більше немає доступу до налаштування, тому я не можу перевірити на 100%, чи правильно налаштовані конфігурації; однак, вони повинні бути :)
lobi

Відповіді:


7

У 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

Привіт Майкл, це вирішило оригінальну проблему, однак тепер, здається, є проблема маршрутизації, викликана конфігурацією strongswan. Я не в змозі пінгувати від одного екземпляра VPN до іншого екземпляра VPN (таймаути), і якщо я спробую виконати пінг із іншого екземпляра з підмережі, я отримаю наступне: Від 10.194.0.176: icmp_seq = 4 Хост перенаправлення (Новий nexthop: 10.194.0.176)
лобі

Я відредагував своє первісне повідомлення
lobi

Зрозумів це. Я неправильно реалізував конфігурацію Майкласа (я також включив права джерела, тим самим плутаючи, хто з них був ініціатором, а хто запитувачем). Я ТАКОЖ потребував явного встановлення параметра esp.
лобі

1

Виправлена ​​проблема.

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

2) Я зрозумів, що мені також явно потрібно встановити параметр esp. Незважаючи на те, що вже існує за замовчуванням (aes128-sha1,3des-sha1), параметр esp все одно повинен бути встановлений для того, щоб екземпляр знав використовувати esp OR ах (але не обидва). Я в кінцевому підсумку використовував aes128-sha1-modp2048.


Не впевнений, чи це на 100% фіксовано. Дивіться редагування №4 в оригінальній публікації.
lobi
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.