考虑到强天鹅维基,这似乎是一个标准的问题,但我无法使它很好地工作。

本地站点(client和gateway)在我的控制之下,而远程站点(remote gateway和remote server)则不是。IPSec隧道是一个split隧道,只有对10.10.0.0/16子网的请求才能通过IPSec隧道发送。
我希望client与remote server进行通信,例如创建ssh或smb连接。
gateway之间建立了一个隧道。gateway:sysctl net.ipv4.ip_forward=1上启用了ip转发gateway上创建了一个NAT : iptables -t nat -I POSTROUTING -m策略-- policy dir out -j ACCEPT -j -t nat -A POSTROUTING -j伪装client上,我已经通过gateway路由了流量: ip路由模型默认ip路由添加默认值通过192.168.144.4 # 192.168.144.4是网关gateway时,我可以成功地ping remote gateway和remote server .我也可以ping client。我可以ping google.com。client时,我可以ping google.com,也可以ping gateway.使用tcpdump icmp在gateway上,我看到来自client的ping google.com正在通过gateway。我不能通过IP从ping从client获取remote server。
client$ ping -c 1 10.10.12.7
PING 10.10.12.7 (10.10.12.7): 56 data bytes
--- 10.10.12.7 ping statistics ---
1 packets transmitted, 0 packets received, 100% packet loss从gateway上的D66中,看起来ping是发送的,但不是通过隧道转发的:
gateway$ tcpdump icmp
13:19:18.122999 IP 192.168.144.7 > 10.10.12.7: ICMP echo request, id 15, seq 0, length 64
13:19:18.123038 IP gateway > 10.10.12.7: ICMP echo request, id 15, seq 0, length 64
13:19:18.127534 IP ac5.nue3.m-online.net > gateway: ICMP net 10.10.12.7 unreachable, length 36
13:19:18.127556 IP ac5.nue3.m-online.net > 192.168.144.7: ICMP net 10.10.12.7 unreachable, length 36由于ac5.nue3.m-online.net是本地站点的互联网服务提供商,我认为数据包不是通过IPSec隧道路由的,而是通过gateway的互联网连接来路由的,而D70当然无法到达remote server。(如果我将IPSec隧道变成一个完整的隧道,而不是一个分割的隧道,我就会得到同样的结果。)
任何帮助或洞察力将是非常感谢的!
ipsec statusall on gatewaygateway > ipsec statusall
Status of IKE charon daemon (strongSwan 5.8.2, Linux 5.4.0-88-generic, x86_64):
uptime: 7 minutes, since Oct 08 08:18:24 2021
malloc: sbrk 3112960, mmap 0, used 1081456, free 2031504
worker threads: 11 of 16 idle, 5/0/0/0 working, job queue: 0/0/0/0, scheduled: 4
loaded plugins: charon test-vectors ldap pkcs11 tpm aesni aes rc2 sha2 sha1 md5 mgf1 rdrand random nonce x509 revocation constraints pubkey pkcs1 pkcs7 pkcs8 pkcs12 pgp dnskey sshkey pem openssl gcrypt af-alg fips-prf gmp curve25519 agent chapoly xcbc cmac hmac ctr ccm gcm ntru drbg curl attr kernel-netlink resolve socket-default connmark farp stroke updown eap-identity eap-aka eap-md5 eap-gtc eap-mschapv2 eap-dynamic eap-radius eap-tls eap-ttls eap-peap eap-tnc xauth-generic xauth-eap xauth-pam tnc-tnccs dhcp lookip error-notify certexpire led addrblock unity counters
Listening IP addresses:
192.168.144.4
Connections:
example-ipsec: %any...vpn1.example.com IKEv2, dpddelay=300s
example-ipsec: local: [example@example.com] uses pre-shared key authentication
example-ipsec: remote: [example@example.com] uses pre-shared key authentication
example-ipsec: child: dynamic === 0.0.0.0/0 TUNNEL, dpdaction=clear
Security Associations (1 up, 0 connecting):
example-ipsec[1]: ESTABLISHED 7 minutes ago, 192.168.144.4[example@example.com]...[example@example.com]
example-ipsec[1]: I: 9d7c74f670bbda86_i* c12b3b4a236b7018_r, pre-shared key reauthentication in 2 hours
example-ipsec[1]: IKE proposal: AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_2048
example-ipsec{1}: INSTALLED, TUNNEL, reqid 1, ESP in UDP SPIs: cf66ad72_i af3c9348_o
example-ipsec{1}: AES_CBC_256/HMAC_SHA2_256_128, 442 bytes_i (4 pkts, 434s ago), 485 bytes_o (6 pkts, 433s ago), rekeying in 38 minutes
example-ipsec{1}: 10.10.102.235/32 === 0.0.0.0/0这是ipsec statusall在将ping从client发送到remote server失败后在D80上的输出。来自ping的gateway不会改变输出中的“字节”。输出中的“字节”对应于我从gateway发送到remote server的一个D86。
/etc/ipsec.conf on gateway:# /etc/ipsec.conf
conn example-ipsec
left = %defaultroute
leftsourceip = %config
leftid = "example@example.com"
right = vpn1.example.com
rightid = "example@example.com"
rightsubnet = 0.0.0.0/0
leftfirewall = yes
installpolicy = yes
keyexchange = ikev2
type = tunnel
auto = start
leftauth = psk
rightauth = psk
dpdaction = clear
dpddelay = 300s发布于 2021-10-11 07:49:46
由于连接使用虚拟IP地址(leftsourceip=%config,这将导致10.10.102.235/32作为本地流量选择器),因此必须将流量NAT传输到该地址,而不是通过MASQUERADE获得主机的物理地址,以便匹配IPsec策略并隧道通信量(-I将其插入到顶部):
iptables -t nat -I POSTROUTING -j SNAT --to-source 10.10.102.235如果没有静态分配虚拟IP (例如,基于客户端的标识),并且可能发生更改,则可以在自定义updown脚本 (通过leftupdown配置)中动态安装/删除$PLUTO_MY_SOURCEIP中的虚拟IP。
正如您最初所说的,这是一个拆分隧道设置( 0.0.0.0/0的远程流量选择器实际上并不反映这种设置),您还可以将例如-d 10.10.0.0/16添加到SNAT规则中,以便只处理该子网中的数据包,其他通信量将不会被捕获和隧道化(您可以保留该通信量的MASQUERADE规则)。这也可以通过IPsec策略(rightsubnet=10.10.0.0/16)来实现,然后在updown脚本中在$PLUTO_PEER_CLIENT中获得该策略。
https://serverfault.com/questions/1079879
复制相似问题