Routing

Strongswan 在兩個 IPsec 隧道之間轉發流量，其中一個是主機

  • January 16, 2017

我面臨著與此處所述類似的問題，但該解決方案在我的場景中不起作用。

我有

  • 具有靜態外部 IP 地址 AA.AA.AA.AA、內部 IP 192.168.1.1 和內部子網 192.168.1.0/24 的 VPN 伺服器 A
  • 具有動態外部 IP 地址 BB.BB.BB.BB、內部 IP 為 192.168.2.254 和內部子網為 192.168.2.0/24 的 VPN 伺服器 B
  • 連接到 VPN 時具有動態外部 IP 地址 MM.MM.MM.MM 和 IP 192.168.250.129 的移動設備

在 A 和 B 之間，兩個子網通過 VPN 透明路由，效果很好。

移動設備連接到 A 並從 192.168.250.128/25 子網接收 IP 地址。移動設備可以與 192.168.1.0/24 子網中的所有設備正常通信（反之亦然），但不能與 192.168.2.0/24 中的任何設備通信。

在 A 上，我可以看到數據包到達：

hanjo@A:~$ sudo tcpdump -n net 192.168.250.128/25
19:28:31.367911 IP 192.168.250.129 > 192.168.2.50: ICMP echo request, id 26463, seq 0, length 64
19:28:32.469991 IP 192.168.250.129 > 192.168.2.50: ICMP echo request, id 26463, seq 1, length 64
19:28:33.410002 IP 192.168.250.129 > 192.168.2.50: ICMP echo request, id 26463, seq 2, length 64
19:28:34.389997 IP 192.168.250.129 > 192.168.2.50: ICMP echo request, id 26463, seq 3, length 64
19:28:35.449973 IP 192.168.250.129 > 192.168.2.50: ICMP echo request, id 26463, seq 4, length 64

在 B 上，沒有擷取到任何數據包。

有趣的是，從另一個方向發送數據，即從 192.168.2.0/24 子網上的主機到移動設備似乎工作得更好。

從 B 擷取：

hanjo@B:~$ sudo tcpdump -n net 192.168.250.0/24
20:44:27.201713 IP 192.168.2.50 > 192.168.250.129: ICMP echo request, id 55134, seq 0, length 64
20:44:28.202222 IP 192.168.2.50 > 192.168.250.129: ICMP echo request, id 55134, seq 1, length 64
20:44:29.202355 IP 192.168.2.50 > 192.168.250.129: ICMP echo request, id 55134, seq 2, length 64
20:44:30.202603 IP 192.168.2.50 > 192.168.250.129: ICMP echo request, id 55134, seq 3, length 64

從 A 擷取：

hanjo@A:~$ sudo tcpdump -n net 192.168.250.128/25
20:42:28.897441 IP 192.168.2.50 > 192.168.250.129: ICMP echo request, id 39774, seq 0, length 64
20:42:28.897990 IP AA.AA.AA.AA > 192.168.250.129: ICMP echo request, id 39774, seq 0, length 64
20:42:29.897510 IP 192.168.2.50 > 192.168.250.129: ICMP echo request, id 39774, seq 1, length 64
20:42:29.897962 IP AA.AA.AA.AA > 192.168.250.129: ICMP echo request, id 39774, seq 1, length 64
20:42:30.897469 IP 192.168.2.50 > 192.168.250.129: ICMP echo request, id 39774, seq 2, length 64
20:42:30.897918 IP AA.AA.AA.AA > 192.168.250.129: ICMP echo request, id 39774, seq 2, length 64
20:42:31.897458 IP 192.168.2.50 > 192.168.250.129: ICMP echo request, id 39774, seq 3, length 64
20:42:31.897911 IP AA.AA.AA.AA > 192.168.250.129: ICMP echo request, id 39774, seq 3, length 64

但是，如您所見，沒有收到回顯回复。

這是我的 Strongswan 配置：

A的ipsec.conf：

conn B-tunnel
   left=AA.AA.AA.AA
   leftid="@A"
   right=B.dyndns
   rightid="@B"
   leftsubnet=192.168.1.0/24,192.168.250.0/24
   rightsubnet=192.168.2.0/24
   keyexchange=ikev2
   type=tunnel
   authby=secret
   auto=route

conn rw-v2
   keyexchange=ikev2
   left=AA.AA.AA.AA
   leftid="@A"
   right=%any
   leftsubnet=192.168.1.0/24,192.168.2.0/24
   rightsourceip=192.168.250.128/25
   rightdns=192.168.1.1
   authby=secret

conn mobile
   also=rw-v2
   auto=add
   rightid="@mobile"

B的ipsec.conf：

