我在 GCE 中的 Debian 上设置了一个 strongswan 响应器。我可以通过 Android 上的 strongswan 应用程序连接到它。没有问题。我也可以使用 Windows 10 中的本机 vpn 客户端进行连接。当我这样做时，响应器将成为我的默认网关。（此操作的全部意义。）。我可以通过这种方式访问大部分互联网，但无法访问谷歌服务。没有搜索引擎，没有 gmail、youtube 等。pp。在 GCE 中运行的网站也可以访问。该网站需要加载谷歌字体。失败了。
有人知道为什么会发生这种情况吗？
/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 服务不可用。也就是说，使用 Web 浏览器时不可用。服务器本身正在响应 ping：
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:networking）。它没有给我提供任何更好的信息，但也许对其他人有用。
隧道向上：新 Firefox 登录 并向下挖掘（谷歌服务可用）：new-firefox.log-downa
同时，Android 上的 strongswan 应用程序也表现出同样的行为。它只在片刻内正常工作。
服务器上的“防火墙”：
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
以下是从使用 tcpdump 生成的 pcap 文件中精心挑选的一些条目。在响应方，当隧道已启动且发起方尝试访问 www.google.com 时：隧道上行响应器
在发起方同时：隧道启动器
作为参考，它在启动器上应该是这样的。这里隧道已经关闭。隧道关闭启动器
答案1
在您的帮助下，我解决了这个问题。将 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
我的问题仍然是为什么首先这是必要的。