Ipv6

OpenVPN 網關不回复 IPv6 ping,但轉發包

  • November 23, 2019

我正在嘗試調試我的 IPv6 網路並遇到了一個我無法理解的問題。

我使用 OpenVPN 作為我的 VPN 伺服器,下面是設置的簡圖:

具有雙宿主 VPN 伺服器的 IPv6 網路 當我嘗試從 VPN Client ( 2001:470:7875:1::2) ping 到 VPN Server ( 2001:470:7875:1::1) 時,所有包都被丟棄了,但奇怪的是:

我可以通過 IPv6 ping 任何其他主機(如 Google)或通過 IPv6 連接到同一 VPN 伺服器的任何其他 VPN 客戶端。

我還可以在其本地 IPv6 介面 ( ens3) 上 ping 我的 VPN 伺服器。只有 VPN 伺服器介面 ( tun0) 在直接 ping 時不響應。

因此,我想知道發生了什麼?

由於我有兩個 IPv6 連結到網際網路的 IPv6 版本,我必須做基於策略的路由。規則非常簡單。

  • 只有源自 VPN 伺服器本身的 IPv6 包才允許通過本機 IPv6 連結發送。
  • 所有其他 IPv6 包必須由 Hurricane Electric IPv6 隧道處理。

這導致我在 VPN 伺服器上的以下路由表:

該命令ip -6 rule show具有以下設置:

0:      from all lookup local
32000:  from 2001:470:7875::/48 lookup openvpn
32766:  from all lookup main

local

local ::1 dev lo proto kernel metric 0 pref medium
anycast 2001:470:1f14:2c7:: dev he-ipv6 proto kernel metric 0 pref medium
local 2001:470:1f14:2c7::2 dev he-ipv6 proto kernel metric 0 pref medium
anycast 2001:470:7875:1:: dev tun0 proto kernel metric 0 pref medium
local 2001:470:7875:1::1 dev tun0 proto kernel metric 0 pref medium
anycast 2a01:xxx:xxxx:: dev ens3 proto kernel metric 0 pref medium
local 2a01:xxx:xxxx:xxx::1 dev ens3 proto kernel metric 0 pref medium
anycast fe80:: dev ens3 proto kernel metric 0 pref medium
anycast fe80:: dev tun0 proto kernel metric 0 pref medium
anycast fe80:: dev he-ipv6 proto kernel metric 0 pref medium
local fe80::95d2:9e6b dev he-ipv6 proto kernel metric 0 pref medium
local fe80::5054:ff:fe66:f97f dev ens3 proto kernel metric 0 pref medium
local fe80::af96:f1e3:dbf3:96a7 dev tun0 proto kernel metric 0 pref medium
ff00::/8 dev ens3 metric 256 pref medium
ff00::/8 dev tun0 metric 256 pref medium
ff00::/8 dev he-ipv6 metric 256 pref medium

main

local ::1 dev lo proto kernel metric 256 pref medium
2001:470:1f14:2c7::/64 dev he-ipv6 proto kernel metric 256 pref medium
2001:470:7875:1::/64 dev tun0 proto kernel metric 256 pref medium
unreachable 2001:470:7875::/48 dev lo metric 1024 error -113 pref medium
2xxx:xxx:xxxx::/48 dev ens3 proto kernel metric 256 pref medium
fe80::/64 dev ens3 proto kernel metric 256 pref medium
fe80::/64 dev tun0 proto kernel metric 256 pref medium
fe80::/64 dev he-ipv6 proto kernel metric 256 pref medium
default via 2a01:xxx:xxxx::1 dev ens3 metric 1024 pref medium

openvpn

unreachable 2001:470:7875::/48 dev lo metric 1024 error -113 pref medium
default via 2001:470:1f14:2c7::1 dev he-ipv6 metric 1024 pref medium

有誰能給我指點一下嗎?:-)


快速回顧一下路由表中無法到達的線路

