Statische Tunneladressen in pfSense: Präferenz oder Reservierung?

Zwei Entwürfe wirken auf dem Papier ähnlich und verhalten sich ganz anders, sobald eine Regel von ihnen abhängt. Der eine trägt eine Adresse in ein Client-Override ein und vertraut der Adresse als Identität. Der andere schließt die dynamische Aufnahme vollständig, sodass ein Endpunkt entweder eine eindeutige Zuweisung hat oder gar nicht verbindet. Nur der zweite macht aus einer Adresse eine Richtlinienangabe, die man verteidigen kann, und der Unterschied lohnt sich zu verstehen, bevor man auch nur eine einzige Firewall-Regel schreibt.

Was eine Override-Adresse wirklich verspricht

Ein Client Specific Override trägt Optionen pro Client, darunter eine bevorzugte Tunneladresse. Netgate beschreibt diese Adresse als Präferenz und nicht als Reservierung, was bedeutet, dass der dynamische Pool die Adresse für niemanden anderen freigibt.

Das ist meistens in Ordnung. Eine Kollision ist selten, und der Client erhält normalerweise, was er angefordert hat, was für Bequemlichkeit reicht und für Autorisierung nicht. Bequemlichkeit und Autorisierung sind verschiedene Anforderungen, und nur eine von ihnen übersteht eine Kollision.

Bei Subnetz-Topologie nimmt das Feld die Client-Adresse zusammen mit der Maske des Servernetzes auf, sodass eine Adresse innerhalb eines 10.90.0.0/24 Tunnels als 10.90.0.10/24 geschrieben wird.

Nichts davon reserviert die Nummer. Ein Client, dessen Override nicht passt, oder eine doppelte Sitzung kann woanders im Pool landen, und eine auf die Adresse abgestellte Regel beschreibt dann jemanden, der nicht da ist.

Den dynamischen Pfad mit einem eingegrenzten Default schließen

Die Alternative ist ein rein statischer Server: Jeder zugelassene Endpunkt hat seine eigene Identität und seine eigene eindeutige Adresse, und nichts anderes kommt hinein.

Die Umsetzung bedeutet ein DEFAULT-Override, das auf diesen einen Server begrenzt ist und bei dem die Verbindungssperre aktiviert ist. Ein Client ohne passendes Override kann dann nicht auf die gewöhnliche dynamische Aufnahme zurückfallen. Diese eine Zeile ist es, die eine Präferenz in eine geschlossene Menge verwandelt.

Der Geltungsbereich zählt. Ein Standard-Override, das auf jede VPN-Instanz auf der Box angewendet wird, sperrt unabhängige Tunnel aus, und dieser Fehler sieht wie ein defekter Dienst aus statt wie eine Richtlinienentscheidung. Binde es an den einen Server, dessen Aufnahmemodell du änderst. Vermerke den Geltungsbereich dann im Änderungsprotokoll, weil die nächste Person nicht mehr weiß, zu welchem Tunnel er gehört.

Prüfe anschließend die gesamte erlaubte Menge. Die Standardsperre behebt kein benanntes Override, das ohne Adresse geblieben ist, und dieser Endpunkt wird einfach keine Verbindung aufbauen, ohne einen offensichtlichen Hinweis darauf, warum.

Auf die Identität abstellen, die der Server wirklich verwendet

Ein Override passt auf etwas. Auf einem Server, der Zertifikats-Common-Names abgleicht, muss der Override-Name dieser Common Name sein, nicht der Anzeigename der Person. Kopiere ihn aus dem Zertifikat und nicht aus der Kontoliste.

Ein Server, der dafür konfiguriert ist, den Benutzernamen als Common Name zu verwenden, gleicht auf einem ganz anderen Schlüssel ab, und ein auf das Zertifikat benanntes Override wird nie auslösen. Lies die Einstellung, statt sie aus dem abzuleiten, was die Kontoliste zeigt.

Behalte die zusätzlichen Authentifizierungsfaktoren bei, die die Bereitstellung verlangt. Ein geschlossenes Adressmodell ändert, wer verbinden darf und welche Adresse er erhält; es ersetzt nicht die Zertifikatsprüfung oder den zweiten Faktor.

Die Zugriffsregeln schreiben, nachdem die Zuordnung stimmt

Sobald die Zuordnung von Identität zu Adresse geschlossen ist, können Regeln Adressen referenzieren, ohne vorzugeben, sie seien Personen. Ein Alias, der die Endpunkte einer Person gruppiert, kann einen bestimmten Dienst erreichen, während ein anderer Alias etwas anderes erreicht. Der Alias wird zum prüfbaren Objekt, und die Adresse wird zum Implementierungsdetail darin.

Halte Ziele und Ports explizit. Das gesamte lokale Netz aus dem ganzen Tunnelpool zuzulassen ist genau der Entwurf, den diese Übung ersetzen sollte.

Lies Floating-, Gruppen- und Interface-Regeln in ihrer tatsächlichen Auswertungsreihenfolge, weil eine frühere breite Freigabe eine spätere enge aushebelt. Das Abschalten der internen Weiterleitung von Client zu Client hält Peer-Verkehr an der Grenze, an der diese Regeln geprüft werden. Eine Regel, die nur auf dem Papier existiert, ist keine Durchsetzung.

Die negativen Fälle testen

Probiere vier frische Verbindungen aus: einen benannten Endpunkt, einen ganz ohne Override, einen Dienst, der erreichbar sein sollte, und einen, der es nicht sein sollte. Der nicht gelistete Endpunkt ist der wichtige Fall, denn er ist derjenige, den der Entwurf stoppen soll. Wenn er verbindet, erfüllt die Standardsperre ihre Aufgabe nicht.

Prüfe IPv6 separat, da eine IPv4-Adressrichtlinie nichts über einen zweiten Stack aussagt. Bestätige dann, dass die Anwendung den Benutzer weiterhin autorisiert, weil eine Tunneladresse eine Netzwerktatsache ist und kein Beweis dafür, wer an der Tastatur sitzt. Beide Prüfungen gehören in die Abnahmenotiz.

Plane schließlich die Migration. Neue Overrides und enge Regeln ändern bereits aufgebaute Sitzungen nicht rückwirkend, daher müssen bestehende Zustände auslaufen oder bewusst gelöscht werden.