Próbuję skonfigurować tunel VPN za pomocą StrongSwan 5.1.2 między dwiema instancjami Amazon AWS EC2 z systemem Ubuntu 14.04.2 LTS. Przed użyciem StrongSwan użyłem otwartego (darmowego) łabędzia na Amazon RedHat AMI, który działał dobrze. Z jakiegoś powodu nie mogę nawet zmusić IKE do pracy tutaj dla StrongSwan. Potrójnie sprawdziłem konfiguracje AWS i wszystko wygląda dobrze, więc to musi być problem z konfiguracją StrongSwan.
Jak zobaczysz poniżej, pojawia się błąd: „Błąd zapisu do gniazda: nieprawidłowy argument” . Szukałem w Internecie i naprawdę nie mogę znaleźć rozwiązania tego problemu. Jestem przekonany, że mój strongswan ipsec.conf jest nieprawidłowo skonfigurowany.
Oto z czym pracuję:
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
(Prosta) topologia jest następująca:
[ Instance #1 within N.Virginia VPC <-> Public internet <-> Instance #2 within Oregon VPC ]
Sprawdziłem, czy następujące konfiguracje AWS są poprawne:
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)
Poniżej znajduje się plik /etc/ipsec.conf (pochodzi z Oregonu, jednak jest taki sam w instancji N.Virginia, z tym że wartości lewej | prawej są odwrócone) :
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
Poniżej znajduje się plik /etc/ipsec.secrets * (oczywiście odwrócony dla innych instancji):
54.X.X.X 52.Y.Y.Y : PSK "Key_inserted_here"
Poniżej znajduje się plik /etc/strongswan.conf:
charon {
load_modular = yes
plugins {
include strongswan.d/charon/*.conf
}
}
Poniżej znajduje się plik /etc/sysctl.conf:
net.ipv4.ip_forward=1
net.ipv4.conf.all.accept_redirects = 0
net.ipv4.conf.all.send_redirects = 0
Oto dane wyjściowe debugowania z / var / log / syslog. Wygląda na to, że problemem jest „błąd zapisu do gniazda: Nieprawidłowy argument; po wszystkim, co próbowałem, nadal pojawia się ten sam błąd :
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
Poniżej jest to, co próbowałem do tej pory:
1) Zweryfikowana warstwa 3
2) ponownie uruchomione maszyny
3) Próbowałem dodać leftid =
4) Próbowałem wykonać aktualizację ipsec, a następnie ponownie uruchomić ipsec
5) Próbowałem dodać nat_traversal = tak w konfiguracji confif (pamiętaj, że nie powinno to mieć znaczenia, ponieważ ipsec statusall zweryfikowano za pomocą IKEv2, który zgodnie z dokumentacją automatycznie używa nat_traversal)
6) Próbowałem pominąć virtual_private <- Użyłem zgodnie z dokumentacją AWS openswan, więc zawarłem go w konfiguracji strongswan.
7) Próbowałem wyłączyć net.ipv4.conf.all.send_redirects = 0 i net.ipv4.conf.all.accept_redirects = 0 w /etc/sysctl.conf
8) Próbowałem użyć prywatnego adresu IP zamiast EIP. Nie pojawia się już błąd gniazda, ale oczywiście dwa adresy IP nie mogą się ze sobą komunikować, aby nawiązać połączenie ...
9) Próbowałem dodać to do strongswan.conf: load = aes des sha1 sha2 md5 gmp random nonce hmac stroke kernel-netlink socket-default updown
10) Próbowałem użyć leftfirewall = tak, nie działało
Proszę pomóż! Dzięki!
EDYCJA 1:
Odpowiedź Michaela usunęła pierwotny problem, jednak mam nowy problem związany z routingiem. Oba wystąpienia VPN nie mogą pingować się nawzajem. Ponadto, gdy próbuję wykonać polecenie ping z przypadkowej instancji w dowolnej podsieci, innej losowej instancji lub odległej instancji VPN, otrzymuję następującą odpowiedź 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)
Oczywiście musi to być problem z routingiem między dwoma instancjami VPN (najprawdopodobniej z powodu konfiguracji lub tabeli routingu instancji strongswan), ponieważ host 10.194.0.80 w podsieci Oregon jest w stanie odebrać odpowiedź z instancji Oregon VPN. Tabela tras + traceroute w instancji:
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
Kiedy korzystałem z openswan, nie wymagało to ode mnie ręcznych modyfikacji w tabeli routingu każdej instancji.
Oto tabela routingu instancji 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
Jestem trochę zakłopotany.
EDYCJA 2:
Wygląda na to, że routing między instancjami VPN może nie stanowić problemu: / var / log / syslog pokazuje, że pakiety są odbierane z jednego publicznego adresu IP instancji VPN do drugiej instancji 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)
Wygląda na to, że jest to problem związany z Child Security Associations:
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
*** EDYCJA nr 3: Problem rozwiązany (tak, patrz EDYCJA nr 4 poniżej ...) ****
Problem rozwiązany.
1) Nie postępowałem właściwie zgodnie ze wskazówkami konfiguracyjnymi Michaela. Skonfigurowałem też wspólnie plik rightsourceip i leftsourceip, powodując w ten sposób, że oba instancje uważają, że oba były inicjatorami. Zapewniłem, że jeden był inicjatorem, a drugi wnioskodawcą; rozwiązało to problem IKE.
2) Zrozumiałem, że musiałem również wyraźnie ustawić parametr esp. Mimo że istnieje już wartość domyślna (aes128-sha1,3des-sha1), parametr esp wciąż musi być ustawiony, aby instancja wiedziała, że używa esp OR ah (ale nie obu). Skończyło się na użyciu aes128-sha1-modp2048.
Mam nadzieję, że ten post pomoże następnemu nowicjuszowi w Linuksie to skonfigurować !!
Twoje zdrowie!
EDYCJA 4: Problem (nie bardzo) rozwiązany
Podczas rozwiązywania osobnego problemu związanego z strongswan, zmieniłem parametr „leftfirewall”, przetestowałem, nie naprawiłem mojego osobnego problemu, a następnie wróciłem z powrotem do konfiguracji orig (skomentowałem firewall po lewej). Potem zauważyłem, że nie mogę teraz pingować przez tunel. Po wielu godzinach szaleństwa, próbując dowiedzieć się, co się stało, skomentowałem parametr esp, aby zobaczyć, co się stanie: MOGĘ TERAZ ZWRÓCIĆ PONOWNIE TUNEL! <- więc istnieje możliwość, że niektóre duchy ipsec biegają wokół mnie, grając na mnie i że parametr esp nie jest naprawą błędu TS_UNACCEPTABLE (chociaż w innych zasobach stan online parametr esp jest poprawką ...)
EDYCJA 5: Problem w pełni rozwiązany
Skończyłem przenosząc wszystko do środowiska testowego i zaczynając od zera. Zainstalowałem ze źródła używając najnowszej wersji (5.3.2) zamiast starszej wersji, która była w repozytorium Ubuntu (5.1.2). To rozwiązało problem, który miałem powyżej, i zweryfikowałem łączność warstwy 7 za pomocą netcat (świetne narzędzie !!) między wieloma podsieciami w tunelu VPN.
Ponadto: NIE jest wymagane włączenie nazw hostów DNS dla VPC (jak błędnie mnie uwierzyło Amazon), FYI>
Mam nadzieję, że to wszystko pomaga !!!!!!
Dodatkowa edycja 2/11/2017:
Zgodnie z prośbą JustEngland, skopiuj poniżej działającą konfigurację (pomijając pewne szczegóły, aby w jakikolwiek sposób zapobiec identyfikacji):
Strona 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"
Strona 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"
Odpowiedzi:
W VPC publiczny adres IP instancji nigdy nie jest powiązany ze stosem instancji, więc musisz skonfigurować zarówno wewnętrzny adres prywatny, jak i zewnętrzny adres publiczny. Niepoprawny argument jest przypuszczalnie spowodowane próbuje ruchu źródłowego bezpośrednio z publicznym adresem IP, który nie jest znany do instancji.
źródło
Problem rozwiązany.
1) Nie postępowałem właściwie zgodnie ze wskazówkami konfiguracyjnymi Michaela. Skonfigurowałem też wspólnie plik rightsourceip i leftsourceip, powodując w ten sposób, że oba instancje uważają, że oba były inicjatorami. Zapewniłem, że jeden był inicjatorem, a drugi wnioskodawcą; rozwiązało to problem IKE.
2) Zrozumiałem, że musiałem również wyraźnie ustawić parametr esp. Mimo że istnieje już wartość domyślna (aes128-sha1,3des-sha1), parametr esp wciąż musi być ustawiony, aby instancja wiedziała, że używa esp OR ah (ale nie obu). Skończyło się na użyciu aes128-sha1-modp2048.
źródło