IPv6 blockieren, um WireGuard abzusichern, bricht den Host

Das Ziel ist vernünftig: Nur Tunnel-Nutzer sollen die Dienste auf dieser Maschine erreichen. Die Umsetzung, zu der viele greifen, ist eine IPv6-Input-Kette, die alles außer WireGuard verwirft, und damit auch den Verkehr, der den Host an seiner eigenen Verbindung hält. Nachbar-Erkennung und Meldungen zur Pfadpflege sind kein Dienstzugriff, und ihr Entfernen erzeugt eine Maschine, die aus Gründen unerreichbar ist, die nichts mit Ihrer Richtlinie zu tun haben. Der Tunnel kommt hoch, die Dienste sind korrekt begrenzt, und sonst funktioniert nichts auf der Verbindung.

Drei Zuständigkeiten, ein Regelsatz

Die erste Zuständigkeit ist der Betrieb des äußeren Netzes: Der Host muss an seiner Verbindung bleiben, Nachbarn auflösen und die Pfadgrenzen dieser Verbindung kennen. Die zweite ist der verschlüsselte Listener, der UDP auf der gewählten Adresse und dem gewählten Port annimmt. Die dritte ist die Menge der entschlüsselten Dienste, die Tunnel-Nutzer erreichen sollen.

Das sind drei verschiedene Richtlinien, und nur die zweite und dritte betreffen das VPN. Ein Regelsatz, der sie als eine behandelt, erbt einen Fehlermodus, in dem eine Verschärfung der Anwendungsgrenze die Host-Anbindung still bricht.

Halten Sie sie in getrennten Ketten oder mindestens getrennten Kommentaren, damit die nächste Person sieht, welche Zeile aus welchem Grund existiert.

Was ICMPv6 für den Host tut

IPv6 verlässt sich weit mehr als für Echo auf ICMPv6. Nachbar-Solicitation und -Advertisement ersetzen ARP und sind für die lokale Zustellung nötig. Packet Too Big trägt Pfad-MTU-Informationen, und wer sie ignoriert, bekommt Übertragungen, die bei großen Paketen hängen bleiben. Router-Advertisement tragen die Standardroute und Präfixinformationen, wenn die Verbindung automatische Konfiguration nutzt.

RFC 4890 trennt die Meldungen, die ein Host-Filter zulassen muss, von denen, die eine administrative Entscheidung sind, und zwar in einem Host-Abschnitt, der sich von den Regeln für einen Router unterscheidet, der zwischen Netzen weiterleitet. Wer nur den Weiterleitungsabschnitt liest, erhält eine Input-Richtlinie, die für den geschützten Host zu streng ist.

Die praktische Regel ist, die wesentlichen Fehler- und Konfigurationsmeldungen auf dem Interface zuzulassen, das sie braucht, nach Typ und Quelle begrenzt, wo die Plattform es erlaubt, und über den Rest ausdrücklich zu entscheiden.

All das durch eine pauschale ICMPv6-Erlaubnis zu ersetzen löst das Verfügbarkeitsproblem und gibt die Filterung auf. Es durch ein pauschales Verwerfen zu ersetzen löst das Filterproblem und gibt den Host auf.

Erst den Tunnel zulassen, dann den Dienst

Nehmen Sie den WireGuard-Transport auf der vorgesehenen äußeren Adresse und dem UDP-Port an und den Rückverkehr über Connection Tracking. Erlauben Sie dann die Anwendungsdienste über das Tunnel-Interface, von den Quellen, die Sie wirklich autorisieren.

Eine Freigabe für den äußeren UDP-Port autorisiert nicht die entschlüsselten Anfragen darin. Genau dieser Unterschied ist der Grund, warum das Tunnel-Interface in den Dienste-Regeln auftaucht.

Lesen Sie den Regelsatz so, wie er ist, nicht wie die Datei ihn beschreibt:

sudo nft list ruleset
ip -6 addr show
ip -6 route show default

Ein Listener auf einer physischen Adresse ist eine eigene Exposition gegenüber demselben Dienst auf der Tunneladresse. Leitet die Maschine auch Verkehr an eine andere weiter, ist das eine Entscheidung der Forward-Kette und nicht diese Input-Richtlinie, und sie braucht eine eigene Begründung.

Prüfen Sie die Verbindung, nicht nur den Tunnel

Ein funktionierender Tunnel nach der Änderung beweist weniger, als es aussieht, weil ein bestehender Nachbar-Eintrag und eine aufgebaute Verbindung eine Kontrollmeldung verbergen können, die die Richtlinie jetzt verwirft.

Prüfen Sie die Anbindung direkt und prüfen Sie dann, dass der ausgeschlossene Pfad weiterhin fehlschlägt:

ip -6 neigh show
ping -6 -c 3 2001:db8:1::1
sudo nft -c -f /etc/nftables.conf

Eine Nachbartabelle, die nach einem Neustart vollständig bleibt, ist das Signal, dass die Erkennung noch funktioniert. Eine Tabelle, die leer läuft und sich nie wieder füllt, ist das Signal, dass Sie sie weggefiltert haben. Der dritte Befehl prüft die Syntax des Regelsatzes, ohne ihn anzuwenden, was sich lohnt, solange Sie noch eine Sitzung haben.

Holen Sie einen Host zurück, aus dem Sie sich ausgesperrt haben

Bevor Sie Firewall-Regeln ändern, die Ihre eigene Administrationssitzung tragen, halten Sie einen zweiten Kanal bereit: eine Konsole, eine serielle Verbindung oder ein geplantes Zurückrollen, das die neuen Regeln entfernt, wenn Sie es nicht abbrechen.

Sperrt eine Änderung Sie tatsächlich aus, läuft die Wiederherstellung über diesen Kanal und nicht über das Netz, das Sie gerade entfernt haben. Stellen Sie den vorherigen Regelsatz aus einer gesicherten Kopie wieder her, bestätigen Sie, dass der Host wieder erreichbar ist, und wenden Sie erst dann die beabsichtigte Richtlinie in kleineren Teilen an.

Die endgültige Richtlinie ist nicht universell. Adressierung, Routing und Firewall-Implementierung sind Eingaben der Bereitstellung, aber die Grenze ist überall dieselbe: ungewollten Anwendungszugriff verweigern und den Kontrollverkehr behalten, der den autorisierten Tunnel trägt.