Einen Zielbereich für jeden VPN-Client-Pool blockieren

Eine Regel kann einen zugelassenen VPN-Pool von einem Zielbereich fernhalten, ohne irgendetwas anderes zu stören, was das Gateway tut. Die Regel selbst ist kurz; entscheidend dafür, ob sie wirkt, sind der Hook, in dem sie lebt, und ihre Position in der Kette. Wer diese beiden falsch wählt, bekommt eine Firewall, die korrekt aussieht und sich inkonsistent verhält. Beginnen Sie damit, was das Paket tut, wenn die Regel es sieht.

Was die Regel tatsächlich abgleicht

Die Regel gleicht drei Dinge gleichzeitig ab: ein Eingangsinterface, ein Quellpräfix und ein Zielpräfix. Alle drei müssen zutreffen, bevor der Drop greift, und das hält sie eng. Sie als einen Ausdruck zu lesen ist einfacher, als sie als drei getrennte Richtlinien zu lesen.

Der Interface-Abgleich unterscheidet weitergeleiteten Client-Verkehr von den eigenen Verbindungen des Gateways. Ohne ihn würde eine Regel, die nur den Quell-Pool nennt, auch Pakete betreffen, die das Gateway selbst von dieser Adresse erzeugt, falls es das je tut. Das Quellpräfix beschränkt die Richtlinie auf zugelassene Clients, das Zielpräfix auf einen Bereich. Lesen Sie die Regel als Schnittmenge und nicht als Liste.

Schreiben Sie die drei Werte auf, bevor Sie etwas ändern: den Namen des Tunnel-Interfaces, den Pool, den der Server ausgibt, und das Präfix, das Sie verweigern wollen. Ein Tippfehler in einem davon erzeugt eine Regel, die sauber parst und nichts schützt. Halten Sie diese drei Werte im Änderungsdatensatz neben der Regel fest.

Der Hook entscheidet, für wen die Regel gilt

Eine netfilter-Kette hängt an einem Hook, und der Hook entscheidet, welche Pakete die Kette überhaupt sieht. Der forward-Hook sieht Verkehr, der durch das Gateway geroutet wird, und genau das ist Client-zu-Ziel-Verkehr. Alles andere in der Kette richtet sich an ein anderes Publikum.

Der input-Hook sieht Verkehr, der an das Gateway selbst adressiert ist, also regelt eine dort platzierte Regel den Zugang zu seinen eigenen Diensten statt den Transit. Der output-Hook sieht Verkehr, den das Gateway selbst erzeugt, was das Gegenteil dessen ist, was eine Client-Pool-Richtlinie braucht. Kettennamen sind beliebige Beschriftungen, die der Autor des Rulesets gewählt hat, also leiten Sie den Hook nicht aus dem Namen ab. Prüfen Sie, wo die Kette hängt, bevor Sie annehmen, was sie abgleichen kann.

Die Anbindung zu lesen ist eine Prüfung in einer Zeile, die verhindert, dass eine Regel in einer Kette landet, die das Paket nie sieht.

Platzieren Sie die Regel vor dem breiten Accept

Regeln werden der Reihe nach ausgewertet, und das erste Urteil gewinnt. Ein breiter Accept weiter oben in der Kette beendet die Auswertung für die Pakete, die er trifft, sodass ein danach angehängter Drop für sie nie läuft. Diese Reihenfolgeregel ist der ganze Grund, warum eine korrekt aussehende Regel wirkungslos sein kann.

Fügen Sie die Regel vor dem Accept ein, statt sie ans Ende zu hängen. Enthält die Kette bereits einen allgemeinen Accept für das Tunnel-Interface, muss die neue Regel davor stehen, sonst ist sie dekorativ. Prüfen Sie die resultierende Reihenfolge und nicht die Datei, die Sie bearbeitet haben, denn ein aus mehreren Dateien zusammengesetztes Ruleset entspricht vielleicht keiner einzelnen davon. Bestätigen Sie es dann mit einem Testpaket aus dem Pool.

sudo nft list chain inet filter forward
sudo nft insert rule inet filter forward iifname "tun0" ip saddr 10.90.0.0/24 ip daddr 198.51.100.0/24 drop
sudo nft -c -f /etc/nftables.conf

Der dritte Befehl parst die Datei, ohne sie anzuwenden, und fängt damit Syntaxfehler ab, bevor sie zum Ausfall werden. Wenden Sie ihn mit einem Rückplan an, denn eine falsche Regel in einer forward-Kette kann den Tunnel kappen, über den Sie arbeiten.

Bestehende Flows interessieren Ihre neue Regel nicht

Ein conntrack-Eintrag, der entstand, bevor die Regel existierte, passt weiterhin auf die frühere Annahme. Deshalb scheint ein neuer Drop manchmal für frische Verbindungen zu wirken und für die getestete nichts zu tun.

Lesen Sie den State-Abgleich oben in der Kette. Wenn er established- und related-Verkehr vor Ihrer Regel annimmt, fließt jeder bereits laufende Flow weiter, bis er schließt. Das ist meist das Verhalten, das Sie für eine Notfallregel wollen, und es ist verwirrend, wenn Sie einen sofortigen Schnitt erwarten. Entscheiden Sie vor dem Ausrollen, welche Wirkung Sie wollen. Ein Test, der eine offene Verbindung wiederverwendet, erzählt Ihnen die falsche Geschichte.

sudo conntrack -L -s 10.90.0.14 -d 198.51.100.20
sudo nft list ruleset | grep -n -A3 'ct state'

Der erste Befehl zeigt, ob ein Flow existiert, und der zweite, ob eine frühe State-Regel ihn weiterhin annimmt. Beide sind nur lesend und während eines Vorfalls sicher auszuführen.

Was diese Regel nicht ist

Die Regel ist keine Domain-Blacklist, keine IPv6-Richtlinie und keine Beschränkung für ein einzelnes Anwendungskonto.

Jedes davon braucht seinen eigenen Mechanismus. Eine Domain-Sperre muss Namen auflösen, was ein Paketfilter nicht tut. IPv6-Verkehr braucht seinen eigenen Abgleich, weil ein ip-Ausdruck nichts über ip6-Pakete sagt. Eine Beschränkung auf Anwendungsebene gehört zum Dienst oder zu einem authentifizierten Proxy und nicht zu einem Präfix-Abgleich. Diese Anforderungen getrennt zu halten verhindert, dass eine enge Regel vier Aufgaben erledigen soll.

Der Vertrag, den diese Regel liefert, ist präzise: Verkehr aus einem zugelassenen Pool zu einem Zielpräfix wird verweigert, während unabhängiger Gateway-Verkehr seine bestehende Richtlinie behält. Schreiben Sie diesen Satz neben die Regel, und die nächste Person weiß, wofür sie da war.