[Problem] Routing-Problem

[dougi]

Hallo Zusammen,

ich habe ein kleinen Routingproblem zwischen meinen beiden lokalen Netzen 10.0.0.0/24 und 10.0.1.0/24 die über tun (10.0.0.1 mit tun-IP 10.0.10.2 und 10.0.1.1 mit tun-IP 10.0.10.1) per OpenVPN verbunden sind. Das Problem welches sich in meinen Augen in der Routingtabelle im Gateway 10.0.0.1 verbirgt stellt sich folgendermasen dar.
Zunächst ein Ausschnitt aus der Routingtabelle 10.0.0.1:

10.0.0.0        localhost       255.255.255.0   UG    0      0        0 tun0
10.0.0.0        *               255.255.255.0   U     0      0        0 lan
10.0.1.0        localhost       255.255.255.0   UG    0      0        0 tun0
10.0.10.0       localhost       255.255.255.0   UG    0      0        0 tun0
10.0.10.0       *               255.255.255.0   U     0      0        0 tun0

Hier ist in meinen Augen das Problem, dass Anfragen aus 10.0.0.0 nach 10.0.1.0 scheitern, weil der GW für 10.0.1.0 localhost lautet anstatt 10.0.10.1.

Also habe ich versucht mit folgenden Route-Befehlen die Tabelle anzupassen:

route del -net 10.0.1.0 netmask 255.255.255.0 dev tun0 
route add -net 10.0.1.0 netmask 255.255.255.0 dev tun0 gw 10.0.10.1

Das führt allerdings dazu, dass als GW für 10.0.1.0 wieder localhost erscheint und das verstehe ich nicht. :crazy:

Hat einer eine Idee oder einen Hinweis wo ich einen Fehler gemacht habe?

Viele Grüße,

Dougi

 

[MaxMuster]

Erstmal zeigen die Routingtabellen ein Problem in ersten beiden Zeilen:

Das Netz 10.0.0.0/24 wird nicht nur lokal (lan) sondern auch auf den Tunnel (tun0) geroutet. Das ist eigentlich nicht korrekt, woher kommt das?

Woher kommen denn ansonsten die Routen? Aus der OpenVPN-Config?

Im Prinzip sollte eine Route mit Gateway reichen, das Device ist meist überflüssig, alos so in dieser Art:

route add -net 10.0.1.0 netmask 255.255.255.0 gw 10.0.10.1

Jörg

 

[dougi]

Hallo Jörg,

vermutlich stammt der doppelte Eintrag aus den Push-Infos. Folgender Push wird gesendet:

PUSH: Received control message: 'PUSH_REPLY,dhcp-option WINS 10.0.1.1,route 10.0.10.0 255.255.255.0,route-gateway 10.0.10.1,topology subnet,route 10.0.1.0 255.255.255.0 10.0.10.1,ping 40,ping-restart 120

Darauf folgend im Syslog:

Jun 10 15:37:49 fritz daemon.notice openvpn[725]: /sbin/ifconfig tun0 10.0.10.2 netmask 255.255.255.0 mtu 1500 broadcast 10.0.10.255
Jun 10 15:37:49 fritz daemon.notice openvpn[725]: /sbin/route add -net 10.0.0.0 netmask 255.255.255.0 gw 10.0.10.1
Jun 10 15:37:49 fritz daemon.notice openvpn[725]: /sbin/route add -net 10.0.10.0 netmask 255.255.255.0 gw 10.0.10.1
Jun 10 15:37:49 fritz daemon.notice openvpn[725]: /sbin/route add -net 10.0.1.0 netmask 255.255.255.0 gw 10.0.10.1

Folgende Config ist für den Client auf Serverseite eingetragen:
Clientname (Zertifikat) Client-VPN-IP Netz bei Client (Syntax: <ip> <subnetmask>)
abc123 10.0.10.2 10.0.0.0 255.255.255.0

Allerdings sollte das ja nur den Eintrag für das Routing Serverseitig erstellen, was auch passiert.

Bin nach wie vor total verwirrt ...

 

[dougi]

Update

Ok doppelter Eintrag war falsche Config auf Clientseite.

Aktuelle Routingtabelle:

10.0.0.0        *               255.255.255.0   U     0      0        0 lan
10.0.1.0        localhost       255.255.255.0   UG    0      0        0 tun0
10.0.10.0       localhost       255.255.255.0   UG    0      0        0 tun0
10.0.10.0       *               255.255.255.0   U     0      0        0 tun0

Allerdings besteht das Problem mit localhost anstelle von 10.0.10.1 als GW für 10.0.1.0 nach wie vor.

Und warum ich drei Routingeinträge mit dev tun0 habe verstehe ich auch nicht. Im Vergleich dazu nur zwei Einträge auf Serverseite:

10.0.0.0        10.0.10.2       255.255.255.0   UG    0      0        0 tun0
10.0.1.0        *               255.255.255.0   U     0      0        0 lan
10.0.10.0       *               255.255.255.0   U     0      0        0 tun0

 

[dougi]

Es schaut so aus, dass der Client immer als gw localhost einträgt wenn ich ihm als gw den Tunnelendpunkt auf Serverseite übergebe. Ist das evtl ein OpenVPN Fehler?
Ich suche mal weiter ...

 

[MaxMuster]

Vielleicht ist das nur die Namensauflösung, denn du hast doch den Server als DNS drin oder?

Ich vermute, dass ein “route -n“ vielleicht schon das Erwartete zeigt?

Jörg

 

[dougi]

Hut ab Jörg

Der Parameter -n war mir neu.

So sehen die Routingtabellen besser aus :

Server:

10.0.0.0        10.0.10.2       255.255.255.0   UG    0      0        0 tun0
10.0.1.0        0.0.0.0         255.255.255.0   U     0      0        0 lan
10.0.10.0       0.0.0.0         255.255.255.0   U     0      0        0 tun0

Client:

10.0.1.0        10.0.10.1       255.255.255.0   UG    0      0        0 tun0
10.0.10.0       10.0.10.1       255.255.255.0   UG    0      0        0 tun0
10.0.10.0       0.0.0.0         255.255.255.0   U     0      0        0 tun0
10.0.0.0        0.0.0.0         255.255.255.0   U     0      0        0 lan

Somit sehen die Routingtabellen sauber aus.
Was jetzt bei mir allerdings trotzdem noch nicht klappt ist der Zugriff auf Netzwerkfreigaben bei Clients im jeweils anderen Subnetz.
Die Browsingtabellen werden zwar von beiden Servern mittels Samba WINS ausgetauscht, so dass auf den Clients die jeweils anderen Rechner zu sehen sind und zwar mit diesen Parametern:

Server 10.0.1.1:

domain master = Yes
prefered master = yes
local master = Yes

wins support = yes
wins proxy = yes
name resolve order = bcast wins lmhosts hosts
remote announce = 10.0.0.255/simpsons.int 10.0.0.1/simpsons.int 10.0.1.255/simpsons.int 10.0.1.1/simpsons.int 10.0.10.255/simpsons.int 10.0.10.2/simpsons.int
remote browse sync = 10.0.0.1 10.0.10.2

Client 10.0.0.1:

domain master = no
prefered master = yes
local master = Yes

wins support = no
wins proxy = yes
wins server = 10.0.1.1
name resolve order = wins lmhosts hosts bcast 

remote announce = 10.0.0.255/simpsons.int 10.0.0.1/simpsons.int 10.0.1.255/simpsons.int 10.0.1.1/simpsons.int 10.0.10.255/simpsons.int 10.0.10.1/simpsons.int
remote browse sync = 10.0.1.1 10.0.10.1

Aber Zugriff erhalte ich damit nur auf die Sambafreigaben von 10.0.1.1 und 10.0.0.1 aus beiden Netzen.

Any Idea?

Grüße,

Dougi

 

[MaxMuster]

Samba, WINS und Co sind nicht so meine Gebiete, aber im Zweifel tippe ich auf
- irgendwelche Firewall-Einstellungen (sofern du die noch nicht angepasst hast), die einen Zugriff aus "Fremdnetzen" nicht zulassen
- Die WINS-Auflösung klappt nicht ganz (versuchst du \\DerPCName\Freigabe oder \\10.0.1.25\Freigabe ? )


Jörg

 

[dougi]

Die Firewall-Einstellungen hatte ich auch schon in Verdacht. Wins-Auflösung mit \\DerPCName\Freigabe oder \\10.0.1.25\Freigabe geht beides nicht bei Clientrechnern. Bei den Serverfreigaben allerdings schon und das wie gesagt aus beiden Netzen auf beide Server. Namensauflösung funktioniert in meinen Augen auch, da ein Ping auf den Namen auch die korrekte IP liefert.