conn A-tunnel
   left=192.168.2.254
   leftsubnet=192.168.2.0/24
   leftid=@B
   right=AA.AA.AA.AA
   rightsubnet=192.168.1.0/24,192.168.250.0/24
   rightid=@A
   authby=secret
   type=tunnel
   auto=start

來自 A 的附加資訊：

hanjo@A:~$ sudo ipsec statusall
Status of IKE charon daemon (weakSwan 5.2.2, Linux 3.10.20, mips64):
 uptime: 7 hours, since Jan 08 14:50:14 2017
 malloc: sbrk 586896, mmap 0, used 376264, free 210632
 worker threads: 11 of 16 idle, 5/0/0/0 working, job queue: 0/0/0/0, scheduled: 44
 loaded plugins: charon ldap sqlite pkcs11 aes des sha1 sha2 md5 random nonce x509 revocation constraints pubkey pkcs1 pkcs8 pem openssl agent xcbc cmac ctr ccm gcm curl attr kernel-netlink resolve socket-default stroke vici updown eap-identity eap-md5 eap-mschapv2 eap-radius eap-tls xauth-generic xauth-eap addrblock
Virtual IP pools (size/online/offline):
 192.168.250.128/25: 126/1/1
Listening IP addresses:
 AA.AA.AA.AA
 192.168.1.1
Connections:
B-tunnel:  AA.AA.AA.AA...B.dyndns  IKEv2, dpddelay=30s
B-tunnel:   local:  [A] uses pre-shared key authentication
B-tunnel:   remote: [B] uses pre-shared key authentication
B-tunnel:   child:  192.168.1.0/24 192.168.250.0/24 === 192.168.2.0/24 TUNNEL, dpdaction=restart
     mobile:  AA.AA.AA.AA...%any  IKEv2, dpddelay=15s
     mobile:   local:  [A] uses pre-shared key authentication
     mobile:   remote: [mobile] uses pre-shared key authentication
     mobile:   child:  192.168.1.0/24 192.168.2.0/24 === dynamic TUNNEL, dpdaction=clear
Routed Connections:
B-tunnel{5}:  ROUTED, TUNNEL
B-tunnel{5}:   192.168.1.0/24 192.168.250.0/24 === 192.168.2.0/24
Security Associations (6 up, 0 connecting):
     mobile[55]: ESTABLISHED 104 seconds ago, AA.AA.AA.AA[A]...MM.MM.MM.MM[mobile]
     mobile[55]: IKEv2 SPIs: 4dc26b00764d7fbf_i f00fd36247594b6a_r*, pre-shared key reauthentication in 106 minutes
     mobile[55]: IKE proposal: AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_2048
     mobile{36}:  INSTALLED, TUNNEL, ESP in UDP SPIs: c1012a86_i 08a38525_o
     mobile{36}:  AES_CBC_256/HMAC_SHA1_96, 15163 bytes_i (100 pkts, 66s ago), 55569 bytes_o (78 pkts, 87s ago), rekeying in 44 minutes
     mobile{36}:   192.168.1.0/24 192.168.2.0/24 === 192.168.250.129/32
B-tunnel[19]: ESTABLISHED 6 hours ago, AA.AA.AA.AA[A]...BB.BB.BB.BB[B]
B-tunnel[19]: IKEv2 SPIs: 97ef622accd69b0a_i* b1cd574224dcba1c_r, rekeying in 80 minutes, pre-shared key reauthentication in 70 minutes
B-tunnel[19]: IKE proposal: AES_CBC_256/HMAC_SHA2_512_256/PRF_HMAC_SHA2_512/MODP_8192
B-tunnel{5}:  INSTALLED, TUNNEL, ESP in UDP SPIs: cbd873b7_i cebce241_o
B-tunnel{5}:  AES_CBC_256/HMAC_SHA2_512_256, 518363 bytes_i (3670 pkts, 0s ago), 274095 bytes_o (3733 pkts, 0s ago), rekeying in 21 minutes
B-tunnel{5}:   192.168.1.0/24 192.168.250.0/24 === 192.168.2.0/24

hanjo@A:~$ sudo ip xfrm policy
src 192.168.250.129/32 dst 192.168.2.0/24 
   dir fwd priority 2851 
   tmpl src MM.MM.MM.MM dst AA.AA.AA.AA
       proto esp reqid 36 mode tunnel
src 192.168.250.129/32 dst 192.168.2.0/24 
   dir in priority 2851 
   tmpl src MM.MM.MM.MM dst AA.AA.AA.AA
       proto esp reqid 36 mode tunnel
