O túnel de VPN do Strongswan entre duas instâncias da AWS não se conectará

10

Estou tentando configurar um túnel VPN usando o StrongSwan 5.1.2 entre duas instâncias do Amazon AWS EC2 executando o Ubuntu 14.04.2 LTS. Antes de usar o StrongSwan, usei o cisne aberto (libre) em um Amazon RedHat AMI, que funcionou bem. Por alguma razão, eu nem consigo fazer o IKE trabalhar aqui para o StrongSwan. Eu verifiquei três vezes minhas configurações da AWS e tudo parece bom, portanto, deve haver um problema com a configuração do StrongSwan.

Como você verá abaixo, o erro que estou recebendo é "Erro ao gravar no soquete: argumento inválido" . Procurei on-line e realmente não consigo encontrar a solução para isso. Estou convencido de que o ipsec.conf do strongswan está configurado incorretamente.

Aqui está o que eu estou trabalhando:

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

A topologia (simples) é a seguinte:

[ Instance #1 within N.Virginia VPC <-> Public internet <-> Instance #2 within Oregon VPC ]

Eu verifiquei que as seguintes configurações da AWS estão corretas:

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)

Abaixo está o /etc/ipsec.conf (este é do Oregon, no entanto, é o mesmo na instância N.Virginia, exceto que os valores da esquerda | direita são revertidos) :

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

Abaixo está o /etc/ipsec.secrets * (revertido para outra instância, obviamente):

54.X.X.X 52.Y.Y.Y : PSK "Key_inserted_here"

Abaixo está o /etc/strongswan.conf:

