Hilfe bei Routing-Konfig

[Tr4c3rt]

Hallo,

ich hab eine Frage bezüglich eines Opnenvpn Netzwerks, habe dazu mal eine Zeichnung gemacht:



Die Voraussetzungen:

Auf dem Rootserver läuft ein TLS gesicherter openvpn Server.
Die Einwahl findet auf der einen Seite über einen Debian Homeserver statt, auf der anderen Seite über einen TP Link 1043 Router mit DD WRT.

Angenommen der Server hat 10.8.0.1, der Homeserver 10.8.0.6 und der TP Link 10.8.0.10 (per ccd so definiert)

Das Ziel:

Client 1 soll eine Verbindung zum Homeserver herstellen und zwar auf Port 12345 TCP.

Das Problem:

Von den an den TP Link angeschlossenen Clients kann ich zwar den Rootserver (10.8.0.1) anpingen, bekomme aber keine Antwort von 10.8.0.10 oder 10.8.0.6.
Vom TP Link selbst kann ich 10.8.0.6 und 10.8.0.10 (eigenes tun device) problemlos anpingen.

Aus irgendeinem Grund bekommen die Endgeräte am TP Link Router aber keine Route zu 10.8.0.6.


Hier die server.conf

port 1194
proto udp
dev tun

ca      /etc/openvpn/easy-rsa/keys/ca.crt    # generated keys
cert    /etc/openvpn/easy-rsa/keys/server.crt
key     /etc/openvpn/easy-rsa/keys/server.key  # keep secret
dh      /etc/openvpn/easy-rsa/keys/dh1024.pem

server 10.8.0.0 255.255.255.0  # internal tun0 connection IP
keepalive 10 120

comp-lzo         # Compression - must be turned on at both end
persist-key
persist-tun

client-config-dir /etc/openvpn/ccd

status log/openvpn-status.log

verb 3  # verbose mode
client-to-client

Hier die CCD'S:

Client1

ifconfig-push 10.8.0.10 10.8.0.9
push "route 10.8.0.0 255.255.255.0"

Client2

ifconfig-push 10.8.0.6 10.8.0.5
push "route 10.8.0.0 255.255.255.0"

Mein Lösungsansatz:

Wenn ich von den Endgeräten nicht direkt an die 10.8.0.6 komme, warum dann nicht am rootserver per IPTables einen Forward einrichten:

$FW -A INPUT -p tcp --dport 12345 -j ACCEPT
$FW -t nat -A PREROUTING -p tcp --dport 12345 -j DNAT --to-destination 10.8.0.6:12345
$FW -t nat -A POSTROUTING -j MASQUERADE

Funktioniert auch bestens, aber sauber ist die Lösung nicht!

Warum bekommen die Endgeräte keine Route zu 10.8.0.6, obwohl die Route zu 10.8.0.1 bekannt ist und dem TP Link Router auch die Route zu 10.8.0.6 bekannt ist?

Fehlt in der server.conf oder in den ccd files irgendwas?

Dabei gebe ich zu bedenken, dass ich am TP Link selbst keine beliebige Client Config einrichten kann, jegliche Routen müssen vom Server per push Funktion gesendet werden.

Besten Dank im voraus ;-)

 

[olqs80]

Hast du auf deinem Homeserver mal mit tcpdump nachgesehen ob die Pakete ankommen?
Ich denke das die ankommen aber der Homeserver die nicht wieder in den Tunnel schickt, da er ersten das 192.168.1.0/24 Netz auch lokal connected hat und der openvpn Client sich auch nicht um Pakete für das Netz annimmt. Sieh dir dazu mal die Option iroute an.
Ich würde wenns möglich ist mal beide lokalen Netze unterschiedliche IP Netze geben und dann in die clientconfigs jeweils noch "iroute <lokales Netz> <Subnetzmaske>" hinzufügen.

 

[Tr4c3rt]

Hi,

danke für den Tip, hat allerdings leider nicht funktioniert.
Im Moment teste ich den DD WRT Router direkt am Homeserver anzumelden (ohne Umweg über den root)
Dafür habe ich auf dem Homeserver direkt einen Openvpn Server eingerichtet, dieses mal mit der IP 10.8.1.1.
Der Client (TP Link) bekommt per CCD die 10.8.1.10.
Der Tunnel steht beide Geräte sind verbunden, lassen sich gegenseitig anpingen.

