Mac-PF-VPN-Sperre: eine Standortrichtlinie, keine auslieferbare Funktion

Es funktioniert auf Ihrem Mac, also sieht es wie etwas aus, das Sie Nutzern geben können. Diese Annahme ist das Erste, was Sie verlieren sollten. Apples TN3165 stellt klar, dass Packet Filter keine unterstützte API für allgemein verteilte Produkte ist, und beschreibt privilegierte, kontrollierte Standortverwaltung als den vernünftigen Fall. Eine auf PF gebaute VPN-Sperre ist daher eine lokale Betriebsrichtlinie mit einem Eigentümer, keine Funktion, die Sie in einer App ausliefern können.

PF ist keine Verpackungsfläche

Der Unterschied ist nicht akademisch. Ein verteiltes Produkt, das von PF abhängt, erbt jede Änderung, die Apple daran vornimmt, jeden Konflikt mit einem anderen Werkzeug, das ebenfalls Regeln schreibt, und keine Supportzusage, dass die Anordnung weiter funktioniert. Ein Standort, der seine eigenen Rechner verwaltet, hat eine andere Beziehung: Er kann die Abhängigkeit dokumentieren, sie gegen jede OS-Version testen und die Wartung übernehmen.

Manche Installationshinweise überschreiten eine Grenze, die es wert ist, benannt zu werden. Das Überschreiben des gesamten Systemregelsatzes, damit ein Anchor geladen wird, das Bearbeiten von Apples Systemstartkonfiguration oder das Deaktivieren von System Integrity Protection sind keine akzeptablen Anforderungen für ein wiederverwendbares Rezept. Wenn eine veröffentlichte Anleitung irgendetwas davon braucht, beschreibt sie ein Labor, keine einsatzfähige Richtlinie.

Schreiben Sie die Egress-Absicht vor der Syntax

Entscheiden Sie, was erlaubt ist, bevor Sie ein einziges Schlüsselwort wählen. Normalerweise müssen drei Wege existieren: der eigene Transport des VPN-Clients zu seinem Server, der geschützte Anwendungsverkehr innerhalb des Tunnels und alles, was Einrichtung oder lokale Dienste wirklich als direkten Weg benötigen.

Geben Sie jeder vorgeschlagenen Ausnahme ein Ziel, einen Transport und einen Eigentümer. Alle Ports zu einem Endpunkt zu erlauben, erlaubt weit mehr als den einen Transport, den der Tunnel nutzt, und die zusätzliche Exposition entsteht, ohne dass jemand entschieden hat, dass sie da sein soll. Einen öffentlichen Resolver zu erlauben, ist dieselbe Falle in freundlicherer Verkleidung: Er schafft einen direkten DNS-Weg, selbst während der Tunnel unten ist, sodass Namensauflösungen weiterhin lecken.

Der nützliche Test für eine Ausnahme ist, ob Sie die Person nennen können, die sie verlangt hat, und den Fehler, den sie verhindert. Wenn keine der beiden Antworten existiert, ist die Regel wahrscheinlich ein Workaround für eine Fehlkonfiguration, die sonst unsichtbar bliebe.

utun-Nummern sind keine Identität

MacOS legt Tunnel-Schnittstellen als utun-Geräte an, und die Nummer, die Ihrem VPN zugewiesen wird, ist nicht stabil über Neustarts, Neuverbindungen oder die Anwesenheit eines anderen Clients hinweg. Eine Regel, die mehrere geratene Nummern auflistet, ist keine Richtlinie; sie ist eine Momentaufnahme eines Nachmittags.

Verankern Sie die Regel an etwas, das den beabsichtigten Anbieter identifiziert: den Adressplan, den der Tunnel zuweist, den Prozess, dem die Schnittstelle gehört, oder eine Konfiguration, die der VPN-Client selbst pflegt. Halten Sie dann fest, wie diese Identifikation funktioniert, denn wer die Regel in einem Jahr prüft, wird Ihre Shell-Historie nicht haben.

Machen Sie die geladene Richtlinie zurechenbar

Ein Anchor-Name organisiert Regeln; er beweist nicht, dass die wirksame Richtlinie die beabsichtigte ist. Die Rangfolge zwischen Anchors, Regeln, die andere Software geladen hat, und bestehender Zustand können das Ergebnis verändern. Prüfen Sie den wirksamen Satz mit allen, die auf dieser Maschine ebenfalls PF besitzen, und dokumentieren Sie die Zuständigkeit am selben Ort wie die Konfiguration. Zwei Eigentümer, die verschiedene Anchors mit unterschiedlichen Annahmen bearbeiten, sind der übliche Weg, auf dem eine Sperre ein Loch bekommt.

Halten Sie den Regelsatz im unterstützten Konfigurationspfad des Standorts, versionieren Sie ihn und notieren Sie, welche macOS-Versionen getestet wurden. Eine Änderung, die von Hand angewendet und von einer Person erinnert wird, ist keine gepflegte Infrastruktur, egal was der Dateikopf sagt.

Testen Sie die Übergänge, nicht den verbundenen Zustand

Ein Screenshot, der bei aktivem Tunnel aufgenommen wird, beweist fast nichts. Gehen Sie stattdessen die Zustände durch: Start vor jeder Verbindung, ein funktionierender Tunnel, ein Tunnel, der ohne Warnung abreißt, eine bewusste Trennung und ein Wechsel von WLAN zu Hotspot. Jeder Zustand hat seine eigene Antwort, und die interessanten sind die Fehler, nicht der glückliche Pfad.

Halten Sie in jedem Zustand fest, was absichtlich erreichbar ist. Prüfen Sie IPv4 und IPv6 getrennt, testen Sie die Namensauflösung und beziehen Sie einen Fluss ein, der bereits vor dem Übergang bestand, denn bestehende Verbindungen folgen nicht immer der neuen Richtlinie. Ein Browser, der ausfällt, während der Tunnel unten ist, ist ein Datenpunkt, kein Beweis, dass jeder andere Weg blockiert ist.

Behalten Sie schließlich eine Wiederherstellungsmethode, die nicht von dem Netzwerkweg abhängt, den Sie ändern. Eine bekannt gute Konfiguration auf lokalem Speicher und ein dokumentierter Weg, sie zu laden, machen aus einer Sperre eine Richtlinie; ohne sie sperrt eine schlechte Revision den Administrator aus der Maschine aus, die geschützt werden sollte.