OpenVPN + iptables: Traffic über anderen Client routen

Frazer1

Lieutenant
Registriert
März 2013
Beiträge
637
Hallo allerseits,
ich habe was das ganze routen angeht noch nicht so viel Erfahrung und hoffe, dass ihr mir hier helfen könnt.

Folgende Geräte sind hier relevant:
VPN-Server: 10.8.0.1/24
Client-A: 10.8.0.10/24
Client-B: 10.8.0.11/24

Der VPN-Server ist ein öffentlicher VPS, Client-A ist ein kleiner Linux-Server bei mir zu Hause und Client-B ist mein Laptop (auch Linux).

Mein Ziel ist es, den Traffic vom Laptop über den Client-A zu routen, damit der "von Zuhause" kommt. Mit den Servereinstellungen "redirect-gateway" kommt der Traffic beim VPS raus, was soweit funktioniert, aber ich hätte ihn lieber am Client-A.

Bei Client-A habe ich folgendes gemacht:
Code:
iptables -I FORWARD -i tun0 -o eth0 \
         -s 10.8.0.0/24 -m conntrack --ctstate NEW -j ACCEPT

iptables -I FORWARD -m conntrack --ctstate RELATED,ESTABLISHED \
         -j ACCEPT

iptables -t nat -I POSTROUTING -o eth0 \
          -s 10.8.0.0/24 -j MASQUERADE
Soweit ich das verstanden habe, werden also alle neuen Verbindungen, die in tun0 rein, und aus eth0 rausgehen, sowie alle bereits bestehende Verbindungen akzeptiert. Dann werden alle Pakete aus dem Netz 10.8.0.0/24, die über eth0 rausgeschickt werden als "NAT" verpackt.
Hier auch gleich ein Frage dazu: Heißt dass, das auch die Antworten auf diese Pakete automatisch wieder an 10.8.0.0/24 weitergeleitet werden, oder braucht es da eine eigene Regel für den Rückweg?

Bei Client-A ist zudem folgende route vorhanden:
Code:
10.8.0.0/24 dev tun0 proto kernel scope link src 10.8.0.10



Bei Client-B habe ich folgendes gemacht:
Ohne weiteres kann ich Client-A anpingen und auch sonst ohne Probleme erreichen, da OpenVPN automatisch folgende route hinzugefügt hat:
Code:
10.8.0.0/24 dev tun0 proto kernel scope link src 10.8.0.11

Soweit mein Verständnis reicht, muss ich nun also nur noch das default gw auf 10.8.0.10 ändern und es sollte funktionieren, oder habe ich etwas übersehen?
Code:
ip route add default via 10.8.0.10 dev tun0
Wenn ich allerdings eine neue default route hinzufüge, geht gar nichts mehr. Ich kann gar nichts mehr machen. Ich kann das lokale Netz, in dem der Laptop ist noch erreichen, aber ich kann weder den VPN-Server, noch Client-A anpingen, geschweige denn das Internet erreichen. Muss ich hier noch irgendwelche FORWARD Policies beim VPN-Server hinzufügen? Ich kann aber ja den anderen Client sonst direkt erreichen, die sollten also ja eigentlich alle schon existent sein, oder?

Ich hoffe mir kann einer von euch auf die Sprünge helfen.
Viele Grüße
Frazer
 
Auf Client-A einen zweiten OpenVPN Server um den Laptop damit zu verbinden wäre die einfachste Lösung.

Frazer1 schrieb:
Code:
ip route add default via 10.8.0.10 dev tun0
Damit killst Du auch die Verbindung zum VPN-Server
 
Zuletzt bearbeitet:
Ok, das erklärt dann schon mal einiges. An einen zweiten VPN-Server hatte ich auch schon gedacht, nur keine Lust und ich dachte, dass das auch ein wenig unnötig ist, wenn es auch anders funktionieren müsste.

