OpenBSD Routing und Flags UC/UGS

pebwindkraft

pebwindkraft

Member
Hi,

ich krieg mal wieder irgendwas in meinem Kopf nicht hin :confused:
Ich möchte einen Laboraufbau erstellen, mit zwei Clients in unterschiedlichen Netzen, und dazwischen einen OpenBSD 6.0 als Router. Das ganze ohne Firewall (pf), nur erstmal reines "ping" und dann routing. Kann ja nicht so schwer sein, oder?
Plain vanilla dachte ich... Also minimale OpenBSD 6.0 in virtuellen Maschinen aufgebaut, kein pf, keine default Gateways, und fixe IP Adressen. OpenBSD Router mit sysctl net.inet.ip.forwarding=1 eingestellt, bzw. auch im config file. Setup:
Code: 
                      /-----------------------------\
/--------------\      |       OpenBSD Router        |      /----------------\
|   client 1   |______| IP 1                   IP 2 |______|      client 2  |
| 192.168.0.32 |      | 192.168.0.1   192.168.127.1 |      | 192.168.127.47 |
\--------------/      \-----------------------------/      \----------------/
Dann gebootet, alle IPv4 routen gelöscht:
Code: 
$ doas route  delete 192.168.0/24   
delete net 192.168.0/24
$ doas route  delete 192.168.127/24
delete net 192.168.127/24
$ netstat -rn -f inet (oder route -n show -inet):
Destination        Gateway            Flags   Refs      Use   Mtu  Prio Iface
192.168.0.1        08:00:aa:00:aa:01  UHLl       0        0     -     1 pcn0
192.168.0.255      192.168.0.1        UHb        0        0     -     1 pcn0
192.168.127.1      08:00:bb:12:7b:01  UHLl       0        0     -     1 pcn1
192.168.127.255    192.168.127.1      UHb        0        0     -     1 pcn1
dann funktioniert kein ping mehr zu den Clients (No route to host). Ok, nehme ich so hin. Dachte immer, das müsste auch ohne "routing" gehen, dass sich 2 Rechner direkt unterhalten...
Dann habe ich versucht, die Routen händisch einzubauen:
Code: 
$ doas route add -net 192.168.0/24 192.168.0.1
add net 192.168.0/24: gateway 192.168.0.1
$ doas route add -net 192.168.127/24 192.168.127.1
add net 192.168.127/24: gateway 192.168.127.1
Ich kann immer noch nicht "pingen". Was mache ich falsch?
Schaue ich mir die Routen an:
Code: 
$ netstat -rn -f inet
192.168.0/24       192.168.0.1        UGS        0        0     -     8 pcn0
192.168.0.1        08:00:aa:00:aa:01  UHLl       1        1     -     1 pcn0
192.168.0.255      192.168.0.1        UHb        0        0     -     1 pcn0
192.168.127/24     192.168.127.1      UGS        0        0     -     8 pcn1
192.168.127.1      08:00:bb:12:7b:01  UHLl       1        1     -     1 pcn1
192.168.127.255    192.168.127.1      UHb        0        0     -     1 pcn1
dann sehe ich einen "kleinen" Unterschied bei den -net Routen und Flags. Direkt nach dem Booten (wenn ping noch geht), sieht man das hier:
Code: 
192.168.0/24       192.168.0.1        UC         0        0     -     4 pcn0
192.168.127/24     192.168.127.1      UC         0        0     -     4 pcn1
...
Da ist der Unterschied also bei den Flags. Nach dem Booten hat OpenBSD "UC" gesetzt, lösche ich die Routen, und erstelle sie manuell, sind die Flags "UGS" gesetzt. Auflösung (man netstat!):
Code: 
U = RTF_UP           Route usable.
C = RTF_CLONING      Generate new routes on use.
G = RTF_GATEWAY      Destination requires forwarding by intermediary.
S = RTF_STATIC       Manually added.
Während U und S noch "ok" ist, ist für mich das G ein grosses Fragezeichen.
Na gut, dann setzen wir die Route halt mal mit "-iface" auf, nach "man route" heisst das:
Code: 
...
-iface        ~RTF_GATEWAY     destination is directly reachable

