如何停止發送協議 41 無法訪問的數據包？
我在我的一個 VPS 上使用了 Hurricane Electric 隧道，但它沒有完全工作。我使用與此腳本基本相同的腳本設置隧道：http ://www.cybermilitia.net/2013/07/22/ipv6-tunnel-on-openvz/ ，僅對我的特定設置進行了修改。我可以 ping 伺服器並從中獲取網頁，但我從 ping6 得到以下輸出：
root@unixshell:~# ping6 -c4 2001:470:1f0e:12a7::2 PING 2001:470:1f0e:12a7::2(2001:470:1f0e:12a7::2) 56 data bytes From 2002:d8da:e02a::1 icmp_seq=1 Destination unreachable: Address unreachable 64 bytes from 2001:470:1f0e:12a7::2: icmp_seq=1 ttl=63 time=96.4 ms 64 bytes from 2001:470:1f0e:12a7::2: icmp_seq=2 ttl=63 time=73.2 ms From 2002:d8da:e02a::1 icmp_seq=2 Destination unreachable: Address unreachable --- 2001:470:1f0e:12a7::2 ping statistics --- 2 packets transmitted, 2 received, +2 errors, 0% packet loss, time 1005ms rtt min/avg/max/mdev = 73.256/84.838/96.420/11.582 ms在問題伺服器上，執行 tcpdump，我同時看到了上述內容：
root@tektonic:~# tcpdump -n not port 22 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on venet0, link-type LINUX_SLL (Linux cooked), capture size 262144 bytes 21:25:44.000024 IP 216.218.224.42 > 207.210.83.205: IP6 2002:cfd2:4a7c::1 > 2001:470:1f0e:12a7::2: ICMP6, echo request, seq 1, length 64 21:25:44.000094 IP 207.210.83.205 > 216.218.224.42: ICMP 207.210.83.205 protocol 41 port 0 unreachable, length 132 21:25:44.000629 IP 207.210.83.205 > 216.218.224.42: IP6 2001:470:1f0e:12a7::2 > 2002:cfd2:4a7c::1: ICMP6, echo reply, seq 1, length 64 21:25:45.020972 IP 216.218.224.42 > 207.210.83.205: IP6 2002:cfd2:4a7c::1 > 2001:470:1f0e:12a7::2: ICMP6, echo request, seq 2, length 64 21:25:45.021059 IP 207.210.83.205 > 216.218.224.42: ICMP 207.210.83.205 protocol 41 port 0 unreachable, length 132 21:25:45.021260 IP 207.210.83.205 > 216.218.224.42: IP6 2001:470:1f0e:12a7::2 > 2002:cfd2:4a7c::1: ICMP6, echo reply, seq 2, length 64 ^C 6 packets captured 6 packets received by filter 0 packets dropped by kernel這是我的 iptables 配置的相關部分：
root@tektonic:~# iptables --list | egrep '41|ipv6' ACCEPT ipv6 -- anywhere anywhere ACCEPT ipv6 -- anywhere anywhere我意識到我可以停止使用 iptables 發送 ICMP 不可達消息，如此處所述：禁用 ICMP 不可達回复，但這是一個次優的解決方案。關於如何在無需探勘核心原始碼的情況下解決實際問題的任何想法？
錯誤消息的“埠 0”部分是一條紅鯡魚。6in4 數據包只是一個帶有 ipv4 標頭的 ipv6 數據包，因此在 ipv4 級別沒有埠號。但是，正在發送的 ICMP 數據包的類型號為 3，程式碼號為 3，意思是“埠不可達”，而不是程式碼 2，“協議不可達”。這是一個：
12:15:51.011697 IP 207.210.83.205 > 216.218.224.42: ICMP 207.210.83.205 protocol 41 port 0 unreachable, length 132 0x0000: 45c0 0098 8d6c 0000 4001 0f94 cfd2 53cd E....l..@.....S. 0x0010: d8da e02a 0303 62fb 0000 0000 4500 007c ...*..b.....E..| 0x0020: 9157 4000 f829 145c d8da e02a cfd2 53cd .W@..).\...*..S. 0x0030: 6000 0000 0040 3a3b 2002 cfd2 4a7c 0000 `....@:;....J|.. 0x0040: 0000 0000 0000 0001 2001 0470 1f0e 12a7 ...........p.... 0x0050: 0000 0000 0000 0002 8000 aa6e 1022 0002 ...........n.".. 0x0060: ad8a c355 ce94 0a00 0809 0a0b 0c0d 0e0f ...U............ 0x0070: 1011 1213 1415 1617 1819 1a1b 1c1d 1e1f ................ 0x0080: 2021 2223 2425 2627 2829 2a2b 2c2d 2e2f .!"#$%&'()*+,-./ 0x0090: 3031 3233 3435 3637 01234567$$ update 2015-08-06 $$將 tb_userspace 升級到修訂版 18，沒有變化。 $$ update 2015-08-09 $$ tb_userspace.c line 163:
sockv6 = socket(AF_INET, SOCK_RAW, IPPROTO_IPV6);，並lsof -c tb_userspace顯示套接字確實已創建：tb_usersp 6614 root 4u raw 0t0 1559059549 CD53D2CF:0029->00000000:0000 st=07$$ update 2015-08-09 17:18 PDT $$確認在沒有 openvz 的普通核心上存在同樣的問題：jcomeau@unixshell:~$ ping6 2001:470:66:79d::2 PING 2001:470:66:79d::2(2001:470:66:79d::2) 56 data bytes 64 bytes from 2001:470:66:79d::2: icmp_seq=1 ttl=60 time=86.5 ms From 2001:470:0:206::2 icmp_seq=1 Destination unreachable: Address unreachable 64 bytes from 2001:470:66:79d::2: icmp_seq=2 ttl=60 time=83.4 ms From 2001:470:0:206::2 icmp_seq=2 Destination unreachable: Address unreachable 64 bytes from 2001:470:66:79d::2: icmp_seq=3 ttl=60 time=86.1 ms From 2001:470:0:206::2 icmp_seq=3 Destination unreachable: Address unreachable ^C --- 2001:470:66:79d::2 ping statistics --- 3 packets transmitted, 3 received, +3 errors, 0% packet loss, time 2012ms rtt min/avg/max/mdev = 83.429/85.376/86.556/1.427 ms jcomeau@unixshell:~$ logout Connection to www closed. jcomeau@aspire:~$ uname -a Linux aspire 3.2.0-4-amd64 #1 SMP Debian 3.2.54-2 x86_64 GNU/Linux還刷新了 iptables 和 ip6tables 並刪除了所有 netfilter 模組。相同的症狀。
$$ update 2015-08-11 01:04 $$ 從http://linux.die.net/man/7/raw發現，在將原始數據包發送到任何原始套接字後，核心仍會將其傳遞給為該協議註冊的任何模組。我自己的上網本上的模組是我正在測試的“沒有openvz的原始核心”，它是tunnel4。一旦我刪除它，目標無法到達的消息就會停止。我假設我的 VPS 上的單片核心中內置了相同的模組。/proc/kallsyms 上不存在，所以我必須聯繫客戶支持。 $$ update 2015-08-11 01:50 $$ http://www.haifux.org/lectures/217/netLec5.pdf也是一個有幫助的資源。
正如問題更新中所指出的，問題在於核心將數據包傳遞到正在偵聽該協議的任何原始套接字之後，它會將其交給為同一協議註冊的任何核心模組。因為我一直在上網本上使用坐隧道，所以即使我臨時設置了 tb_userspace 隧道進行測試，隧道 4 模組仍然載入；因此，由於它已註冊，但未配置任何處理程序，因此它拒絕了帶有 ICMP 3:3 消息的數據包。
rmmod sit隨後rmmod tunnel4解決了這個問題。在最初的問題伺服器上，這並不容易，因為它是一個帶有單片核心的 openvz VPS，正如客戶端“盒子”所見。但有了來自http://linux.die.net/man/7/raw>和<http://www.haifux.org/lectures/217/netLec5.pdf的資訊，我能夠與提供商合作解決問題。在這種情況下，他們重新安裝了 sat 模組，所以我根本不需要使用 tb_userspace 隧道軟體。但我懷疑問題是隧道4也安裝在那裡。