Weißt du, wie ich dass dann hinbekomme? Kann ich eine eigene route zum VPN Server einstellen, die dafür sorgt, dass der Traffic für diesen noch an das richtige Ziel geht? Also in etwa so?
Code:
ip route add 10.8.0.1/32 via 10.8.0.1 dev tun0
Ich kanns allerdings erst heute Abend ausprobieren. Trotzdem schon mal danke!
 
Auf Client-A ist in jedem Fall NAT nötig, damit der Traffic auch nach "von Zuhause" aussieht.
 
Frazer1 schrieb:
Der VPN-Server ist ein öffentlicher VPS, Client-A ist ein kleiner Linux-Server bei mir zu Hause und Client-B ist mein Laptop (auch Linux).

Mein Ziel ist es, den Traffic vom Laptop über den Client-A zu routen, damit der "von Zuhause" kommt. Mit den Servereinstellungen "redirect-gateway" kommt der Traffic beim VPS raus, was soweit funktioniert, aber ich hätte ihn lieber am Client-A.
Frage 1: "öffentlicher VPS" heißt aber schon, dass das deiner ist? Also inkl. root-Zugriff und kein Server eines VPN-Anbieters xy? Es ist nämlich notwendig, dem VPN-Server überhaupt mitzuteilen, dass er client-to-client Traffic durchlassen soll. Das wäre also schon mal die erste wichtige Einstellung (glaub die heißt auch "client-to-client" bei openvpn)

Frage 2: Warum soll der Internettraffic denn nicht beim VPS ins www, sondern nochmal einen Umweg über das VPN zu einem anderen VPN-Client, um dann von dort wieder ins www zu gehen? Der Sinn erschließt sich mir gerade nicht wirklich..


Wie dem auch sei: Bei OpenVPN muss man prinzipiell keine manuellen Routen anlegen. Das kann OpenVPN auch selbst, wenn die server.ovpn bzw. die client.ovpn und ggfs eben die ccd-Dateien korrekt sind. Dabei kann man zB in der client.ovpn "iroute" verwenden, während der Server dazu passend trotzdem ein "route" Kommando enthalten muss. Intern übernimmt der OpenVPN-Server dann bei seiner route in das definierte Subnetz dann als Gateway den Client mit dem iroute-Kommando. Normalerweise dient diese Option aber dazu, das private Netzwerk hinter einem der Clients für andere Clients verfügbar zu machen, nicht aber als neues Standard-Gateway.

Zur Not macht man sonst ein up-Skript, das bei hergestellter VPN-Verbindung ausgeführt wird und dann eben explizit eine manuelle Standard-Route über den anderen VPN-Client einrichtet. Aber: Man darf nicht glauben, dass das dann direkt von Client A zu Client B ginge, weil das ALLES über die VPN-Verbindungen zum Server geht, also A <VPN> Server <VPN> B --> www. Eine direkte Verbindung A<>B gibt es ausschließlich über die jeweils öffentlichen IP-Adressen, aber alles was im VPN ist, geht zwangsläufig über den Server.
Daher auch die Alternative von @till69 mit der direkten VPN-Verbindung A <VPN> B über einen separaten VPN-Server in B.
 
Zur 1: Ja, ist "mein" Server mit Root Zugriff, auf welchem ich OpenVPN installiert habe. Client-to-client ist schon aktiviert und ich kann den anderen Clienten ja auch erreichen, das sollte also kein Problem sein.

Zur 2: Zuerst war mein Gedanke, dass es schöner ist, wenn der private Traffic übers Heimnetzwerk geht. Das das Schmarn ist, ist mir bewusst und eigentlich ist es mehr eine Ausrede um sich mit dem ganzen Routing Thema mal mehr zu befassen :)
Ich hab kein Problem damit, dass der Traffic über den VPS läuft, und sofern ich das hier nicht gebacken bekomme wirds auch darauf hinauslaufen.