Die Adressbereiche des Netzwerks am TP LInk Router habe ich auf 192.168.0.0 angepasst, damit zwei verschiedene Adressbereiche zur Verfügun stehen.

Nun wollte ich also die Subnetze einbinden, dafür erstmal IP Tables:

Am Homeserver:

# Weiterleitung VPN to eth0
$FW -I FORWARD -i eth0 -o tun0 -j ACCEPT
$FW -I FORWARD -i tun0 -o eth0 -j ACCEPT

# Allow established 
$FW -I FORWARD -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT

Am Router:

iptables -I FORWARD -i br0 -o tun0 -j ACCEPT
iptables -I FORWARD -i tun0 -o br0 -j ACCEPT

Jetzt muss ich natürlich noch die Routen schreiben:

Am Router:

add route -net 192.168.1.0 netmask 255.255.255.0 gw 10.8.1.1

Am Homeserver:

add route -net 192.168.0.0 netmask 255.255.255.0 gw 10.8.1.10

Das liefert mir aber am Homeserver Folgendes:

SIOCADDRT: Kein passender Prozess gefunden


So langsam gehe ich hier die Wände hoch, das ist doch wirklich eigentlich nix kompliziertes aus dem Subnetz eine Route freizugeben und per IPTables den Forward zu erlauben.
Trotzdem kann ich nicht gegenseitig pingen...

Wo ist der Fehler?

 

[olqs80]

Die Routen macht openvpn selbst, da brauchst du nichts machen. Ich Schau mir das morgen nochmal an.

Hatte früher mit ein paar Freunden ein ähnliches Setup wie bei die mit dem Root als zentralen Punkt.

 

[Tr4c3rt]

Vielen Dank das würde mir echt weiterhelfen, ich sitz da seit heute früh um 10 dran und kriegs einfach nicht hin :-(

Hab mittlerweile die FAQ's und Tutorials auf google bis Seite 5 durch ;-)

Was ich noch als eventuell auftretendes Problem sehe ist folgendes:

Der TP Link Router hat die IP 192.168.1.2, der vorgeschaltete Linksys Router(mit Modem) macht DHCP fürs ganze Netzwerk. (Geht wegen mobilen Endgeräten nicht ohne DHCP)
Der TP Link ist als DHCP Forwarder eingestellt.

Wenn ich jetzt auf dem Endgerät statisch die 192.168.1.2 als Gateway und DNS einstelle, kann ich zumindest den Server anpingen (also 10.8.0.1)
Allerdings habe ich dann auf dem Endgerät kein Internet mehr, vermutlich da keine vernünftige DNS Auflösung mehr gegeben ist. (Ob garnix mehr durchgeht oder nur DNS nicht hab ich nicht getestet, ist jetzt geraten)

So wie es aussieht muss ich dem Linksys Router die Route zum 192.168.1.xer Netzwerk mitteilen, der die dann wiederrum an die Endgeräte weiterleitet.

Bevor jetzt jemand auf die Idee kommt den Linksys als Modem only laufen zu lassen, geht leider nicht.
Der TP Link steht im Wohnzimmer und der Linksys hängt im Keller.
Dazwischen gibts nur ein Kabel und am Linksys selbst sind auch noch Endgeräte angeschlossen. (Die nicht unbedingt zugriff aufs VPN brauchen)

 

[TCM]

Bitte mal komplette ifconfig -a und netstat -r outputs vom Homeserver, Rootserver, TP-Link und einem Client.

 

[Tr4c3rt]

Hat sich erledigt, der Fehler lag genau da wo ich ihn gestern schon vermutet hatte.
Da im zweiten Subnetz der TP Link Router nur dhcp forwarder ist und als Gateway die 192.168.0.1 fungiert, musste ich die Routen ins andere Netz natürlich auch dort verankern (10.8.0.0 über 192.168.0.1 und 192.168.1.0 über 10.8.0.1)

Jetzt läuft es so wie ich es mir vorstelle.

 

[TCM]

Tjaja, der Spaß, wenn man einfach Consumer-Zeug zusammenstückelt statt ein Netzwerk richtig zu designen.