Re: ein kleines routing Problem
Hallo,
ich springe noch einmal rein, weil ich glaube das Problem gesehen zu haben.
Kannst du den Client anpingen? Sprich sowohl 10.101.101.22 als auch (!)
10.101.2.253?
##### ip ro li
default via 10.101.1.254 dev eth0
10.100.0.0/16 via 10.100.100.253 dev vpn2boe
10.101.1.0/24 dev eth0 proto kernel scope link src 10.101.1.1
10.101.101.0/24 via 10.101.101.2 dev tun0
10.101.101.2 dev tun0 proto kernel scope link src 10.101.101.1
10.101.102.0/24 dev vmbr0 proto kernel scope link src 10.101.102.1
10.101.200.0/24 dev eth2 proto kernel scope link src 10.101.200.1
239.0.0.0/8 dev eth0 scope link
Hier fehlt die Route für 10.101.2.0/24 oder eine Route, die dieses
Netz einschließt. Dein Server weiß nicht, dass Pakete für die
Wetterstation in den Tunnel müssen.
#######################################################################
Ich dachte dem Server zu sagen das an dem VPN Client 10.101.101.22 ein
Netz 10.101.2.0/24 hängt und der VPN Client ist dafür der Router, langt.
#######################################################################
Du sagst dem Server aber nicht, dass der VPN-Client für 10.101.2.0/24
der Router ist.
Eine grundsätzliche Regel zum Routing:
Eine Route sollte immer nur zum nächsten GW zeigen. Es macht also wenig
Sinn, dem Server zu sagen, dass 10.101.2.0/24 über 10.101.101.22 zu
erreichen ist. Siehe unten.
Forward ist an, IPTABLES zeigt das auch
cat /proc/sys/net/ipv4/ip_forward
1
das ist das wichtige.
iptables -L -n
Chain FORWARD (policy ACCEPT)
Das ist irrelevant, eine FORWARD-Chain existiert auch wenn Forwarding
aus ist. Die Chain kommt nur nie zum Zuge.
Und wer kann hier wen jetzt nicht pingen?
Ich kann die Route auf dem Server nicht setzen ...
ip ro add 10.101.2.0/24 via 10.101.101.22
RTNETLINK answers: Network is unreachable
ip ro add 10.101.2.0/24 dev tun0?
ip ro add 10.101.2.0/24 via 10.101.101.22 dev tun0?
Wenn das nicht hilft, geht es nicht ohne OpenVPN, "route 10.101.2.0
255.25.255.0" in der Konfiguration des Servers. An manchen Stellen
sitzt OpenVPN quer zum normalen Routing. Ja, das ist unlogisch und
häßlich.
Nein, es ist logisch. Ob hässlich, kann man drüber streiten, das gebe
ich zu.
So jetzt zur Erklärung:
Du verwendet OpenVPN mit tun Geräten. Lies dir man die Doku dazu durch.
Daran liegt nämlich vermutlich dein Problem. Es funktioniert so:
Der Server legt ein Subnetz /30 für sich selbst und für jeden einzelnen
Client an. Das erste ist das Subnetz 10.101.101.0/30, das nächste
10.101.101.4/30 etc. In jedem Subnetz gibt es 4 IPs. Die mit dem selben
Offste haben immer die selbe Funktion:
- Offset 0 (...0, ...4, ...20) beschrieben das Subnetz.
- Offset 1 (...1, ...5, ...21) beschrieben die IP des jeweiligen Geräts.
- Offset 2 (...2, ...6, ...22) beschrieben die IP des Tunnels. Die Route
auf dem Gerät muss über diesen P2P Tunnel laufen
- Offset 3 (...3, ...7, ...23) ist der Broadcast in dem Subnetz.
Intern bildet OpenVPN einen Router virtuell ab, der für den Server und
jeden Client einen Port hat. Das sind die P2P Tunnel-IPs (Offset 2).
Um also den Client zu erreichen passiert folgendes: Der Server schickt
ein Paket von 10.101.101.1 an *.2 (Ich lasse die 10.101.101 ab jetzt
weg). Dort wird es von OVPN entgegen genommen und geschaut, wo eine
iroute in der Konfiguration steht. Diese wird für direkte Client
automatisch anglegt. Damit weiß OVPN, dass das Paket an .22 über den
Tunnel .23 raus gehen muss und schickt das Paket auf den Weg.
Wenn du jetzt ein externes Netz erreichbar machen möchtest, musst das
zum einen OVPN wissen (sonst funktioniert der virtuelle Router nämlich
nicht) und die Kernel-Routen müssen passen.
Konkret brauchst du auf dem Server (falls nicht schon vorhanden)
- *.22/32 via *.2 oder alternativ *.0/24 via *.2 (aber dann
funktionieren nur die IPs mit Offset 1! Die anderen kann man nicht pingen)
- 10.101.2.0/24 via *.2 (!)
Dann muss wie gesagt noch iroute in OVPN eingetragen werden.
Wenn du mit route in OVPN arbeitest, wird die Kernel-Routing-Tabelle von
OVPN automatisch angepasst.
Wie schon gesagt: Den Rückweg der Pakete nicht vergessen! Am einfachsten
(wie schon empfohlen) das Gefault GW der Wetterstation auf den Client
also 10.101.2.253 setzten. Oder im aktuellen Standard GW des
10.101.2.0/24 Netz eine entsprechende Route setzen.
Ich hoffe, das sollte damit dann funktionieren und ich konnte damit helfen.
Gib Bescheid, ob es damit geklappt hat.
Grüße Chris
Reply to: