Ich habe im Wesentlichen ein Routing-Problem und bin mit Routing und iptables nicht vertraut genug, um die Probleme effektiv zu beheben und meine Netzwerkanforderungen einzurichten.
Was funktioniert
Ich habe ein OpenVPN-Netzwerk eingerichtet und es funktioniert; Clients können über das Internet eine Verbindung zu einem LAN herstellen.
Was ich gerne hätte
... wenn ein Client eine Verbindung zum VPN in einem bestimmten Subnetz herstellt.
- Der Client sollte vom VPN-Netzwerk aus erreichbar sein
Bonuspunkte, wenn die Regeln eines oder mehrere der folgenden Dinge können:
- Der Client sollte nicht in der Lage sein, Verbindungen zum VPN herzustellen
- Der Client sollte in unserem DNS angezeigt werden
Topologie
Unsere Netzwerktopologie sieht ungefähr so aus:
______ ____________________
/ \ / \
| internet |---| client (10.8.8.0/24) |
\________/ \____________________/
|
______
/ \
| gateway |
\________/
|
-----LAN------ (10.10.10.0/24)
| | | |
L_____VPN Server `VPN1` 10.10.10.2 (fictional name/subnet)
Aktuelle Einstellungen
Für unser Gateway ist die folgende Route definiert:
10.8.8.0 255.255.255.0 10.10.10.2 LAN & WLAN
Auf VPN1gelten für iptables folgende Regeln
# Flush the filter and nat tables
iptables -t filter -F
iptables -t nat -F
iptables -A INPUT -i tun+ -j ACCEPT
iptables -A FORWARD -i tun+ -j ACCEPT
iptables -A INPUT -i eth0 -j ACCEPT -d 10.8.8.0/24
iptables -A FORWARD -i eth0 -j ACCEPT
iptables -t nat -A POSTROUTING -s 10.10.10.0/16 -d 10.8.8.0/24 -o tun+ -j MASQUERADE
Was passiert derzeit
Das Ausführen des Befehls mtr 10.8.8.1(die IP des verbundenen Clients im VPN) zeigt, dass die aktuelle Route zwischen VPN1 und dem Gateway hin- und herspringt.
Antwort1
Nach einer weiteren zermürbenden Runde des Iptables-Online-Lernwahnsinns habe ich die Lösung entdeckt.
Zunächst gibt es jedoch eine ungültige Annahme bezüglich iptables. Mein anfänglicher Ansatz zu den Regeln war, dass ein empfangenes Paket die INPUT- und OUTPUT-Ketten durchlaufen würde. Das ist nicht so; sobald eine Regel mit einem Paket übereinstimmt, verlässt es die Tabelle. Da die Filtertabelle angenommen wird, sofern nicht anders angegeben (z. B. „-t nat“), werden die meisten der aufgeführten Regeln auf der Filtertabelle ausgeführt.
In Bezug auf Ketten
- EINGANG: Wird auf Paketen ausgeführt, die für den Server bestimmt sind
- AUSGABE: Wird auf Paketen ausgeführt, die vom Server stammen
- NACH VORNE: alles andere - wenn eine Regel hier passt, und der "Sprung" (ich denke gerne, wenn-Jals "Job" ;) ist ACCEPT, das Paket wird entsprechend geroutet
Eine Aufschlüsselung der Regeln
Dies ist eine Beschreibung der Regeln unterAktuelle Einstellungenüber
iptables -t filter -F
iptables -t nat -F
Diese Regeln spülen einfach dieFilterUndnatürlichTabellen. Beachten Sie, dass es mehr Tabellen und eine gründlichere Möglichkeit zum Löschen von iptables-Regeln gibt.
iptables -A INPUT -i tun+ -j ACCEPT
Diese Regel bewirkt nichts, weil:
- Es wird für den Datenverkehr ausgeführt, der für VPN1 bestimmt ist, nicht für ein anderes Netzwerk.
- Für eingehenden Datenverkehr ist keine Richtlinie festgelegt, daher ist er standardmäßig zulässig
weiter geht‘s …
iptables -A FORWARD -i tun+ -j ACCEPT
Mit dieser Regel kann Datenverkehr von 10.8.8.0/24 weitergeleitet werden. Regeln in dernatürlichTabelle wird für Pakete ausgeführt, die dieser Regel entsprechen.
iptables -A INPUT -i eth0 -j ACCEPT -d 10.8.8.0/24
Auch auf das gewünschte Routing hat diese Regel keine Auswirkung, da der 10.8.8.0/24-Verkehr nicht für den VPN1-Server bestimmt ist.
iptables -A FORWARD -i eth0 -j ACCEPT
Diese Regel ermöglicht die Weiterleitung des Datenverkehrs von 10.10.10.0/16.
iptables -t nat -A POSTROUTING -s 10.10.10.0/16 -d 10.8.8.0/24 -o tun+ -j MASQUERADE
Diese Regel bewirkt, dass der für das VPN bestimmte Datenverkehr von 10.10.10.0/16 so aussieht, als käme er von VPN1. Dadurch wird VPN1 effektiv wie ein Gateway aussehen.
Was ist falsch?
Die Regeln sollten so, wie sie sind, „OK“ sein, um Verkehr von einem Netzwerk zum nächsten zu leiten. Es gibt keinen wirklichen Schutz – z. B. eine standardmäßige „DROP“-Richtlinie usw., aber darum geht es in der Frage nicht.
Wenn iptables so eingerichtet ist, dass es den Datenverkehr über das VPN weiterleiten kann, was würde dazu führen, dass er zurückgesendet wird?eth0zum Gateway? Wenn VPN1 10.8.8.0/24 nicht kennen würde. Wenn der VPN-Server dieses Netzwerk nicht kennen würde, würde es als Internetverkehr behandelt und an das Gateway zurückgesendet.
Die Reparatur
Die Lösung bestand darin, dem VPN-Server das Netzwerk mitzuteilen (dies ist ein OpenVPN-Server). Dies kann auf zwei Arten erfolgen. Wenn der Server nur ein Netzwerk bedient, ist dies eine einfache Konfigurationseinstellung:
server 10.8.8.0 255.255.255.0
In meinem Fall hatte ich die Serverroute eingerichtet und musste sie über ein zusätzliches Netzwerk informieren. Die Konfiguration sah eher so aus:
server 10.5.5.0 255.255.255.0
route 10.8.8.0 255.255.255.0
Das ist es! Sobald VPN1 eine Route zum Netzwerk hat, kann die FORWARD-Kette den Datenverkehr weiterleiten.
Ein besseres iptables-Setup
Nach dem Leeren von iptables würde eine bessere Konfiguration ungefähr so aussehen:
# Forward established traffic so that (in the above case) VPN1 doesn't
# drop responses from the client, A.K.A. "the magic"
iptables -t filter -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -t filter -A FORWARD -s 10.10.10.0/16 -d 10.8.8.0/24 -j ACCEPT
iptables -t nat -A POSTROUTING -s 10.10.10.0/16 -d 10.8.8.0/24 -j MASQUERADE
# Drop everything else that wants to be forwarded
iptables -P FORWARD DROP
Beachten Sie, dass es keine expliziten Regeln für Datenverkehr von 10.8.8.0/24 gibt. Das bedeutet, dass der Datenverkehr standardmäßig das Netzwerk 10.10.10.0/16 nicht erreicht – mit Ausnahme des Datenverkehrs als Antwort auf Datenverkehr von 10.10.10.0/16. Nachdem iptables nun eingerichtet ist, können Clients in der VPN-Konfiguration eine IP zugewiesen und für eine vollständige Lösung zum DNS hinzugefügt werden.