IPv6 - chaotisches lokales Routing

P

PMc

Well-Known Member
Also, bei IPv4 war die Spielregel immer so, dass aller lokaler Traffic immer durch das 'lo0' interface geht - egal welche IP-Adresse verwendet wird, und egal auf welchem Interface diese IP-Adresse gebunden ist.
Das ist auch nachvollziehbar aus der Routing-Tabelle:

Code: 
root@xxxx:~ # ifconfig
vtnet0: flags=8863<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
        inet 192.168.97.15 netmask 0xffffffe0 broadcast 192.168.97.31
        inet6 fd00::1 prefixlen 64
root@xxxx:~ # netstat -rn
Routing tables

Internet:
Destination        Gateway            Flags     Netif Expire
127.0.0.1          link#2             UH          lo0
192.168.97.0/27    link#1             U        vtnet0
192.168.97.15      link#1             UHS         lo0 <<<<<<

Während das netz 192.168.97.0/27 an 'vtnet0' hängt, ist die lokale Adresse selber an 'lo0'.
Im praktischen Einsatz sieht das dann so aus:

Code: 
root@xxxx:~ # ping 192.168.97.15
ipfw: 1 Accept ICMP:8.0 127.0.0.1 192.168.97.15 out via lo0
ipfw: 1 Accept ICMP:8.0 127.0.0.1 192.168.97.15 in via lo0
ipfw: 1 Accept ICMP:0.0 192.168.97.15 127.0.0.1 out via lo0
ipfw: 1 Accept ICMP:0.0 192.168.97.15 127.0.0.1 in via lo0

root@xxxx:~ # telnet 192.168.97.15 7777
ipfw: 1 Accept TCP 192.168.97.15:52401 192.168.97.15:7777 out via lo0
ipfw: 1 Accept TCP 192.168.97.15:52401 192.168.97.15:7777 in via lo0
ipfw: 1 Accept TCP 192.168.97.15:7777 192.168.97.15:52401 out via lo0
ipfw: 1 Accept TCP 192.168.97.15:7777 192.168.97.15:52401 in via lo0

Alles geht immer schön durch lo0 (und da kann man es filtern, wenn man zB traffic zwischen non-vimage jails filtern will).

Und jetzt schauen wir uns dasselbe mal mit IPv6 an:

Code: 
root@xxxx:~ # ping fd00::1
ipfw: 1 Accept ICMPv6:128.0 [fd00::1] [fd00::1] out via lo0
ipfw: 1 Accept ICMPv6:128.0 [fd00::1] [fd00::1] in via lo0
ipfw: 1 Accept ICMPv6:129.0 [fd00::1] [fd00::1] out via lo0
ipfw: 1 Accept ICMPv6:129.0 [fd00::1] [fd00::1] in via lo0

root@xxxx:~ # telnet fd00::1 7777
ipfw: 1 Accept TCP [fd00::1]:53821 [fd00::1]:7777 out via lo0
ipfw: 1 Accept TCP [fd00::1]:53821 [fd00::1]:7777 in via vtnet0  <<<<<
ipfw: 1 Accept TCP [fd00::1]:7777 [fd00::1]:53821 out via lo0
ipfw: 1 Accept TCP [fd00::1]:7777 [fd00::1]:53821 in via lo0

Upsala! Was tut denn das 'vtnet0' da mittendrin??

Das ist aber noch lang noch nicht alles. Das ist ein RELEASE 13.0. Jetzt mal RELEASE 12.2:

Code: 
root@yyyy:~ # ping6 fd00::1
ipfw: 1 Accept ICMPv6:128.0 [fd00::1] [fd00::1] out via lo0
ipfw: 1 Accept ICMPv6:128.0 [fd00::1] [fd00::1] in via vtnet0
ipfw: 1 Accept ICMPv6:129.0 [fd00::1] [fd00::1] out via lo0
ipfw: 1 Accept ICMPv6:129.0 [fd00::1] [fd00::1] in via vtnet0

root@yyyy:~ # telnet fd00::1 7777
ipfw: 1 Accept TCP [fd00::1]:60375 [fd00::1]:7777 out via lo0
ipfw: 1 Accept TCP [fd00::1]:60375 [fd00::1]:7777 in via vtnet0
ipfw: 1 Accept TCP [fd00::1]:7777 [fd00::1]:60375 out via lo0
ipfw: 1 Accept TCP [fd00::1]:7777 [fd00::1]:60375 in via vtnet0

Au backe.

Mal soweit zusammengefaßt: das Verhalten ist
* inkonsistent zwischen incoming und outgoing
* inkonsistent zwischen originate und answer Flow
* inkonsistent zwischen Protokollen (ICMP vs. TCP)
* inkonsistent zwischen Releases

Und jetzt hab ich ein Problem damit. Ich bastel ja an diesem Teil hier, und würde das gern auch für IPv6 verwenden.

Aber wie soll ich das coden, wenn das Verhalten für jeden denkbaren Usecase ein anderes ist?

