ipsec blocos de túnel do google services

1

Eu configurei um respondedor strong no debian na GCE. Eu posso me conectar a ele através do aplicativo strongswan no android. Sem problemas. Eu também posso conectar usando o cliente vpn nativo no Windows 10. E quando eu faço, o respondedor se torna meu gateway padrão. (O ponto inteiro desta operação). Eu posso acessar a maior parte da internet desta forma, mas não há serviços do Google. Nenhum motor de busca, gmail, youtube etc. pp. Um site que está sendo executado no GCE também está acessível. Esse site quer que as fontes do google sejam carregadas. Isso falha.

Alguém tem uma ideia do porquê isso está acontecendo?

/etc/ipsec.conf:

    config setup
    charondebug="ike 1, knl 1, cfg 0"
    uniqueids=never

conn AndroidCon
    auto=add
    compress=no
    type=tunnel
    keyexchange=ikev2
    fragmentation=yes
    forceencaps=yes
    ike=aes128-sha256-ecp256,aes256-sha384-ecp384,aes128-sha256-modp2048,aes128-sha1-modp2048,aes256-sha384-modp4096,aes256-sha256-modp4096,aes256-sha1-mo$
    esp=aes128gcm16-ecp256,aes256gcm16-ecp384,aes128-sha256-ecp256,aes256-sha384-ecp384,aes128-sha256-modp2048,aes128-sha1-modp2048,aes256-sha384-modp4096$
    dpdaction=clear
    dpddelay=300s
    rekey=no
    left=%any
    leftid=%defaultroute
    leftcert=/etc/ipsec.d/certs/cert.pem
    leftsendcert=always
    leftsubnet=0.0.0.0/0
    right=%any
    rightid=%any
    rightauth=eap-mschapv2
    rightdns=8.8.8.8,8.8.4.4
    rightsourceip=172.31.0.0/24
    rightsendcert=never
    eap_identity=%identity

Log do servidor quando a janela é conectada:

    Jul 16 07:22:03 vpn-gateway ipsec[2578]: 07[NET] received packet: from x.x.x.x[15246] to 10.0.0.2[500] (384 bytes)
