Я намагаюся налаштувати тунель 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"