Und wen könnte ich vielleicht fragen wie das letztlich aussehen wird falls es irgendwann fertig ist?
(Die ipfw mailinglist scheint weitgehend leer zu sein.)
 
Zuletzt bearbeitet:
hi

ich sehe nicht was nicht nachvollziehbar ist.

auf localhost sollte man keine firewall regeln setzen , in pf sprache

skip lo

Holger
 
mark05 schrieb:
ich sehe nicht was nicht nachvollziehbar ist.
Zum Vergrößern anklicken....
Das verstehe ich nicht.

mark05 schrieb:
auf localhost sollte man keine firewall regeln setzen
Zum Vergrößern anklicken....
Das ist für einen firewall schon richtig, und macht da ja auch wenig Sinn. Ich mache aber eher einen Flow-Manager, für Priorisierung, Rerouting, Filtern, und eben auch Firewalling. Und der sollte schon alles behandeln können, was durch den IP-Stack geht.

mark05 schrieb:
, in pf sprache

skip lo
Zum Vergrößern anklicken....
Wie filterst Du dann jails - die laufen komplett über localhost. Ich mach das schon immer mit ipfw. Auch wenn ein jail zB einen separaten Provider-Uplink hat, hab ich das mit forwarding-Rules gemacht (lange bevor es fib oder vnet-jails gab - womit es natürlich leichter geht).

Und das Problem wirkt sich ja auch umgekehrt rum aus: wenn der localhost-Traffic teilweise mit dem richtigen Interface (hier vtnet0) getaggt ist, dann läuft er durch dessen Rules, auch wenn wir "lo" skippen - (und wird dann ggfs dort weggeschmissen).
... Ich sehe so langsam, @KobRheTilla hat recht, das ist tatsächlich schon eher ein Bug und nicht nur eine Unleidlichkeit...

Und der stateful tcp-keepalive geht auch über localhost. Vielleicht kommt daher die Idee, dass man das besser gar nicht anrührt - aber man kann es durchaus richtig machen, auch wenn es etwas haarig ist. Für ipv4 funktioniert das hier schon lange. (Bei der neuimplementation bin ich da grade dran.)

KobRheTilla schrieb:
ich denke auch nicht, dass ipfw da das Problem ist. Ich empfehle, einen Bugreport zu schreiben.
Zum Vergrößern anklicken....
Wo genau das Problem entsteht, weiss ich eh nicht. Der ipfw nutzt halt diese -offensichtlich nicht belastbaren- Daten für Entscheidungen, und damit wird es zum Problem.
 
hi

also eine firewall erstellt von sich aus keine verbindung , es sei den der admin ist auf dieser eingeloggt und erstellt eine.


ansonsten überleg mal wie ein ip stack arbeitet bzw wie er sich verhält . ( ipfw kannst du erstmal ausblenden )

ein ip stack ist immer geneigt direkt ein ziel anzusprechen.

ich denke mal das die verbindung von lo initiert wird wenn der rechner nich direkt mit dem ziel verbunden ist und
sich dann an der default route orientiert.

Holger

p.s. meine jails laufen alle au dem normalen ethernet intervace ( bhyve instanz vtnet0 )
 
rehi
mark05 schrieb:
ansonsten überleg mal wie ein ip stack arbeitet bzw wie er sich verhält . ( ipfw kannst du erstmal ausblenden )
Zum Vergrößern anklicken....
Ja und? Ich denke das weiss ich, und der IP stack ist ja nicht das Problem, der funktioniert ja. Aber die Pakete haben eine Information angefügt: das Interface auf dem sie reingekommen sind, und, wenn sie ausgehened geroutet sind, das interface auf dem sie rausgehen sollen.

Und das Problem hier ist, dass als empfangendes Interface bei IPv6 manchmal ein anderes auftaucht als bei IPv4. Und das kann ja so nicht sein - jedenfalls kann man dann darauf aufbauend keine sinnvollen Entscheidungen treffen (auf der Ebene shaping/rerouting/filtering).

mark05 schrieb:
ich denke mal das die verbindung von lo initiert wird wenn der rechner nich direkt mit dem ziel verbunden ist und
sich dann an der default route orientiert.
Zum Vergrößern anklicken....
Die fraglichen Pakete gehen immer durch lo0 rein und raus. Das steht außer frage.

Ich hab das inzwischen auf der Stable mailinglist vorgetragen, und da hat mir jemand einen Wink in den Code gegeben, der zwar ein totes ende ist, aber von da weitersuchend hab ich dann was gefunden: das Problem ist offenbar bekannt, und der BPF hat damit zunächst auch nicht funktioniert (logisch), und das hat man dann in Rev. 162539 schonmal gefixt.

rS162539

reviews.freebsd.org reviews.freebsd.org

KobRheTilla schrieb:
Ich empfehle, einen Bugreport zu schreiben.
Zum Vergrößern anklicken....
Den gibt es auch schon, seit 2012:

165190 – ipfw(4): lo(4) loopback interface is not marking IPv6 packets

bugs.freebsd.org bugs.freebsd.org
 
Zuletzt bearbeitet:
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben