站點到站點 IPSec 路由(Ubuntu、StrongSwan)
我一直在嘗試連接兩個網路。
SiteA:是多個不同地點的VPS和辦公工作站在私網10.113.0.0/24與OpenVPN相連。每個都有自己的網際網路訪問和預設網關。OpenVPN 伺服器具有公共 ip 95.95.95.95,也代表 IPSec 端點。
SiteB:是在邊緣網關後面的 VMWare 雲上建構的專用網路,公共 IP 為 212.212.212.212。
問題是 SiteB 中的主機無法從 SiteA 中的主機訪問。同時,它們可以直接從 SiteA 端點訪問。我確信我錯過了一些非常簡單和明顯的東西。
SiteA 端點配置
如果配置
eth0 Link encap:Ethernet HWaddr 00:00:00:46:76:84 inet addr:95.95.95.95 Bcast:95.95.95.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:249492177 errors:0 dropped:395296 overruns:0 frame:0 TX packets:13730009 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:39576084672 (39.5 GB) TX bytes:8388420192 (8.3 GB) tun0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 inet addr:10.113.0.1 P-t-P:10.113.0.1 Mask:255.255.255.0 UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1 RX packets:13968 errors:0 dropped:0 overruns:0 frame:0 TX packets:11554 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:100 RX bytes:1069136 (1.0 MB) TX bytes:4425784 (4.4 MB)
IPSec 連接:
conn portal-vcd authby=secret auto=start ## phase 1 ## ike=aes128-md5-modp1024 ikelifetime=28800 keyexchange=ikev1 ## phase 2 ## esp=aes128-sha1-modp2048 type=tunnel leftid=95.95.95.95 left=95.95.95.95 leftsubnet=10.113.0.0/24 rightid=212.212.212.212 right=212.212.212.212 rightsubnet=10.200.0.0/24
來自 Endpoint 的 Traceroute 沒問題
traceroute 10.200.0.1 traceroute to 10.200.0.1 (10.200.0.1), 30 hops max, 60 byte packets 1 10.200.0.254 (10.200.0.254) 3.042 ms 2.979 ms 2.943 ms 2 10.200.0.1 (10.200.0.1) 3.457 ms 3.472 ms 3.051 ms
IP xfrm 策略:
ip xfrm policy src 10.113.0.0/24 dst 10.200.0.0/24 dir out priority 2883 tmpl src 95.95.95.95 dst 212.212.212.212 proto esp reqid 1 mode tunnel
路線表:
route Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface default 95.95.95.254 0.0.0.0 UG 0 0 0 eth0 10.113.0.0 * 255.255.255.0 U 0 0 0 tun0 95.95.95.0 * 255.255.255.0 U 0 0 0 eth0
iptables NAT:
Chain POSTROUTING (policy ACCEPT 174 packets, 12723 bytes) num pkts bytes target prot opt in out source destination 1 96 5928 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 policy match dir out pol ipsec 2 0 0 MASQUERADE all -- * eth0 10.113.0.0/24 0.0.0.0/0
SiteA VPS 配置
如果配置:
eth0 Link encap:Ethernet HWaddr 00:00:00:34:22:23 inet addr:178.X.X.X Bcast:178.X.X.255 Mask:255.255.254.0 inet6 addr: fe80::200:ff:fe34:2223/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:5599082 errors:0 dropped:48196 overruns:0 frame:0 TX packets:300211 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:918538724 (918.5 MB) TX bytes:706426556 (706.4 MB) tun0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 inet addr:10.113.0.2 P-t-P:10.113.0.2 Mask:255.255.255.0 UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1 RX packets:384 errors:0 dropped:0 overruns:0 frame:0 TX packets:1590 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:100 RX bytes:80459 (80.4 KB) TX bytes:124217 (124.2 KB)
我添加了一條靜態路由
route Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface default 178.X.X.X 0.0.0.0 UG 0 0 0 eth0 10.113.0.0 * 255.255.255.0 U 0 0 0 tun0 10.200.0.0 10.113.0.1 255.255.255.0 UG 0 0 0 tun0 178.X.X.0 * 255.255.254.0 U 0 0 0 eth0
Traceroute 顯示數據包已發送到 10.113.0.1,但在我看來似乎沒有路由到那裡的 IPSec。
traceroute 10.200.0.1 traceroute to 10.200.0.1 (10.200.0.1), 30 hops max, 60 byte packets 1 10.113.0.1 (10.113.0.1) 1.887 ms 2.453 ms 2.452 ms 2 * * *
什麼是錯誤配置?謝謝!!
在@MadHatter 評論後編輯:
ICMP 請求的 Tcpdump #ServerA tun0:
tcpdump -n -n -i tun0 host 10.200.0.1 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on tun0, link-type RAW (Raw IP), capture size 262144 bytes 08:52:32.011631 IP 10.113.0.2 > 10.200.0.1: ICMP echo request, id 24258, seq 10, length 64 08:52:33.011614 IP 10.113.0.2 > 10.200.0.1: ICMP echo request, id 24258, seq 11, length 64
流量從隧道返回後,ServerA 上 ACMP 響應的 Tcpdump:
tcpdump -n -n -i eth0 host 10.200.0.1 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes 08:52:45.014288 IP 10.200.0.1 > 10.113.0.2: ICMP echo reply, id 24258, seq 23, length 64 08:52:46.014010 IP 10.200.0.1 > 10.113.0.2: ICMP echo reply, id 24258, seq 24, length 64
所有 iptables 規則的列表。正如@MadHatter 在評論轉發中所說,預設情況下必須打開。但我提到它適用於 tun0 -> eth0 流量,但對於 eth0 -> tun0 則不是。
iptables -L -n -v Chain INPUT (policy ACCEPT 3380K packets, 1704M bytes) pkts bytes target prot opt in out source destination Chain FORWARD (policy DROP 1095 packets, 91824 bytes) pkts bytes target prot opt in out source destination 2886 236K DOCKER-USER all -- * * 0.0.0.0/0 0.0.0.0/0 2886 236K DOCKER-ISOLATION all -- * * 0.0.0.0/0 0.0.0.0/0 0 0 ACCEPT all -- * docker0 0.0.0.0/0 0.0.0.0/0 ctstate RELATED,ESTABLISHED 0 0 DOCKER all -- * docker0 0.0.0.0/0 0.0.0.0/0 0 0 ACCEPT all -- docker0 !docker0 0.0.0.0/0 0.0.0.0/0 0 0 ACCEPT all -- docker0 docker0 0.0.0.0/0 0.0.0.0/0 0 0 ACCEPT all -- eth1 eth0 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED 1020 85632 ACCEPT all -- tun0 eth0 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED 637 47172 ACCEPT all -- tun0 eth0 0.0.0.0/0 0.0.0.0/0 Chain OUTPUT (policy ACCEPT 105K packets, 13M bytes) pkts bytes target prot opt in out source destination Chain DOCKER (1 references) pkts bytes target prot opt in out source destination Chain DOCKER-ISOLATION (1 references) pkts bytes target prot opt in out source destination 2886 236K RETURN all -- * * 0.0.0.0/0 0.0.0.0/0 Chain DOCKER-USER (1 references) pkts bytes target prot opt in out source destination 24177 70M RETURN all -- * * 0.0.0.0/0 0.0.0.0/0
我為 eth0 -> tun0 添加了轉發規則
iptables -A FORWARD -i eth0 -o tun0 -j ACCEPT
它神奇地起作用了!主持人A:
ping 10.200.0.1 PING 10.200.0.1 (10.200.0.1) 56(84) bytes of data. 64 bytes from 10.200.0.1: icmp_seq=1 ttl=62 time=3.17 ms 64 bytes from 10.200.0.1: icmp_seq=2 ttl=62 time=2.88 ms
在 Karma 中為@MadHatter +1。
我們曾經
tcpdump
檢查進出兩個防火牆節點的流量。我順便指出tcpdump
,在現代核心中使用 {Open,Libre,Strong}S/WAN 可能會有點問題,因為在加密流量進出的介面上,只有當它離開時才會看到明文流量,而不是當它到達時。儘管如此,
tcpdump
為了遵循流程,我們已經確定 ICMP 回應要求從網路 A 一直傳遞到網路 B,並且響應一直返回到伺服器 A(網路 A OpenVPN 伺服器/IPSec 隧道崩潰點) ,但它們並沒有通過它傳遞給 OpenVPN 客戶端。由於流量是向外轉發的,因此流量轉發沒有一般問題,因此我們懷疑防火牆規則。您添加了一條規則,以允許將流量從外部網路轉發到 OpenVPN
tun0
介面,從而實現了完全連接。您可能希望稍微改進該規則,例如讓它顯式應用於通過 IPSec 連接到達的流量
iptables -A FORWARD -i eth0 -o tun0 -m policy --pol ipsec --dir in -j ACCEPT
或者也許讓它有狀態感知,但這些都是改進,取決於你。