src 192.168.2.0/24 dst 192.168.250.129/32 
   dir out priority 2851 
   tmpl src AA.AA.AA.AA dst MM.MM.MM.MM
       proto esp reqid 36 mode tunnel
src 192.168.250.129/32 dst 192.168.1.0/24 
   dir fwd priority 2851 
   tmpl src MM.MM.MM.MM dst AA.AA.AA.AA
       proto esp reqid 36 mode tunnel
src 192.168.250.129/32 dst 192.168.1.0/24 
   dir in priority 2851 
   tmpl src MM.MM.MM.MM dst AA.AA.AA.AA
       proto esp reqid 36 mode tunnel
src 192.168.1.0/24 dst 192.168.250.129/32 
   dir out priority 2851 
   tmpl src AA.AA.AA.AA dst MM.MM.MM.MM
       proto esp reqid 36 mode tunnel
src 192.168.2.0/24 dst 192.168.250.0/24 
   dir fwd priority 2883 
   tmpl src BB.BB.BB.BB dst AA.AA.AA.AA
       proto esp reqid 5 mode tunnel
src 192.168.2.0/24 dst 192.168.250.0/24 
   dir in priority 2883 
   tmpl src BB.BB.BB.BB dst AA.AA.AA.AA
       proto esp reqid 5 mode tunnel
src 192.168.250.0/24 dst 192.168.2.0/24 
   dir out priority 2883 
   tmpl src AA.AA.AA.AA dst BB.BB.BB.BB
       proto esp reqid 5 mode tunnel
src 192.168.2.0/24 dst 192.168.1.0/24 
   dir fwd priority 2883 
   tmpl src BB.BB.BB.BB dst AA.AA.AA.AA
       proto esp reqid 5 mode tunnel
src 192.168.2.0/24 dst 192.168.1.0/24 
   dir in priority 2883 
   tmpl src BB.BB.BB.BB dst AA.AA.AA.AA
       proto esp reqid 5 mode tunnel
src 192.168.1.0/24 dst 192.168.2.0/24 
   dir out priority 2883 
   tmpl src AA.AA.AA.AA dst BB.BB.BB.BB
       proto esp reqid 5 mode tunnel
src 0.0.0.0/0 dst 0.0.0.0/0 
   socket in priority 0 
src 0.0.0.0/0 dst 0.0.0.0/0 
   socket out priority 0 
src 0.0.0.0/0 dst 0.0.0.0/0 
   socket in priority 0 
src 0.0.0.0/0 dst 0.0.0.0/0 
   socket out priority 0 

hanjo@A:~$ sudo ip route
default via AA.AA.AA.1 dev eth0  proto zebra 
AA.AA.AA.0/30 dev eth0  proto kernel  scope link 
192.168.1.0/24 dev eth1  proto kernel  scope link  src 192.168.1.1 

hanjo@A:~$ sudo ip route show table 220
192.168.2.0/24 via AA.AA.AA.1 dev eth0  proto static  src 192.168.1.1 
192.168.250.129 via AA.AA.AA.1 dev eth0  proto static  src 192.168.1.1

來自 B 的附加資訊：

hanjo@B:~$ sudo ipsec statusall
Status of IKE charon daemon (strongSwan 5.2.1, Linux 4.4.23+, armv6l):
 uptime: 24 hours, since Jan 07 22:19:36 2017
 malloc: sbrk 663552, mmap 0, used 246232, free 417320
 worker threads: 11 of 16 idle, 5/0/0/0 working, job queue: 0/0/0/0, scheduled: 12
 loaded plugins: charon aes rc2 sha1 sha2 md5 random nonce x509 revocation constraints pubkey pkcs1 pkcs7 pkcs8 pkcs12 pgp dnskey sshkey pem openssl fips-prf gmp agent xcbc hmac gcm attr kernel-netlink resolve socket-default farp stroke updown eap-identity eap-aka eap-md5 eap-gtc eap-mschapv2 eap-radius eap-tls eap-ttls eap-tnc xauth-generic xauth-eap xauth-pam tnc-tnccs dhcp lookip error-notify certexpire led addrblock unity
Virtual IP pools (size/online/offline):
Listening IP addresses:
 192.168.2.254
Connections:
   A-tunnel:  192.168.2.254,0.0.0.0/0,::/0...AA.AA.AA.AA,0.0.0.0/0,::/0  IKEv2, dpddelay=30s
   A-tunnel:   local:  [B] uses pre-shared key authentication
   A-tunnel:   remote: [A] uses pre-shared key authentication
   A-tunnel:   child:  192.168.2.0/24 === 192.168.1.0/24 192.168.250.0/24 TUNNEL, dpdaction=restart
