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

Я пытаюсь создать туннель VPN с помощью StrongSwan 5.1.2 между двумя Amazon экземпляры AWS EC2 под управлением Ubuntu 14.04.2 LTS. До использования StrongSwan я использовал открытый (Весы) лебедь на Redhat Amazon 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 statusall проверенное использование IKEv2, который согласно документации автоматически использует nat_traversal),

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

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

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

9) Испытанное добавление этого к strongswan.conf: загрузитесь = AES GMP des sha1 sha2 md5 случайный данный случай hmac штриховое значение по умолчанию сокета ядра-netlink updown

10) Испытанное использование leftfirewall=yes, не работал

Помогите!Спасибо!

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

Ответ Michael очистил исходную проблему, однако мне связали новую проблему с маршрутизацией. Оба экземпляра VPN не могут проверить с помощью ping-запросов друг друга. Кроме того, когда я пытаюсь проверить с помощью ping-запросов от случайного экземпляра в любой подсети, или к другому случайному экземпляру или к экземпляру 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 хоста в Орегонской подсети могут получить ответ от Орегонского экземпляра 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: решенная проблема (uhh, на самом деле посмотрите РЕДАКТИРОВАНИЕ № 4 ниже...), ****

Проблема решена.

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

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

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

Удачи!

РЕДАКТИРОВАНИЕ № 4: проблема (не действительно) решенный

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

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

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

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

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

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