$ doas route add -net 192.168.127/24 -iface 192.168.127.1
$ netstat -rn -f inet
Destination        Gateway            Flags   Refs      Use   Mtu  Prio Iface
192.168.0/24       192.168.0.1        UGS        0        4     -     8 pcn0
192.168.127/24     192.168.127.1      US         0        5     -     8 pcn1
oha, kein "G" mehr. Ping auf das 0er Netzwerk kommt nix zurück, ping auf das 127er Netzwerk gibt:
Code: 
ping: sendto: Invalid argument
ping: wrote 192.168.127.47 64 chars, ret=-1
ping: sendto: Invalid argument
ping: wrote 192.168.127.47 64 chars, ret=-1
ping: sendto: Invalid argument
ping: wrote 192.168.127.47 64 chars, ret=-1
"Invalid Argument" - was immer das bedeutet. Aber immerhin schon etwas mehr!
Jetzt muss ich noch das "C" darein kriegen, das man route sagt:
Code: 
-cloning      RTF_CLONING      generates a new route on use
...

$ doas route add -net 192.168.127/24 -iface -cloning 192.168.127.1
et voilà: :)
Code: 
$ netstat -rn -f inet
192.168.127/24     192.168.127.1      UCS        0        0     -     8 pcn1
...
$ ping 192.168.127.47
PING 192.168.127.47 (192.168.127.47): 56 data bytes
64 bytes from 192.168.127.47: icmp_seq=0 ttl=255 time=5.174 ms
64 bytes from 192.168.127.47: icmp_seq=1 ttl=255 time=0.566 ms
64 bytes from 192.168.127.47: icmp_seq=2 ttl=255 time=0.825 ms
Wow, verstanden habe ich nicht, warum das so "funktioniert" (anderer Ausdruck für umständlich?).
Vielleicht kann mir jemand einen Hinweis geben, warum das so ist?
Ich dachte, ne statische Route drauf und "go"...

merci!
Volker
 
pebwindkraft schrieb:
Dachte immer, das müsste auch ohne "routing" gehen, dass sich 2 Rechner direkt unterhalten...
Zum Vergrößern anklicken....
Ohne Routing geht prinzipiell gar nichts. Bevor eine Kommunikation gestartet wird, wird in der Routingtabelle nachgesehen, wie die Verbindung (über welches Interface) aufgebaut werden kann.

Ich verstehe auch nicht, warum du es dir so umständlich machst. Die Routingeinträge, die beim Setzen der IP-Adresse+Netzmaske auf einem Interface automatisch angelegt werden, sind doch genau das, was du dort von Hand einrichtest.

Rob
 
<quote>Ohne Routing geht prinzipiell gar nichts</quote>:
OK, wenn er nicht weiss, welches Interface er hat... verstehe.
<quote>umständlich</quote>
na wegen dem Lerneffekt :). Ich wollte also sehen, was passiert, wenn kein Routing da ist, und dann per Hand wieder die Routen setzen.
Man ist es so gewohnt, dass "alles" so funktioniert, aber die Hintergründe sind oft unklar.
Jetzt suche ich also mal tiefer nach dem Routing Stack, denn das mit den Flags ist mir unklar. Im Internet (Google und Co.) gibt es haufenweise Hinweise, die Routen einfach ohne die Flags zu setzen. Wundere mich gerade, ob und wieso das funktioniert hat. Vielleicht sind das ältere Versionen, wo es "einfach so" funktioniert hat. Jetzt jedenfalls nicht mehr...
 
Ich hab noch nie diese Flags genutzt, versuche es mal mit -ifp <devicename>:

route add 192.168.127/24 -ifp pcn1

Rob
 
Ich glaube kaum, dass sich die haufenweisen Hinweise damit befassen, wie man manuell die Routen wieder setzt, die jedes System automatisch beim ifconfig einrichtet und die man gerade aus fragwürdigen Gründen zerstört hat.

Hast du ein Beispiel, wo genau dein Fall behandelt wird, aber keine Flags gesetzt werden?
 
KobRheTilla schrieb:
Ich hab noch nie diese Flags genutzt, versuche es mal mit -ifp <devicename>:

route add 192.168.127/24 -ifp pcn1

Rob
Zum Vergrößern anklicken....

ja, das hatte ich auch schon mal versucht...
Code: 
$ route add 192.168.127/24 192.168.127.1 -ifp pcn1
route: must be root to alter routing table
ooops ... :D, nochmal:
Code: 
$ doas route add 192.168.127/24 192.168.127.1 -ifp pcn1  
...
$system_server:~ $ netstat -rn -f inet
Destination        Gateway            Flags   Refs      Use   Mtu  Prio Iface
192.168.0.1        08:00:aa:00:aa:01  UHLl       0        0     -     1 pcn0
192.168.0.255      192.168.0.1        UHb        0        0     -     1 pcn0
192.168.127/24     192.168.127.1      UGS        0        0     -     8 pcn1
192.168.127.1      08:00:bb:12:7b:01  UHLl       1        1     -     1 pcn1
192.168.127.255    192.168.127.1      UHb        0        0     -     1 pcn1