Jul 16 07:22:03 vpn-gateway ipsec[2578]: 07[ENC] parsed IKE_SA_INIT request 0 [ SA KE No N(FRAG_SUP) N(NATD_S_IP) N(NATD_D_IP) V V V V ]
Jul 16 07:22:03 vpn-gateway ipsec[2578]: 07[IKE] received MS NT5 ISAKMPOAKLEY v9 vendor ID
Jul 16 07:22:03 vpn-gateway ipsec[2578]: 07[IKE] received MS-Negotiation Discovery Capable vendor ID
Jul 16 07:22:03 vpn-gateway ipsec[2578]: 07[IKE] received Vid-Initial-Contact vendor ID
Jul 16 07:22:03 vpn-gateway ipsec[2578]: 07[ENC] received unknown vendor ID: 01:52:8b:bb:c0:06:96:12:18:49:ab:9a:1c:5b:2a:51:00:00:00:02
Jul 16 07:22:03 vpn-gateway ipsec[2578]: 07[IKE] x.x.x.x is initiating an IKE_SA
Jul 16 07:22:03 vpn-gateway ipsec[2578]: 07[IKE] local host is behind NAT, sending keep alives
Jul 16 07:22:03 vpn-gateway ipsec[2578]: 07[IKE] remote host is behind NAT
Jul 16 07:22:03 vpn-gateway ipsec[2578]: 07[ENC] generating IKE_SA_INIT response 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) N(FRAG_SUP) N(MULT_AUTH) ]
Jul 16 07:22:03 vpn-gateway ipsec[2578]: 07[NET] sending packet: from 10.0.0.2[500] to x.x.x.x[15246] (288 bytes)
Jul 16 07:22:03 vpn-gateway ipsec[2578]: 08[NET] received packet: from x.x.x.x[6511] to 10.0.0.2[4500] (580 bytes)
Jul 16 07:22:03 vpn-gateway ipsec[2578]: 08[ENC] parsed IKE_AUTH request 1 [ EF(1/3) ]
Jul 16 07:22:03 vpn-gateway ipsec[2578]: 08[ENC] received fragment #1 of 3, waiting for complete IKE message
Jul 16 07:22:03 vpn-gateway ipsec[2578]: 05[NET] received packet: from x.x.x.x[6511] to 10.0.0.2[4500] (580 bytes)
Jul 16 07:22:03 vpn-gateway ipsec[2578]: 05[ENC] parsed IKE_AUTH request 1 [ EF(2/3) ]
Jul 16 07:22:03 vpn-gateway ipsec[2578]: 05[ENC] received fragment #2 of 3, waiting for complete IKE message
Jul 16 07:22:03 vpn-gateway ipsec[2578]: 06[NET] received packet: from x.x.x.x[6511] to 10.0.0.2[4500] (132 bytes)
Jul 16 07:22:03 vpn-gateway ipsec[2578]: 06[ENC] parsed IKE_AUTH request 1 [ EF(3/3) ]
Jul 16 07:22:03 vpn-gateway ipsec[2578]: 06[ENC] received fragment #3 of 3, reassembling fragmented IKE message
Jul 16 07:22:03 vpn-gateway charon: 06[ENC] parsed IKE_AUTH request 5 [ AUTH ]
Jul 16 07:22:03 vpn-gateway ipsec[2578]: 06[ENC] parsed IKE_AUTH request 1 [ IDi CERTREQ N(MOBIKE_SUP) CPRQ(ADDR DNS NBNS SRV ADDR6 DNS6 SRV6) SA TSi TSr ]
Jul 16 07:22:03 vpn-gateway ipsec[2578]: 06[IKE] received 41 cert requests for an unknown ca
Jul 16 07:22:03 vpn-gateway ipsec[2578]: 06[IKE] initiating EAP_IDENTITY method (id 0x00)
Jul 16 07:22:03 vpn-gateway ipsec[2578]: 06[IKE] peer supports MOBIKE
Jul 16 07:22:03 vpn-gateway ipsec[2578]: 06[IKE] authentication of 'CN=ipsec.xxx.xxx' (myself) with RSA signature successful
Jul 16 07:22:03 vpn-gateway ipsec[2578]: 06[IKE] sending end entity cert "CN=ipsec.xxx.xxx"
Jul 16 07:22:03 vpn-gateway ipsec[2578]: 06[IKE] sending issuer cert "C=US, O=Let's Encrypt, CN=Let's Encrypt Authority X3"
Jul 16 07:22:03 vpn-gateway ipsec[2578]: 06[ENC] generating IKE_AUTH response 1 [ IDr CERT CERT AUTH EAP/REQ/ID ]
Jul 16 07:22:03 vpn-gateway ipsec[2578]: 06[ENC] splitting IKE message with length of 3136 bytes into 3 fragments
Jul 16 07:22:03 vpn-gateway ipsec[2578]: 06[ENC] generating IKE_AUTH response 1 [ EF(1/3) ]
Jul 16 07:22:03 vpn-gateway ipsec[2578]: 06[ENC] generating IKE_AUTH response 1 [ EF(2/3) ]
Jul 16 07:22:03 vpn-gateway ipsec[2578]: 06[ENC] generating IKE_AUTH response 1 [ EF(3/3) ]
Jul 16 07:22:03 vpn-gateway ipsec[2578]: 06[NET] sending packet: from 10.0.0.2[4500] to x.x.x.x[6511] (1236 bytes)
Jul 16 07:22:03 vpn-gateway ipsec[2578]: 06[NET] sending packet: from 10.0.0.2[4500] to x.x.x.x[6511] (1236 bytes)
Jul 16 07:22:03 vpn-gateway ipsec[2578]: 06[NET] sending packet: from 10.0.0.2[4500] to x.x.x.x[6511] (804 bytes)
Jul 16 07:22:03 vpn-gateway ipsec[2578]: 07[NET] received packet: from x.x.x.x[6511] to 10.0.0.2[4500] (96 bytes)
Jul 16 07:22:03 vpn-gateway ipsec[2578]: 07[ENC] parsed IKE_AUTH request 2 [ EAP/RES/ID ]
Jul 16 07:22:03 vpn-gateway ipsec[2578]: 07[IKE] received EAP identity 'x'
Jul 16 07:22:03 vpn-gateway ipsec[2578]: 07[IKE] initiating EAP_MSCHAPV2 method (id 0xFF)
Jul 16 07:22:03 vpn-gateway ipsec[2578]: 07[ENC] generating IKE_AUTH response 2 [ EAP/REQ/MSCHAPV2 ]
Jul 16 07:22:03 vpn-gateway ipsec[2578]: 07[NET] sending packet: from 10.0.0.2[4500] to x.x.x.x[6511] (112 bytes)
Jul 16 07:22:03 vpn-gateway ipsec[2578]: 08[NET] received packet: from x.x.x.x[6511] to 10.0.0.2[4500] (144 bytes)
Jul 16 07:22:03 vpn-gateway ipsec[2578]: 08[ENC] parsed IKE_AUTH request 3 [ EAP/RES/MSCHAPV2 ]
Jul 16 07:22:03 vpn-gateway ipsec[2578]: 08[ENC] generating IKE_AUTH response 3 [ EAP/REQ/MSCHAPV2 ]
Jul 16 07:22:03 vpn-gateway ipsec[2578]: 08[NET] sending packet: from 10.0.0.2[4500] to x.x.x.x[6511] (144 bytes)
Jul 16 07:22:03 vpn-gateway ipsec[2578]: 05[NET] received packet: from x.x.x.x[6511] to 10.0.0.2[4500] (80 bytes)
Jul 16 07:22:03 vpn-gateway ipsec[2578]: 05[ENC] parsed IKE_AUTH request 4 [ EAP/RES/MSCHAPV2 ]
Jul 16 07:22:03 vpn-gateway ipsec[2578]: 05[IKE] EAP method EAP_MSCHAPV2 succeeded, MSK established
Jul 16 07:22:03 vpn-gateway ipsec[2578]: 05[ENC] generating IKE_AUTH response 4 [ EAP/SUCC ]
Jul 16 07:22:03 vpn-gateway ipsec[2578]: 05[NET] sending packet: from 10.0.0.2[4500] to x.x.x.x[6511] (80 bytes)
Jul 16 07:22:03 vpn-gateway charon: 06[IKE] authentication of '192.168.43.7' with EAP successful
Jul 16 07:22:03 vpn-gateway ipsec[2578]: 06[NET] received packet: from x.x.x.x[6511] to 10.0.0.2[4500] (112 bytes)
Jul 16 07:22:03 vpn-gateway charon: 06[IKE] authentication of 'CN=ipsec.xxx.xxx' (myself) with EAP
Jul 16 07:22:03 vpn-gateway charon: 06[IKE] IKE_SA AndroidCon[1] established between 10.0.0.2[CN=ipsec.xxx.xxx]...x.x.x.x[192.168.43.7]
Jul 16 07:22:03 vpn-gateway charon: 06[IKE] peer requested virtual IP %any
Jul 16 07:22:03 vpn-gateway charon: 06[IKE] assigning virtual IP 172.31.0.1 to peer 'x'
Jul 16 07:22:03 vpn-gateway charon: 06[IKE] peer requested virtual IP %any6
Jul 16 07:22:03 vpn-gateway charon: 06[IKE] no virtual IP found for %any6 requested by 'x'
Jul 16 07:22:03 vpn-gateway charon: 06[IKE] CHILD_SA AndroidCon{1} established with SPIs cd928f30_i a2493b60_o and TS 0.0.0.0/0 === 172.31.0.1/32
Jul 16 07:22:03 vpn-gateway charon: 06[ENC] generating IKE_AUTH response 5 [ AUTH CPRP(ADDR DNS DNS DNS DNS) SA TSi TSr N(MOBIKE_SUP) N(NO_ADD_ADDR) ]
Jul 16 07:22:03 vpn-gateway charon: 06[NET] sending packet: from 10.0.0.2[4500] to x.x.x.x[6511] (256 bytes)

Um teste de um cliente linux conectado (strongswan) mostrou os mesmos resultados problemáticos. Os serviços do Google não estão disponíveis. Não quando se usa um web browser para fazer isso. Os próprios servidores estão respondendo a pings:

root@antelope:/home/karsten# ping mail.google.com
PING googlemail.l.google.com (173.194.196.17) 56(84) bytes of data.
64 bytes from ix-in-f17.1e100.net (173.194.196.17): icmp_seq=1 ttl=51 time=377 ms
64 bytes from ix-in-f17.1e100.net (173.194.196.17): icmp_seq=2 ttl=51 time=358 ms
^C
--- googlemail.l.google.com ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1000ms
rtt min/avg/max/mdev = 358.685/367.880/377.076/9.215 ms

root@antelope:/home/karsten# ping youtube.com
PING youtube.com (173.194.196.136) 56(84) bytes of data.
64 bytes from ix-in-f136.1e100.net (173.194.196.136): icmp_seq=1 ttl=51 time=360 ms
^C
--- youtube.com ping statistics ---
2 packets transmitted, 1 received, 50% packet loss, time 1000ms
rtt min/avg/max/mdev = 360.711/360.711/360.711/0.000 ms

Por isso, ativei o registro para o firefox:

export NSPR_LOG_MODULES="nsHttp:3,nsHostResolver:3"
export NSPR_LOG_FILE="/home/karsten/firefox.log"

O log é bastante detalhado, mas não me diz muito sobre o meu problema. O que está acontecendo enquanto o túnel está estabelecido pode ser encontrado aqui: "túnel está em alta"

Quando o túnel é desativado e todos os serviços do Google são acessados novamente, é assim: "túnel está em baixo"

Faça o login do firefox de uma maneira diferente (por meio de: rede na configuração padrão). Não dá nenhuma informação melhor para mim, mas talvez outra pessoa.

Com o túnel aberto: new-firefox.log-up E desacelere (os serviços do Google estão disponíveis): new-firefox.log-downa

Enquanto isso, o aplicativo strongswan no Android mostra o mesmo comportamento. Está funcionando bem apenas por alguns instantes.

O "firewall" no servidor:

root@vpn-gateway:/home/karsten# iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination         

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         
root@vpn-gateway:/home/karsten# iptables -L -t nat
Chain PREROUTING (policy ACCEPT)
target     prot opt source               destination         

Chain INPUT (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         

Chain POSTROUTING (policy ACCEPT)
target     prot opt source               destination         
ACCEPT     all  --  anywhere             anywhere             policy match dir out pol ipsec
MASQUERADE  all  --  172.31.0.0/24        anywhere            
root@vpn-gateway:/home/karsten# iptables -L -t mangle
Chain PREROUTING (policy ACCEPT)
target     prot opt source               destination         

Chain INPUT (policy ACCEPT)
target     prot opt source               destination         

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         
TCPMSS     tcp  --  anywhere             anywhere             policy match dir in pol ipsec tcp flags:SYN,RST/SYN tcpmss match 1361:1536 TCPMSS set 1360
TCPMSS     tcp  --  anywhere             anywhere             policy match dir out pol ipsec tcp flags:SYN,RST/SYN tcpmss match 1361:1536 TCPMSS set 1360

Aqui estão algumas entradas selecionadas do arquivo pcap gerado com o tcpdump. No lado do respondente, quando o túnel está ativo e o iniciador está tentando acessar www.google.com: tunnel-up.responder

No lado do iniciador ao mesmo tempo: iniciador de encapsulamento

E como referência, é assim que deve parecer no iniciador. Aqui o túnel está em baixo. iniciador de encapsulamento

    
por K. Werner 16.07.2018 / 07:46

1 resposta

0

Com a ajuda de você, consegui resolver o problema. Depois de ajustar o MSS até 1350 bytes, a configuração funciona conforme o esperado.

root@vpn-gateway:/home/karsten# iptables -L -t mangle
Chain PREROUTING (policy ACCEPT)
target     prot opt source               destination         

Chain INPUT (policy ACCEPT)
target     prot opt source               destination         

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         
TCPMSS     tcp  --  anywhere             anywhere             policy match dir in pol ipsec tcp flags:SYN,RST/SYN tcpmss match 1351:1536 TCPMSS set 1350
TCPMSS     tcp  --  anywhere             anywhere             policy match dir out pol ipsec tcp flags:SYN,RST/SYN tcpmss match 1351:1536 TCPMSS set 1350

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         

Chain POSTROUTING (policy ACCEPT)
target     prot opt source               destination 

A questão para mim é porque isso é necessário em primeiro lugar.

    
por 18.07.2018 / 12:57