charon {
        load_modular = yes
        plugins {
                include strongswan.d/charon/*.conf
        }
}

Abaixo está o /etc/sysctl.conf:

net.ipv4.ip_forward=1
net.ipv4.conf.all.accept_redirects = 0
net.ipv4.conf.all.send_redirects = 0

Aqui está a saída de depuração de / var / log / syslog Parece que o problema aqui é "erro ao gravar no soquete: Argumento inválido; depois de tudo o que tentei, continuo recebendo o mesmo erro :

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

Abaixo está o que eu tentei até agora:

1) Camada verificada 3

2) máquinas reiniciadas

3) Tentei adicionar no leftid =

4) Tentei atualizar o ipsec e reiniciar o ipsec

5) Tentei adicionar nat_traversal = yes na configuração do confif (observe que isso não deve importar, pois o status do ipsec foi verificado usando o IKEv2, que de acordo com a documentação usa o nat_traversal automaticamente)

6) Tentei omitir virtual_private <- Foi usado de acordo com a documentação do AWS openswan, por isso o incluí na configuração do strongswan.

7) Tentei desativar o net.ipv4.conf.all.send_redirects = 0 e net.ipv4.conf.all.accept_redirects = 0 no /etc/sysctl.conf

8) Tentei usar IP privado em vez de EIPs. Eu não recebo mais o erro do soquete, no entanto, obviamente, os dois IPs não podem se comunicar entre si para observar ...

9) Tentei adicionar isso ao strongswan.conf: load = aes des sha1 sha2 md5 gmp aleatório nonce hmac stroke kernel-netlink socket-default updown

10) Tentei usar leftfirewall = sim, não funcionou

Por favor ajude! Obrigado!

EDIT # 1:

A resposta de Michael resolveu o problema original, no entanto, tenho um novo problema relacionado ao roteamento. As duas instâncias da VPN não conseguem executar ping uma na outra. Além disso, quando tento executar o ping de uma instância aleatória em qualquer sub-rede, em outra instância aleatória ou na instância VPN remota, recebo a seguinte resposta de 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)

Obviamente, esse deve ser um problema de roteamento entre as duas instâncias da VPN (provavelmente devido à configuração do strongswan ou à tabela de roteamento de instância), pois o host 10.194.0.80 na sub-rede do Oregon pode receber uma resposta da instância da VPN do Oregon. Tabela de rotas + traceroute na instância:

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

Quando eu estava usando o openswan, não era necessário fazer modificações manuais na tabela de roteamento de cada instância.

Aqui está a tabela de roteamento da instância da VPN do Oregon:

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

Estou um pouco perplexo.

EDIT # 2:

Parece que o roteamento entre as instâncias da VPN pode não ser o problema: / var / log / syslog mostra pacotes sendo recebidos de um IP público da instância da VPN para a outra instância da 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)

Parece que é um problema relacionado às associações de segurança infantil:

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

*** EDIÇÃO # 3: Problema resolvido (na verdade, veja EDIÇÃO # 4 abaixo ...) ****

Problema resolvido.

1) Não segui corretamente as instruções de configuração de Michael. Também configurei um sourceourceip e leftsourceip juntos, fazendo com que ambas as instâncias acreditassem que eram ambas iniciadoras. Eu assegurei que um fosse um iniciador e um fosse um solicitante; isso corrigiu o problema do IKE.

2) Eu descobri que também precisava definir explicitamente o parâmetro esp. Embora já exista um padrão (aes128-sha1,3des-sha1), o parâmetro esp ainda precisa ser definido para que a instância saiba usar esp OR ah (mas não ambos). Acabei usando aes128-sha1-modp2048.

Espero que esta publicação ajude o próximo novato linux a configurar isso !!

Felicidades!

EDIT # 4: Problema (não realmente) resolvido

Enquanto solucionava um problema separado relacionado ao strongswan, alterei o parâmetro "leftfirewall", testei, não resolvi meu problema separado e, em seguida, voltei à configuração original (comentado no leftfirewall). Percebi então que agora não podia fazer ping no túnel. Depois de ficar louco por horas tentando descobrir o que aconteceu, comentei o parâmetro esp para ver o que aconteceria: Agora posso agora pular através do túnel novamente! <- então, existe a possibilidade de haver alguns fantasmas ipsec correndo por aí, fazendo truques comigo e que o parâmetro esp não seja realmente a correção para os erros TS_UNACCEPTABLE (embora outros recursos online indiquem que o parâmetro esp é a correção ...)

EDIT # 5: Problema totalmente resolvido

Acabei movendo tudo para um ambiente de teste e começando do zero. Eu instalei a partir da fonte usando a versão mais recente (5.3.2) em vez da versão mais antiga que estava no repositório Ubuntu (5.1.2). Isso resolveu o problema que eu estava tendo acima e verifiquei a conectividade da camada 7 usando o netcat (ótima ferramenta !!) entre várias sub-redes no túnel da VPN.

Além disso: NÃO é necessário ativar nomes de host DNS para a VPC (como fui incorretamente levado a acreditar pela Amazon), FYI>

Espero que tudo isso ajude !!!!!!

Edição adicional 11/11/2017:

Conforme a solicitação da JustEngland, copie a configuração de trabalho abaixo (deixando de fora alguns detalhes para impedir a identificação de qualquer forma):

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

Lado 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"
vpn  amazon-web-services  ipsec  ubuntu-14.04  strongswan 
— lobi
fonte
Você pode postar a configuração de trabalho.
— JustEngland
com certeza, adicionarei a configuração como uma edição à minha pergunta original. Observe que eu não tenho mais acesso à configuração, portanto não posso verificar 100% se as configurações estão corretas; no entanto, eles devem ser :)
— Lobi

Respostas:

7

Na VPC, o endereço IP público de uma instância nunca está vinculado à pilha da instância; portanto, você deve configurar o endereço privado interno e o endereço público externo. O argumento inválido é presumivelmente causado pela tentativa de tráfego de origem diretamente a partir do endereço IP público, que não é conhecido por sua instância.

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
— Michael - sqlbot
fonte
Oi Michael, isso corrigiu o problema original, mas agora parece que há um problema de roteamento causado pela configuração do strongswan. Não consigo executar ping de uma instância da VPN para outra instância de tempo limite (timeouts) e, se tentar executar o ping de uma instância diferente da sub-rede, obtenho o seguinte: De 10.194.0.176: icmp_seq = 4 Redirect Host (New nexthop: 10.194.0.176)
— lobi
Eu editei meu post original
— lobi
Descobri isso. Não implementei a configuração de Michaels corretamente (também incluí o rightsourceip, confundindo, portanto, qual era o iniciador e qual era o solicitante). Eu também precisava definir explicitamente o parâmetro esp.
— Lobi
1

Problema resolvido.

1) Não segui corretamente as instruções de configuração de Michael. Também configurei um sourceourceip e leftsourceip juntos, fazendo com que ambas as instâncias acreditassem que eram ambas iniciadoras. Eu assegurei que um fosse um iniciador e um fosse um solicitante; isso corrigiu o problema do IKE.

2) Eu descobri que também precisava definir explicitamente o parâmetro esp. Embora já exista um padrão (aes128-sha1,3des-sha1), o parâmetro esp ainda precisa ser definido para que a instância saiba usar esp OR ah (mas não ambos). Acabei usando aes128-sha1-modp2048.

— lobi
fonte
Não tenho certeza se isso é 100% corrigido. Veja a edição nº 4 da postagem original.
— Lobi
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.