Я пытаюсь настроить 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 (он из Орегона, однако он аналогичен экземпляру 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 status проверен с использованием 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 Случайное nonce Штрих-код ядра-netlink Обновление по умолчанию для сокета
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 или таблицы маршрутизации экземпляров), поскольку хост 10.194.0.80 в подсети Oregon может получать ответ от экземпляра Oregon VPN. Таблица маршрутов + трассировка на экземпляре:
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**):
/ Вар / Журнал / системный журнал:
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 OR ah (но не оба). В итоге я использовал 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>
Надеюсь, что все это помогает !!!!!!
Дополнительное редактирование 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"
Сторона Б:
# 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"