Die Spur die ich aktuell verfolge ist, ob ich evtl ein DNS-Serverproblem habe. DNSmasq läuft in beiden Netzen. Normalerweise ist pro Domaine nur ein DNS Server erlaubt. Wenn ich allerdings den DNS-Server des 10.0.1.0-Netzes bei den Clients im 10.0.0.0-Netz eintragen lasse, dann klappt dort keine Namensauflösung nach Extern mehr.

Folgende DNSmasq-Einstellungen verwende ich bei den Netzen:

10.0.1.1:

localise-queries
no-negcache
expand-hosts

domain=/simpsons.int/
local=/simpsons.int/

dhcp-option=3,10.0.1.1
dhcp-option=44,10.0.1.1

Die Rechnernamen in der hosts Datei ohne Domaine.

10.0.0.1:

localise-queries
no-negcache
#expand-hosts

domain=/simpsons.int/
local=/gi.simpsons.int/

dhcp-option=3,10.0.0.1
dhcp-option=44,10.0.1.1

Hier ohne expand-hosts, dafür aber mit voll-qualifizierten Hostnamen in der hosts a la rechner1.simpsons.int

Leider bin ich mit der Summe der verschiedenden Dienste auch etwas überfordert und kann mit meinem Wissen den Fehler leider nicht erkennen

 

[RalfFriedl]

Wenn ein Zugriff über die IP-Adresse nicht funktioniert, dann liegt es nicht an der Namensauflösung, weder an DNS noch an WINS.
Hast Du schon irgendwo geschrieben, was genau "geht nicht" bedeutet?
Funktioniert ein Ping auf den Zielrechner? Ein Telnet auf Port 139 oder Port 445?

 

[dougi]

Hallo Ralf,

ja die ursprüngliche Disskusion hat sich erweitert auf

Was jetzt bei mir allerdings trotzdem noch nicht klappt ist der Zugriff auf Netzwerkfreigaben bei Clients im jeweils anderen Subnetz.
Die Browsingtabellen werden zwar von beiden Servern mittels Samba WINS ausgetauscht, so dass auf den Clients die jeweils anderen Rechner zu sehen sind ...

Ein Ping Client (10.0.1.0) zu Client (10.0.0.0) geht genausowenig wie ein Telnet-Zugriff auf die Ports 139 und 445. Hier kommt es zur Fehlermeldung "Network unreachable".
Hieraus hatte ich ja ursprünglich gefolgert, dass es etwas mit den Routingtabellen zu tun hat. Die scheinen aber jetzt in meinen und Jörgs Augen korrekt zu sein.

Sehr merkwürdig

Gruß Dougi

 

[RalfFriedl]

Wenn das Ping schon nicht geht, wird auch sonst nichts funktionieren.
Eine gute Möglichkeit, dem nachzugehen, ist tcpdump auf den Servern laufen zu lassen und zu sehen, wie weit die Pakete kommen.

 

[dougi]

Zum Glück gibts davon schon statisch gelinkte Versionen im Forum

Also tcpdump auf 10.0.0.1 wirft bei ping 10.0.0.11 vom Client (10.0.1.11) folgende Meldung:

18:37:39.835897 arp who-has clientname10.0.0.11 tell servername10.0.0.1
18:37:40.835833 arp who-has clientname10.0.0.11 tell servername10.0.0.1
18:37:41.835818 arp who-has clientname10.0.0.11 tell servername10.0.0.1
18:38:18.105861 arp who-has clientname10.0.0.11 tell servername10.0.0.1

Klingt auf den ersten Eindruck für mich wie ein Namensauflösungsproblem. Mal sehen was Tante google dazu sagt ...

 

[MaxMuster]

Da sieht eher so aus, als wäre das Ziel (10.0.0.11) nicht da oder an? Auf die ARP-Anfrage scheint irgendwie keine Antwort zu kommen. Ist das Gerät von der Box vor Ort denn erreichbar?

 

[RalfFriedl]

Verwende beim tcpdump die Option -n, dann gibt es kein Namensauflösungsproblem.

Wenn hinter den Namen die Adressen stehen, die Du angegeben hast, reagiert 10.0.0.11 nicht auf ARP-Anfragen. Dann wäre er aber auch lokal nicht anpingbar.