fragen stichworte

Wie kann ich das Senden von nicht erreichbaren Paketen 41 verhindern?

Ich verwende einen Hurricane Electric-Tunnel für einen meiner VPS, der nicht vollständig funktioniert. Ich habe den Tunnel mit einem Skript aufgebaut, das im Wesentlichen mit diesem identisch ist: http://www.cybermilitia.net/2013/07/22/ipv6-tunnel-on-openvz/, wobei nur Änderungen für meine vorgenommen wurden bestimmte Einrichtung. Ich kann den Server anpingen und eine Webseite daraus abrufen, aber ich erhalte folgende Ausgabe von 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

auf dem Problemserver, auf dem tcpdump ausgeführt wird, sehe ich dies gleichzeitig mit dem oben genannten:

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

Und hier ist der relevante Teil meiner iptables-Konfiguration:

root@tektonic:~# iptables --list | egrep '41|ipv6'
ACCEPT     ipv6 --  anywhere             anywhere            
ACCEPT     ipv6 --  anywhere             anywhere

Ich merke, dass ich das Senden von nicht erreichbaren ICMP-Nachrichten mit iptables beenden kann, wie hier erwähnt: Deaktivieren Sie nicht erreichbare ICMP-Antworten, dies ist jedoch eine suboptimale Lösung. Irgendwelche Ideen, wie das eigentliche Problem behoben werden kann, ohne die Kernelquellen durchforsten zu müssen?

Der Teil "Port 0" der Fehlermeldung ist ein roter Hering. Ein 6in4-Paket ist einfach ein ipv6-Paket mit einem vorangestellten ipv4-Header und hat daher keine Portnummer auf der ipv4-Ebene. Die gesendeten ICMP-Pakete haben jedoch eine Typennummer von 3 und die Codenummer 3, was "Port nicht erreichbar" bedeutet, nicht Code 2, "Protokoll nicht erreichbar". Hier ist einer:

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 wurde auf Version 18 aktualisiert, keine Änderung.

[Update 2015-08-09] tb_userspace.c Zeile 163: sockv6 = socket(AF_INET, SOCK_RAW, IPPROTO_IPV6); und lsof -c tb_userspace zeigt, dass der Socket tatsächlich erstellt wird: tb_usersp 6614 root 4u raw 0t0 1559059549 CD53D2CF:0029->00000000:0000 st=07

[Update 2015-08-09 17:18 PDT] hat bestätigt, dass das gleiche Problem auf einem einfachen Kernel ohne openvz vorhanden ist:

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

spülte auch iptables und ip6tables und entfernte alle netfilter-Module. dasselbe Symptom

[Update 2015-08-11 01:04] In http://linux.die.net/man/7/raw wurde festgestellt, dass der Kernel, nachdem ein Rohpaket an Roh-Sockets gesendet wurde, es weiterhin an alle für dieses Protokoll registrierten Module weiterleitet . Das Modul auf meinem eigenen Netbook, dem "rohen Kernel ohne openvz", auf dem ich testete, war tunnel4. Sobald ich es entfernte, wurden die nicht erreichbaren Zielnachrichten angehalten. Ich gehe davon aus, dass das gleiche Modul in den monolithischen Kernel meines VPS eingebaut ist./proc/kallsyms ist nicht darauf vorhanden, daher muss ich mich an den Kundendienst wenden.

[Update 2015-08-11 01:50] http://www.haifux.org/lectures/217/netLec5.pdf ist eine Ressource, die auch geholfen hat.

antworten

Wie in den Aktualisierungen der Frage erwähnt, besteht das Problem darin, dass das Paket nach dem Übergeben des Pakets an alle Roh-Sockets, die dieses Protokoll abhören, dann an einen -Kernel weitergibt Module für dasselbe Protokoll registriert. Da ich einen Sit-Tunnel auf meinem Netbook verwendet hatte, war das Tunnel4-Modul immer noch geladen, obwohl ich den Tb_userspace-Tunnel vorübergehend zum Testen eingerichtet hatte. Da es registriert war, aber keine Handler konfiguriert waren, wies es die Pakete mit der ICMP-3: 3-Nachricht zurück. rmmod sit gefolgt von rmmod tunnel4 löste das Problem.