2001:470:1f14:2c7::/64 dev he-ipv6 proto kernel metric 256 pref medium
2001:470:7875:1::/64 dev tun0 proto kernel metric 256 pref medium
unreachable 2001:470:7875::/48 dev lo metric 1024 error -113 pref medium

的範圍2001:470:7875::/48是從2001:470:7875:0:0:0:0:02001:470:7875:ffff:ffff:ffff:ffff:ffff

我已將子網分配2001:470:7875:1::/64給 VPN 隧道。

  • 2001:470:7875:1::/642001:470:7875::/48子網的一部分,這可能會導致路由表中的衝突。
  • 2001:470:1f14:2c7::/64不是子網的一部分,因此不會2001:470:7875::/48與路由表衝突。

沒有其他 IP 範圍正在使用,但將在未確定的以後日期。

記住最長前綴獲勝給我們以下行為:

  • 子網的任何 IP 包2001:470:1f14:2c7::/64都將由 he-ipv6 介面處理。
  • 子網的任何 IP 包2001:470:7875:1::/64都將由 tun0 介面處理。
  • 2001:470:7875::/48 子網的所有其他IP 包將被回復為無法訪問。

所以…

經過更多的探勘,我發現我的設置可以稍微改進一下,儘管我並不完全相信我已經覆蓋了所有的基礎。

無論如何ip -6 rule show可以稍微調整一下。

該行:

32000:  from 2001:470:7875::/48 lookup openvpn

由以下命令生成:

ip -6 rule add priority 32000 from 2001:470:7875::/48 table openvpn

這可以簡化為:

ip -6 rule add priority 32000 iif tun0 to 2000::/3 table openvpn

這意味著基本上所有基於 IPv6 的流量都必須查找表openvpn ,當且僅當流量來自 VPN 連結並且目標地址屬於2003::/3,這基本上是整個官方 IPv6 網際網路 - 不包括 fe80::/10 和 fc 等本地地址::/7。

最終結果是來自我的 VPN 連結的 IPv6 流量始終通過 Hurricane Electric 連結轉發。

要記住的事情。每當我從該範圍內的可用地址池中添加一個新子網時, 2001:470:7875::/48我都必須輸入兩個條目。

  • 表中的一項main,說明如何將包從 VPN 伺服器轉發到新子網。
  • 表中的 Onopenvpn說明 VPN 客戶端如何到達新子網。這通常是在通過 VPN 連結從一個客戶端到另一個客戶端的站點到站點流量時。

無論如何:Ping 現在可以正常工作,我仍然可以通過 IPv6 ping Google。

該命令ip -6 rule show現在提供以下輸出:

0:      from all lookup local
32000:  from all to 2000::/3 iif tun0 lookup openvpn
32766:  from all lookup main

其他一切都是從最初的問題開始的。

Traceroute 有點棘手,但只要使用 ICMP Echo 包就可以了。

在我的 VPN 客戶端上執行命令traceroute -6 -I google.com給出了以下跟踪:

traceroute to google.com (2a00:1450:400e:80b::200e), 30 hops max, 80 byte packets
1  2001:470:7875:1::1 (2001:470:7875:1::1)  16.868 ms  37.912 ms  37.847 ms
2  tunnel547738.tunnel.tserv11.ams1.ipv6.he.net (2001:470:1f14:2c7::1)  37.777 ms  37.710 ms  37.647 ms
3  10ge11-20.core1.ams1.he.net (2001:470:0:7d::1)  37.575 ms  37.509 ms  37.443 ms
4  amsix-router.google.com (2001:7f8:1::a501:5169:1)  37.453 ms  52.425 ms  52.392 ms
5  2001:4860:0:f8d::1 (2001:4860:0:f8d::1)  52.323 ms  52.259 ms  52.189 ms
6  2001:4860:0:1::219f (2001:4860:0:1::219f)  36.456 ms  25.560 ms  18.169 ms
7  ams17s01-in-x0e.1e100.net (2a00:1450:400e:80b::200e)  34.566 ms  34.502 ms  34.435 ms

引用自:https://serverfault.com/questions/993051