$system_server:~ $ ping 192.168.127.47
PING 192.168.127.47 (192.168.127.47): 56 data bytes
--- 192.168.127.47 ping statistics ---
5 packets transmitted, 0 packets received, 100.0% packet loss
 
TCM schrieb:
Ich glaube kaum, dass sich die haufenweisen Hinweise damit befassen, wie man manuell die Routen wieder setzt, die jedes System automatisch beim ifconfig einrichtet und die man gerade aus fragwürdigen Gründen zerstört hat.

Hast du ein Beispiel, wo genau dein Fall behandelt wird, aber keine Flags gesetzt werden?
Zum Vergrößern anklicken....

<quote>fragwürdige Gründe</quote>
Lernen, wie das Routing funktioniert. Ist ja im Testaufbau/virtuelle Maschinen - nix kaputt :):D
Ja, da haben sich einige Leute schon Gedanken gemacht, wie es richtig aufzusetzen ist.

Nein, mein Fall wird nicht "genau" behndelt. Ich hatte mich durch das Buch gehangelt:
Seite 204-207:
https://books.google.ch/books?id=PN...MAU#v=onepage&q=openbsd static routes&f=false
 
Ich sehe da nichts, was cloning routes hinzufügt. Richtig aufzusetzen sind speziell diese Routen, indem man ein Netz auf ein Interface konfiguriert und dann die Finger von der Routingtabelle lässt. :)

Statische Routen über ein Gateway zu irgendwelchen Netzen sind eine _völlig_ andere Geschichte als das, was du da machst. Wollte es nur gesagt haben.
 
Hi,

schoen dass du Dich fuer die Routing-Interna interessierst.
Hier ein paar Grundlagen, damit Dir der Einstieg etwas leichter faellt:

Bei OpenBSD wird der Routing-Code sowohl zum 'klassischen' Routen, als auch fuer
die Aufloesung von Layer-2-Adressen (ARP/NDP) verwendet.

Routen, so wie Du dir sie vorstellst, haben ein G-Flag (Gateway-Routen). Das
sind Routen, fuer die es einen 'klassischen' Nexthop (Gateway) gibt, z.B. die
Default-Route mit dem Default-Gateway. Diese Routen werden ueblicherweise via
'route add' manuell angelegt/geloescht.

Daneben gibt es Cloning-Routen (C). Das sind Routen zu Netzen, die das System
direkt, also ohne Gateway, erreichen kann. Wenn man versucht eine Verbindung zu
einer Adresse, die ueber eine Cloning-Route erreichbar ist, aufzubauen, dann
erzeugt der Kernel aus der Cloning-Route (C) eine Cloned-Route (c). Die
Cloned-Route wird fuer die Layer-2-Aufloesung verwendet. In der netstat-Ausgabe
sieht man hier, sofern die ARP- bzw. NDP-Aufloesung erfolgreich war, als Gateway
die MAC-Adresse des benachbarten Systems. Cloning-Routen werden automatisch
angelegt, wenn man mit ifconfig eine Adresse konfiguriert.

Grundsaetzlich sollte man die Routen, die der Kernel automatisch beim Anlegen
von Adressen erzeugt, z.B. Cloning-Routen, als Kernel-Interna betrachten. Man
kann nicht davon ausgehen, dass man diese Routen mit route anlegen und loeschen
kann und dabei ein definiertes Verhalten hat. Da passieren im Hintergrund noch
Dinge, die man mit netstat so nicht sieht. Wenn man eine falsche Route loescht,
kann es sein, dass man das nur durch ein Reboot wieder beheben kann.

Cloning- bzw. Cloned-Routen sind immer notwendig sind, auch wenn 2 Systeme im
selben Netz liegen und man eigentlich gar kein Routing braucht. Dieses Konzept
stammt noch aus den Urzeiten von BSD und hat sich bewaehrt.

Noch ein paar weitere 'interne' Routen:
b : Routen zu den Broadcast-Adressen der einzelnen Netze
l : Local-Routen. Hiermit merkt sich der Kernel welche Adressen dem eigenen
System gehoeren.

Falls Dich das Thema interressiert, kann ich dir TCP/IP Illustrated Volume 2,
auch bekannt als 'der Stevens', empfehlen. Das Buch ist zwar schon etwas in die
Jahre gekommen, aber die meisten Konzepte treffen immer noch zu.

Hoffe ich konnte Dir helfen.

Gruss

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