Strongswan VPN não funciona a menos que pingue manualmente

Navegue suas respostas
0

Nós configuramos com sucesso uma VPN strong em nossa rede para se comunicar com o Google Cloud VPN.

Às vezes, deixamos ocioso por um tempo, digamos uma noite, quando o problema aparece. Se eu tentar fazer ping do Google para a nossa rede, isso não funciona, nenhum pacote é transmitido. Se eu tentar pingar do nosso lado para o Google, ele funciona, e então o ping que foi bloqueado no lado do Google começa a funcionar bem.

Parece que o StrongSwan entra no modo de hibernação do nosso lado e só acorda quando eu pingar manualmente, não quando recebo pacotes. Mas não consigo encontrar nenhuma opção no documento para consertar isso, alguém já tem esse problema e consertou de alguma forma?

EDIT: não há firewall do nosso lado que poderia explicar esse comportamento e no lado do Google, só podemos definir o intervalo de IP permitido passar pelo firewall, nada mais. Mas como ele usa seu próprio serviço VPN para se comunicar com nosso servidor, duvido muito que ele venha deles.

Aqui está o que o status ipsec retorna antes do problema: 

net-net[72]: ESTABLISHED 113 minutes ago, 79.xxx.xxx.xxx[79.xxx.xxx.xxx]...146.xxx.xxx.xxx[146.xxx.xxx.xxx]     
net-net{255}:  INSTALLED, TUNNEL, reqid 24, ESP SPIs: c5xxxxxx 4exxxxxx     
net-net{255}:   192.168.0.0/24 192.168.17.0/24 === 10.132.0.0/20

Aqui está o que o status do ipsec retorna depois: 

Status of IKE charon daemon (strongSwan 5.3.5, Linux 4.4.0-64-generic, x86_64):  
uptime: 22 days, since Feb 27 15:21:33 2017  
malloc: sbrk 2568192, mmap 0, used 370288, free 2197904  
worker threads: 11 of 16 idle, 5/0/0/0 working, job queue: 0/0/0/0, scheduled: 11  
loaded plugins: charon aes agent attr connmark constraints dnskey fips-prf gcm md4 openssl pem pgp pkcs1 pkcs12 pkcs7 pkcs8 pubkey rc2 resolve revocation sshkey test-vectors x509 xcbc sha1 sha2 md5 gmp random nonce hmac stroke kernel-netlink socket-default updown

Listening IP addresses:  192.168.17.205  79.xxx.xxx.xxx
Connections:     
    net-net:  79.xxx.xxx.xxx...146.xxx.xxx.xxx  IKEv2, dpddelay=30s     
    net-net:   local:  [79.xxx.xxx.xxx] uses pre-shared key authentication     
    net-net:   remote: [146.xxx.xxx.xxx] uses pre-shared key authentication     
    net-net:   child:  192.168.17.0/24 192.168.0.0/24 === 10.132.0.0/20 TUNNEL, dpdaction=restart
Security Associations (1 up, 0 connecting):     
    net-net[72]: ESTABLISHED 2 hours ago, 79.xxx.xxx.xxx[79.xxx.xxx.xxx]...146.xxx.xxx.xxx[146.xxx.xxx.xxx]     
    net-net[72]: IKEv2 SPIs: 0fd4efxxxxxx 17ed000axxxxxx*, pre-shared key reauthentication in 108 minutes     
    net-net[72]: IKE proposal: AES_CBC_128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_2048     
    net-net{255}:  INSTALLED, TUNNEL, reqid 24, ESP SPIs: c5b822fe_i 4ed83bd8_o     
    net-net{255}:  AES_GCM_16_128, 3916 bytes_i (47 pkts, 1020s ago), 3956 bytes_o (47 pkts, 1020s ago), rekeying in 7 hours     
    net-net{255}:   192.168.0.0/24 192.168.17.0/24 === 10.132.0.0/20

E o ipsec.conf: 

config setup

conn %default
        ikelifetime=24h
        keylife=8h
        rekeymargin=9m
        keyingtries=1
        authby=psk
        keyexchange=ikev2
        mobike=no
        esp=aes128gcm16-modp2048!
        dpdaction=restart
conn net-net
        left=79.xxx.xxx.xxx
        leftsubnet=192.168.17.0/24,192.168.0.0/24
        leftid=79.xxx.xxx.xxx
        leftfirewall=yes
        leftdns=xxx....
        right=146.xxx.xxx.xxx
        rightsubnet=10.132.0.0/20
        rightid=146.xxx.xxx.xxx
        auto=start

E nos logs do Google, reparei que, no momento em que envio o teste de ping, ele envia algumas solicitações para recriar o CHILD_SA: 

"creating rekey job for CHILD_SA ESP/0xxxxxxxxx/79.xxx.xxx.xxx"  
...