auf dem ursprünglichen Problemserver war es nicht so einfach, da es sich um einen openvz-VPS mit einem monolithischen Kernel handelt, wie er von den Client-Boxen angezeigt wird. aber bewaffnet mit den Informationen von http://linux.die.net/man/7/raw und http://www.haifux.org/lectures/217/netLec5.pdf Ich konnte mit dem Anbieter zusammenarbeiten, um das Problem zu lösen. In diesem Fall wurde das Sit-Modul erneut installiert, sodass ich die Tb_userspace-Tunnelsoftware nicht verwenden musste. aber ich vermute, das problem war, dass dort auch tunnel4 installiert wurde.

Es sieht so aus, als ob tektonic nicht die Adresse 2001: 470: 1f0e: 12a7 :: 2 hat, die seiner venet0-Schnittstelle zugewiesen ist. Es empfängt die Pakete und weist sie zurück, obwohl sie wohlgeformt sind.

Als Nächstes sollten Sie überprüfen, ob tektonic TCP-Verbindungen zu reinen IPv6-Hosts wie ipv6.google.com herstellen kann und dass die Pakete tatsächlich über die IPv4-Kapselung zum konfigurierten Hurricane Electric-Relay-Host weitergeleitet werden. Wenn TCP durchkommt, ICMP jedoch nicht, dann handelt es sich definitiv um ein Endpunktfilterproblem (d. H. Firewall-Regeln).

Die ICMP-Fehler werden vom Kernel gesendet, da kein Socket zum Empfangen von Protokoll 41-Paketen mit dieser bestimmten Kombination aus Quell- und Ziel-IP-Adresse existiert.

Wenn ein Prozess einen Raw-Socket mit Protokoll 41 erstellt, wird der Kernel die ICMP-Fehler nicht mehr erzeugen. Ein solcher Socket empfängt standardmäßig Pakete von allen Quell-IP-Adressen, die an eine Ziel-IP gesendet werden, die der lokalen Maschine zugewiesen ist. Mit dem Bind- und/oder Connect-Systemaufruf kann die Anwendung einschränken, welche Kombination aus Quell- und Ziel-IP-Adresse sie empfängt. Pakete, die keinem solchen Socket entsprechen, erzeugen immer noch ICMP-Fehler.

Es ist klar, dass in Ihrem Fall die Pakete gleichzeitig vom Tunnel empfangen werden und ICMP-Fehler erzeugen. Aber gemäß meiner obigen Beschreibung ist es für ein Paket, das von einem Socket empfangen wird, unmöglich, auch die ICMP-Fehlermeldung zu erzeugen. Es gibt jedoch andere Möglichkeiten, wie das Paket empfangen werden kann, was den Kernel nicht daran hindert, ICMP-Fehler zu erzeugen.

Es ist möglich, dass ein Socket Pakete in einer niedrigeren Protokollschicht empfängt, in der alle Pakete ungeachtet der IP-Protokollnummer sichtbar sind. Wenn die von Ihnen verwendete Tunnel-Software einen solchen Low-Level-Socket zum Empfang von Protokoll 41-Paketen verwendet, werden ICMP-Fehler erzeugt, wie in Ihrer Frage beschrieben.

Wenn dies die Tunnel-Software ist, dann würde ich es als Konstruktionsfehler in der Tunnel-Software betrachten. In diesem Fall haben Sie drei Möglichkeiten:

  • Umgehen Sie den Fehler, indem Sie Pakete filtern (zum Beispiel mit iptables).
  • Holen Sie sich die Quelle für die Software und beheben Sie den Konstruktionsfehler.
  • Wechseln Sie zu anderer Software ohne diesen Konstruktionsfehler.