--- Begin Message ---
On Fri, Jan 16, 2026 at 05:30:03PM +0100, [email protected] wrote:
Moin,
ich hatte gedacht, ich hätte das mit dem Routing verstanden.
Ist aber offenbar doch nicht so.
Kann mir jemand erklären, warum 1.1.1.1 durch das VPN
geroutet wird und nicht direkt über die Defaultroute
rausgeht?
hajo@ryzen:~$ ip route get 1.1.1.1
1.1.1.1 dev wg_fritz table 52110 src 192.168.178.203 uid 1000
cache
hajo@ryzen:~$ ip r
default via 172.19.88.94 dev wlo1 proto dhcp src 172.19.88.122 metric 600
172.19.88.0/24 dev wlo1 proto kernel scope link src 172.19.88.122 metric 600
192.168.178.0/24 dev wg_fritz proto static scope link metric 50
192.168.178.0/24 dev wg_fritz proto kernel scope link src 192.168.178.203
metric 50
Also - die anderen beiden haben ja schon geschrieben was du dir ansehen
kannst.
Der Trick hier ist das es mehr als eine routing tabelle geben kann. Es
gibt eine "default" table - die hast du dir ja mit "ip r" angesehen.
Jetzt kann es mehr als eine geben (z.b. du hast 2 Interfaces und beide
sollen traffic der da ankommt da auch wieder raus schieben).
Aber zusätzlich zu den routing tabellen musst du dem kernel noch sagen
wenn er denn welche routingtabelle nehmen soll.
Das wird über "ip rule"s gemacht
Default setup:
flo@p5:~$ sudo ip rule
0: from all lookup local
32766: from all lookup main
32767: from all lookup default
Hier sieht man schon das es im default schon 3 routing tabellen gibt.
Das wird genutzt um die verschiedenen routen zu separieren. Denn das
was du mit "ip r" siehst ist ja nur das was du manuell konfigurierst.
Dazu kommen ja multicast, loopback und so dinge wie broadcast etc.
Das wird alles in der "local" versteckt.
Wie man in den rules sieht werden die einfach nacheinander angefahren.
Was du jetzt dir mit "ip r get 1.1.1.1" angesehen hast ist nicht die routing
tabelle sondern der "route cache". Sieht man an dem "cache" am ende.
Wobei den "route cache" gibt es wiederum gar nicht mehr. Das ist jetzt
der FIB (NH) Cache. (FIB -> Forward Information Base)
Denn sagen wir du hast den route lookup gemacht dann weisst du das du
dein paket bei 192.168.178.1 abkippen willst. Das würde aber bedeuten
das du für jedes paket wieder einen ARP Lookup im cache machen müsstest.
Um das zu beschleunigen werden die nexthop informationen für jede
destination im fib cache abgelegt.
Der FIB Cache ist dann auch wieder mehrteilig. Mit realen und exception
destinations. In dem zeugs wird dann auch die Path MTU information und
IIRC die RTT abgelegt (Initialisierung des TCP congestion algo)
Also - es ist alles noch viel viel viel komplexer als man so glaubt -
das liegt zum großteil da dran das man da performance rauskitzeln will.
Und ich meine da gibt es dann noch prozess und socket basierende
Informationen. Wenn ich einen connected socket habe für eine destination
dann ist das immer dieselbe destination (Es sei denn es ist SCTP)
Und mit der ganzen verwirrung.
Flo
--
Florian Lohoff [email protected]
Any sufficiently advanced technology is indistinguishable from magic.
signature.asc
Description: PGP signature
--- End Message ---
--
Linux mailing list [email protected]
subscribe/unsubscribe: https://lug-owl.de/mailman/listinfo/linux
Hinweise zur Nutzung: http://www.lug-owl.de/Mailingliste/hints.epo
