Назад | Перейти на главную страницу

Туннель ipsec блокирует службы Google

Я установил ответчик strongswan на debian в GCE. Я могу подключиться к нему через приложение strongswan на android. Без проблем. Я также могу подключиться с помощью собственного vpn-клиента в Windows 10. И когда я это сделаю, ответчик становится моим шлюзом по умолчанию. (Весь смысл этой операции.) Таким образом я могу получить доступ к большей части Интернета, но не к службам Google. Нет поисковой системы, Gmail, YouTube и т. Д. Стр. Доступен также веб-сайт, работающий в GCE. Этот сайт хочет, чтобы были загружены шрифты Google. Это не удается.

Кто-нибудь знает, почему это происходит?

/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

Журнал сервера при подключении окна:

    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)

Тест с подключенного клиента Linux (strongswan) показал такие же проблемные результаты. Сервисы Google недоступны. Не тогда, когда для этого используется веб-браузер. Сами серверы отвечают на пинги:

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

Итак, я включил ведение журнала для firefox:

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

Журнал довольно подробный, но он мало что говорит мне о моей проблеме. Что происходит во время установки туннеля, можно узнать здесь: "туннель вверх"

Когда туннель деактивирован и все сервисы Google снова становятся доступными, это выглядит так: "туннель опущен"

Собрал логи firefox другим способом (через about: network в стандартной конфигурации). Это не дает мне более точной информации, но, возможно, кого-то еще.

С туннелем вверх: новый-firefox.log-up И туннель вниз (доступны сервисы Google): новый-firefox.log-downa

Между тем приложение strongswan на Android показывает такое же поведение. Он работает нормально только несколько секунд.

«Межсетевой экран» на сервере:

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

Вот несколько выбранных записей из файла pcap, созданного с помощью tcpdump. На стороне респондента, когда туннель активен и инициатор пытается получить доступ к www.google.com: туннель-up.responder

На стороне инициатора одновременно: tunnel-up.initiator

И как ссылка, вот как это должно выглядеть на инициаторе. Здесь туннель внизу. туннель вниз. инициатор

С вашей помощью я смогу решить эту проблему. После уменьшения MSS до 1350 байт настройка работает должным образом.

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 

Для меня остается вопрос, зачем это вообще нужно.