iptables: VPN-Clients nur einen Host erreichen lassen

Die Regel, die Sie brauchen, steht in FORWARD, nicht in INPUT. Erlauben Sie ein Ziel für den VPN-Pool, verwerfen Sie den Rest und belegen Sie es dann mit Zählern und einem Rollback-Befehl.

Zwei Support-Tickets, die unabhängig wirken, haben am Ende eine Ursache. Im ersten möchte ein Administrator, dass der Server Verbindungen nur aus dem Tunnel annimmt; im zweiten sollen VPN-Nutzer genau einen internen Host erreichen und nichts weiter. Beide Richtlinien gehören in FORWARD, und beide werden meist in INPUT versucht. Das Ergebnis sieht wie eine Firewall aus und verhält sich wie ein Platzhalter.

Welche Kette Ihre Frage beantwortet

Pakete, die ein VPN-Client an einen Host im LAN oder weiter ins Internet schickt, werden vom Kernel weitergeleitet und in FORWARD bewertet. INPUT und OUTPUT sehen nur Verkehr, der am Server selbst endet oder von ihm ausgeht. Ein Reject für alles, was nicht über tun0 ankommt, schützt daher die eigenen Listener des Servers und beendet außerdem Ihre SSH-Sitzung, wenn nicht zuerst etablierte Flows zugelassen werden. An der Frage, wohin Clients dürfen, ändert das nichts.

Benennen Sie zuerst die Frage: wer darf den Server erreichen, oder wohin dürfen Clients. Die meisten Netze brauchen beide Antworten, in verschiedenen Ketten.

Erst der Zustand, dann die Erlaubnis, dann die Ablehnung

Eine Positivliste funktioniert nur, wenn die konkrete Erlaubnis über der allgemeinen Ablehnung steht und wenn Rückverkehr über beiden zugelassen wird. Fügen Sie Regeln an ausdrücklichen Positionen ein und geben Sie die Kette dann mit iptables -S FORWARD aus, damit die Reihenfolge sichtbar und nicht angenommen ist.

POOL=10.99.0.0/24
iptables -I FORWARD 1 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
iptables -I FORWARD 2 -s "$POOL" -d 172.31.20.15 -p tcp -m multiport --dports 443,3389 -j ACCEPT
iptables -I FORWARD 3 -s "$POOL" -j REJECT

Zwei Details entscheiden, ob das den Kontakt mit echtem Verkehr übersteht. Ohne die Zustandsregel werden Antworten auf die gerade erlaubten Verbindungen selbst gegen die Ablehnung bewertet und verworfen. Eine ungebremste LOG-Regel kann eine kleine Partition beim ersten Scan füllen, also fügen Sie -m limit --limit 10/min hinzu, bevor Sie weiter protokollieren. REJECT gibt sofort einen Fehler zurück, was beim Feintuning der Liste freundlicher ist; DROP verwirft still, sodass jeder Fehler als Timeout erscheint. Wählen Sie eines bewusst und schreiben Sie die Wahl in den Änderungseintrag.

Weiterleitung und NAT müssen bereits laufen

Filtern kann nicht beweisen, dass ein Pfad existiert. Bestätigen Sie zuerst, dass der Kernel überhaupt weiterleitet, und machen Sie diese Einstellung dauerhaft statt zu einem einmaligen Shell-Befehl. Der Filter ist die letzte Schicht, nicht die erste.

sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A POSTROUTING -s "$POOL" -o eth0 -j MASQUERADE

Wohin das Masquerading gehört, hängt davon ab, wo die Clients hinausgehen. Verlassen sie den Tunnel in Richtung eines entfernten Netzes, gehört die NAT-Regel auf dieses Interface statt auf das WAN-Interface. Beobachten Sie dann die Zähler: Bewegt sich der POSTROUTING-Zähler nie, während die Zahl der FORWARD-Accepts steigt, ist der Rückweg kaputt und der Filter in Ordnung. Diese Lesart spart einen Nachmittag damit, Regeln umzuschreiben, die nie das Problem waren.

Der Mail-Block gehört eine Kette weiter

Port 25 in INPUT zu blockieren, stoppt nur Mail an den VPN-Server. Ein kompromittierter Client, der Mail durch den Tunnel schickt, wird weitergeleitet, also muss der Block in FORWARD neben 465 und 587 sitzen. Wenn eine Anwendung Mail legitim weiterleitet, setzen Sie ihr Ziel und ihren Port über diese Regel.

iptables -I FORWARD 2 -s "$POOL" -p tcp -m multiport --dports 25,465,587 -j REJECT

Lassen Sie den Reject-Zähler eine Woche laufen, bevor Sie sonst etwas verschärfen. Die Zahl, die aufhört zu steigen, ist der legitime Fluss, den Sie gerade gebrochen haben.

Lesen Sie es zurück und beweisen Sie es dann von einem Client

Lesen Sie das Regelset so, wie der Kernel es meldet, nicht wie Ihr Skript es geschrieben hat. Beginnen Sie mit iptables -S FORWARD, dann die NAT-Tabelle mit iptables -t nat -L POSTROUTING -n -v, dann der Conntrack-Eintrag für den Fluss, den Sie prüfen. Halten Sie einen Rollback-Befehl oder ein geplantes Flush bereit, solange die Arbeit dauert. Jeder Aufruf braucht -w, sonst kollidieren zwei Administratoren am xtables-Lock. Nichts davon ist in einem Änderungsfenster optional.

Schließen Sie mit einem Test von einem Client innerhalb des Pools und einem außerhalb ab. Eine Regel, die nur von der Maschine funktioniert, auf der Sie sie getippt haben, ist keine Richtlinie.

Ähnliche Artikel