Uma vez que o CHILD_SA é estabelecido com seu SPI, o ping passa. Embora o ESP SPI não tenha mudado antes e depois. Eu também vejo rekeying em 7 horas no status ipsec. Poderia ser a questão de que durante a noite não há atividade durante mais de 7 horas?

Aqui está o log do charon: 

Mar 22 07:56:43 vpn07 charon: 11[ENC] parsed CREATE_CHILD_SA request 223 [ N(REKEY_SA) SA No KE TSi TSr ]
Mar 22 07:56:43 vpn07 charon: 11[IKE] CHILD_SA net-net{255} established with SPIs c5b8xxxxxxx_o and TS 192.168.0.0/24 192.168.17.0/24 === 10.132.0.0/20
Mar 22 07:56:43 vpn07 charon: 11[ENC] generating CREATE_CHILD_SA response 223 [ SA No KE TSi TSr ]
Mar 22 07:56:43 vpn07 charon: 05[IKE] received DELETE for ESP CHILD_SA with SPI 7dd6xxxx
Mar 22 07:56:43 vpn07 charon: 05[IKE] closing CHILD_SA net-net{254} with SPIs ce7xxxx (95264 bytes) 7ddxxxxx (4885433 bytes) and TS 192.168.0.0/24 192.168.17.0/24 === 10.132.0.0/20
Mar 22 07:56:43 vpn07 charon: 05[IKE] sending DELETE for ESP CHILD_SA with SPI ce75xxxxx
Mar 22 07:56:43 vpn07 charon: 05[IKE] CHILD_SA closed

E os registros do google: 

D  sending DPD request 
D  CHILD_SA closed 
D  received DELETE for ESP CHILD_SA with SPI cexxxxx 
D  parsed INFORMATIONAL response 224 [ D ] 
D  received packet: from 79.xxx.xxx.xxx[500] to 146.xxx.xxx.xxx[500] (76 bytes) 
D  sending packet: from 146.xxx.xxx.xxx[500] to 79.xxx.xxx.xxx[500] (76 bytes) 
D  generating INFORMATIONAL request 224 [ D ] 
D  sending DELETE for ESP CHILD_SA with SPI 7dxxxxxx
I  closing CHILD_SA vpn_79.xxx.xxx.xxx{33} with SPIs 7dxxxxx (5073648 bytes) cexxxxxx (95264 bytes) and TS 10.132.0.0/20 === 192.168.0.0/24 192.168.17.0/24  
I  CHILD_SA vpn_79.xxx.xxx.xxx{34} established with SPIs 4exxxxxx c5xxxxxx and TS 10.132.0.0/20 === 192.168.0.0/24 192.168.17.0/24  
D  handling HA CHILD_SA vpn_79.xxx.xxx.xxx{34} 10.132.0.0/20  === 192.168.0.0/24 192.168.17.0/24  (segment in: 1*, out: 1*) 
D  parsed CREATE_CHILD_SA response 223 [ SA No KE TSi TSr ] 
D  received packet: from 79.xxx.xxx.xxx[500] to 146.xxx.xxx.xxx[500] (476 bytes) 
D  sending packet: from 146.xxx.xxx.xxx[500] to 79.xxx.xxx.xxx[500] (620 bytes) 
D  generating CREATE_CHILD_SA request 223 [ N(REKEY_SA) SA No KE TSi TSr ] 
I  establishing CHILD_SA vpn_79.xxx.xxx.xxx{1} 
D  creating rekey job for CHILD_SA ESP/0xxxxxxx/79.xxx.xxx.xxx 
D  parsed INFORMATIONAL response 222 [ ] 
D  received packet: from 79.xxx.xxx.xxx[500] to 146.xxx.xxx.xxx[500] (76 bytes) 
D  sending packet: from 146.xxx.xxx.xxx[500] to 79.xxx.xxx.xxx[500] (76 bytes) 
D  generating INFORMATIONAL request 222 [ ] 
D  sending DPD request
    
por Vincent Teyssier 21.03.2017 / 08:56

1 resposta

1

Parece que o seu cliente Strongswan VPN está protegido por um firewall ou por um dispositivo NAT que, após um momento de inatividade, cai a "conexão" (provavelmente UDP aqui, o termo "conexão" não é uma boa escolha). Quaisquer dados de entrada pertencentes a essa conexão são considerados inválidos e descartados (você pode ter uma linha sobre isso nos logs de dispositivos do FW / NAT). Mais tarde, quando você faz ping no Google por dentro, sua conexão é restabelecida e seu dispositivo de firewall / NAT agora considera novamente os dados recebidos como válidos.

A solução é evitar que o seu dispositivo de firewall / NAT derrube a "conexão" garantindo um fluxo de dados regular (uma mensagem UDP a cada minuto pode ser suficiente). Procure por qualquer mecanismo de keep-alive construído em Strongswan e ative-o.

    
por 22.03.2017 / 01:21

Tags

scp não está funcionando mascara Dólar, parênteses e aspas no comando ssh remoto [duplicado]