Security Associations (1 up, 0 connecting):
      A-tunnel[11]: ESTABLISHED 6 hours ago, 192.168.2.254[B]...AA.AA.AA.AA[A]
      A-tunnel[11]: IKEv2 SPIs: 0a9bd6cc2a62ef97_i 1cbadc244257cdb1_r*, pre-shared key reauthentication in 79 minutes
      A-tunnel[11]: IKE proposal: AES_CBC_256/HMAC_SHA2_512_256/PRF_HMAC_SHA2_512/MODP_8192
      A-tunnel{12}:  INSTALLED, TUNNEL, ESP in UDP SPIs: cebce241_i cbd873b7_o
      A-tunnel{12}:  AES_CBC_256/HMAC_SHA2_512_256, 275930 bytes_i (3754 pkts, 0s ago), 523881 bytes_o (3728 pkts, 0s ago), rekeying in 22 minutes
      A-tunnel{12}:   192.168.2.0/24 === 192.168.1.0/24 192.168.250.0/24

hanjo@B:~$ sudo ip xfrm policy
src 192.168.250.0/24 dst 192.168.2.0/24 
   dir fwd priority 2883 
   tmpl src AA.AA.AA.AA dst 192.168.2.254
       proto esp reqid 12 mode tunnel
src 192.168.250.0/24 dst 192.168.2.0/24 
   dir in priority 2883 
   tmpl src AA.AA.AA.AA dst 192.168.2.254
       proto esp reqid 12 mode tunnel
src 192.168.2.0/24 dst 192.168.250.0/24 
   dir out priority 2883 
   tmpl src 192.168.2.254 dst AA.AA.AA.AA
       proto esp reqid 12 mode tunnel
src 192.168.1.0/24 dst 192.168.2.0/24 
   dir fwd priority 2883 
   tmpl src AA.AA.AA.AA dst 192.168.2.254
       proto esp reqid 12 mode tunnel
src 192.168.1.0/24 dst 192.168.2.0/24 
   dir in priority 2883 
   tmpl src AA.AA.AA.AA dst 192.168.2.254
       proto esp reqid 12 mode tunnel
src 192.168.2.0/24 dst 192.168.1.0/24 
   dir out priority 2883 
   tmpl src 192.168.2.254 dst AA.AA.AA.AA
       proto esp reqid 12 mode tunnel
src 0.0.0.0/0 dst 0.0.0.0/0 
   socket in priority 0 
src 0.0.0.0/0 dst 0.0.0.0/0 
   socket out priority 0 
src 0.0.0.0/0 dst 0.0.0.0/0 
   socket in priority 0 
src 0.0.0.0/0 dst 0.0.0.0/0 
   socket out priority 0 

hanjo@B:~$ sudo ip route
default via 192.168.2.1 dev eth0 
192.168.2.0/24 dev eth0  proto kernel  scope link  src 192.168.2.254 

hanjo@B:~$ sudo ip route show table 220
192.168.1.0/24 via 192.168.2.1 dev eth0  proto static  src 192.168.2.254 
192.168.250.0/24 via 192.168.2.1 dev eth0  proto static  src 192.168.2.254

知道可能是什麼問題嗎？

這看起來不對：

20:42:28.897990 IP AA.AA.AA.AA > 192.168.250.129: ICMP echo request, id 39774, seq 0, length 64

當A只是轉發B的流量時，為什麼會有從A的公共IP到移動客戶端的ICMP？你所期望的是一個帶有 A 的公共 IP 但絕對不是 ICMP 的 ESP 數據包。

A 上是否有 NAT 規則？如果是這樣，請確保使用策略模組從實際 NAT 規則中排除與 IPsec 策略匹配的流量。基本上在實際的 NAT 規則之前添加這樣的東西（也在strongSwan wiki上解釋過）：

iptables -t nat -A POSTROUTING -s 192.168.1.0/24,192.168.2.0/24,192.168.250.0/24 -o eth0 -m policy --dir out --pol ipsec -j ACCEPT

引用自：https://unix.stackexchange.com/questions/335855

相關問答

Networking

Strongswan 只有最後一個連接的人通過隧道路由

  • March 6, 2020
檢視問答
Ubuntu

wireguard 會握手，但 ping 不通

  • April 19, 2022
檢視問答
Ip

通過 VPN 網關路由 LAN 流量

  • April 16, 2022
檢視問答
Vpn

除非手動 ping 出，Strongswan VPN 無法正常工作

  • March 8, 2022
檢視問答
Iptables

VPN介面和別名介面之間的路由

  • February 23, 2022
檢視問答
Ssh

將 ssh 與特定的網路介面一起使用

  • February 22, 2022
檢視問答