Das man routen pushen kann weiß ich, ich wollte das nur erst mal von Hand ausprobieren, damit ich weiß, was ich dann fest einstellen muss. "iroute" guck ich mir mal genauer an!
Mein Problem ist allerdings aktuell, dass ich es auch manuell nicht so hinbekomme, dass es geht. Wenn ich dich aber richtig verstanden habe, kann ich mir den ganzen iptables-kram sparen und das über iroute machen. Muss anschließend aber noch manuell das gw auf dem Laptop ändern?

@till69 Danke nochmal für den Hinweis, dass ich dann die Verbindung zum VPN kappe. Als ich dann noch von Hand eine Route angelegt habe, die den VPN über das alte gw routet ist die Verbindung nicht eingebrochen, mein Traffic kam allerdings dann beim VPN-Server raus und nicht beim Client-A. Aber ich guck mal, ob sich das dann über die iroute lösen lässt.
till69 schrieb:
Sollte da nicht tun0 anstatt eth0 rein?
Wie gesagt bin ich noch vergleichsweise neu was das alles angeht. Aber das ist doch der Traffic, der aus dem 10.8.0.0/24 Netz kommt und über eth0 den Rechner verlässt. Also der ausgehende Traffic des VPN. Das ist ja der Traffic, bei dem der Sender ersetzt werden soll. Oder muss ich das auch zusätzlich für die andere Richtung machen?
 
Frazer1 schrieb:
Zuerst war mein Gedanke, dass es schöner ist, wenn der private Traffic übers Heimnetzwerk geht. Das das Schmarn ist, ist mir bewusst und eigentlich ist es mehr eine Ausrede um sich mit dem ganzen Routing Thema mal mehr zu befassen :)
Wenn es kein Problem ist, wenn der Internettraffic am VPS ins www geht, dann mach das so. Es ist nicht sinnvoll, das aus ,, ,, ,, Gründen ,, ,, von A über VPN zum Server und dann wieder zu B zu gehen. Gäbe es in irgendeiner Form einen Grund dafür, zB weil man sich bei A mit einem SIP-Client ins VoIP eines Telekom-Anschlusses einloggen will, wäre das ein realer Anwendungsfall, weil die SIP-Server vom rosa Riesen nicht öffentlich erreichbar sind.

Das Standardgateway über OpemVPN in dieser Form zu pushen, ist nicht vorgesehen, weil redurect-gateway sonst eine Option dazu hätte. Es birgt auch ein gewisses Risiko, weil du dich im Zweifelsfalle komplett aus dem VPS aussperrst - insbesondere wenn du das direkt in iptables einträgst (s.u.)



Frazer1 schrieb:
Das man routen pushen kann weiß ich, ich wollte das nur erst mal von Hand ausprobieren, damit ich weiß, was ich dann fest einstellen muss. "iroute" guck ich mir mal genauer an!
Die gepushten Routen von OpenVPN sind temporär und werden bei erfolgreicher VPN-Verbindung erstellt und bei der Trennung wieder entfernt. Wenn man das statisch in iptables einbaut, gelten die Regeln auch, wenn das VPN down ist und das kann problematisch sein. Ist zB nur A online, würde er trotzdem hart kodiert über den Server und darüber durch B ins Internet gehen wollen - B ist aber offline und A hat dann gar kein Internet via VPN mehr.


Routing ist im Prinzip ein Rasiermesser. Es werden gezielt bestimmte IP-Adressen und Subnetze über einzelne Gateways geleitet. Die Standardroute ist gewissermaßen der Dampfhammer, der ddn Rest auf einen Schlag erledigt. Wenn man nicht aufpasst, erschlägt man damit aber mehr als man will wie @till69 schon angedeutet hat.

Mein Tip: Versuche erstma,l nur das private Netzwerk hinter A bzw B jeweils vom der anderen Seite zu erreichen. Das funktioniert wie gesagt mit push route und iroute. Wenn du das hinbekommen und verstanden hast, kannst du dir überlegen ob du es mit der Standardroute versuchst.
 
  • Gefällt mir
Reaktionen: snaxilian
Zurück
Oben