IPsec blockieren, ohne das Wi-Fi Calling des Telefons zu zerstören

Die Anfrage kommt immer in derselben Form: IPsec an der Edge schließen, weil es Tunnel transportiert, die niemand genehmigt hat, und die erste Beschwerde kommt von jemandem, dessen Telefon keine Anrufe über WLAN mehr führt. Beide Tatsachen sind gleichzeitig wahr, und keine von ihnen rechtfertigt, die Kontrolle aufzugeben. Was die Firewall braucht, ist eine Dienstausnahme mit benannter Funktion, begrenzter Quelle, dokumentierten Zielen und einem Verantwortlichen. Fünf Schritte machen daraus eine Regel, die ein Fremder im nächsten Jahr prüfen kann.

Benennen Sie den Dienst, bevor Sie das Protokoll benennen

Ein Tischtelefon an einem SIP-Dienst und ein Handgerät, das Wi-Fi Calling des Mobilfunkanbieters nutzt, teilen kein Netzwerkprofil, und VoIP als Firewallbegriff beschreibt keines von beiden. Port- und Zieldaten müssen vom Hersteller oder vom Anbieter kommen, der den Dienst betreibt, nicht aus einer erinnerten Portliste eines anderen Telefonsystems. Das ist der Unterschied zwischen einer Regel, die eine Funktion schützt, und einer Regel, die ein Wort schützt.

Apples Referenz zu Dienstports listet UDP 500 und 4500 für Wi-Fi Calling auf, also genau das Paar, das die meisten pauschalen IPsec-Sperren verwerfen. Schreiben Sie den Funktionsnamen neben diesen Ports in den Änderungsdatensatz. Fügen Sie Version oder Datum der verwendeten Referenz hinzu, denn Herstellertabellen werden bearbeitet. Eine Regel, die den Dienst benennt, für den sie existiert, lässt sich prüfen; eine, die eine Protokollkategorie benennt, nicht.

Schreiben Sie die Ausnahme als Vertrag, nicht als Gefälligkeit

Die Ausnahme nennt die erlaubte Funktion, die Geräteklassen, die sie nutzen, den benötigten Transport und die Ziele, die die verantwortliche Stelle dokumentiert. Sie trägt außerdem einen Verantwortlichen und ein Prüfdatum, denn Anbieterendpunkte und Handgerätemodelle ändern sich, ohne das Firewallteam zu informieren. Geben Sie die Prüfung einer Person statt einem Teamnamen, der das Team überlebt. Halten Sie die Formulierung so konkret, dass ein Fremder die Regel allein aus dem Datensatz ableiten kann.

Legen Sie die Ausnahme in denselben Zyklus wie die übrige Edge-Policy, damit ein Anbieter, der ein Ziel verschiebt, oder eine Flotte, die das Handgerätemodell wechselt, bei der Prüfung auffällt und nicht beim nächsten Ausfall. Schließen Sie die Schleife mit der Person, die die ausgefallenen Anrufe gemeldet hat, denn nur sie kann die Behebung bestätigen, ohne den Tunnel wieder zu öffnen, den die Sperre schließen sollte. Diese Bestätigung gehört mit Datum ebenfalls in den Datensatz.

Eine dauerhafte Freigabe, die als vorübergehende Telefonreparatur etikettiert ist, ist zwei Jahre später unhaltbar. Eine Freigabe, die an einen identifizierten Dienst gebunden ist, hat ein Ablaufdatum, das bewusst erneuert wird.

Grenzen Sie die Quelle ehrlich ein

Die Ausnahme auf ein verwaltetes Gerätesegment zu begrenzen, ist wesentlich stärker, als das Protokoll für jeden Laptop im Gebäude zu öffnen. Kann das Netzwerk dieses Segment nicht identifizieren, schreiben Sie das hin, statt anzudeuten, die Regel sei gerätebewusst. Das billigste gute Ergebnis ist, eine Grenze wiederzuverwenden, die bereits aus einem anderen Grund existiert, sodass die Ausnahme eine Kontrolle erbt, statt eine zu erfinden. Filtern nach Adresse ist keine Geräteauthentifizierung, und der Änderungsdatensatz sollte nichts anderes nahelegen.

Eine Quelladresse oder eine Hardwareadresse ist kein Beweis für ein physisches Handgerät. Ob eine von beiden Bedeutung hat, hängt vollständig von den anderen Kontrollen in diesem Segment ab. Stützt sich das Argument für die Regel auf eine MAC-Adresse, prüfen Sie, was einen Benutzer daran hindert, sie zu ändern, bevor die Regel ausgeliefert wird.

Akzeptieren Sie, was eine Portregel Ihnen nicht sagen kann

Ports identifizieren Transportendpunkte, nicht Geschäftsabsicht. Wenn ein genehmigter Anrufdienst und ein nicht genehmigter Tunnel beide über UDP 4500 laufen, trennt sie keine portbasierte Regel. Eine Regel, die behauptet, das zu tun, wirkt präzise und ist es nicht, was schlimmer ist als eine Regel, die ihre eigene Form einräumt. Das ist eine Grenze des Mechanismus, kein Fehler der Person, die ihn geschrieben hat.

Sagen Sie es neben der Regel und verbinden Sie die Ausnahme mit der Durchsetzung, die das Netzwerk hat, etwa Geräteverwaltung oder einer Zielliste. Dann formulieren Sie die Ausnahme so eng wie das Werkzeug erlaubt, zum Beispiel mit nftables-Regeln, die das Segment und das Portpaar benennen und die allgemeine Ablehnung dahinter setzen:

nft add rule inet edge forward ip saddr 10.40.0.0/24 udp dport { 500, 4500 } counter accept
nft add rule inet edge forward udp dport { 500, 4500 } counter drop

nftables wertet der Reihe nach aus und stoppt beim ersten Treffer, also muss die eng gefasste Erlaubnis über der allgemeinen Ablehnung stehen. Drehen Sie beide um, und die Ausnahme tut stillschweigend nichts.

Validieren Sie die Funktion und die Ablehnung

Führen Sie die genehmigte Validierung mit einem gewöhnlichen WLAN-Anruf aus der Geräteklasse durch, für die die Ausnahme existiert, und bestätigen Sie, dass ein ausgeschlossener Client weiterhin scheitert. Verwenden Sie unter keinen Umständen Notrufe als Testfall. Prüfen Sie dann die ausgelieferte Regel, denn ein auf null stehender Zähler ist der schnellste Beweis, dass die Ausnahme nie getroffen hat:

nft -a list chain inet edge forward

Nehmen Sie eine Neuverbindung oder einen Netzwerkwechsel in den Test auf und wiederholen Sie ihn aus einem Kaltstart, bei dem das Telefon dem Netzwerk beitritt, statt bereits verbunden zu sein. Bewegt sich der Zähler, während Anrufe weiter scheitern, hat das Problem die Firewall verlassen und gehört zur Zielliste des Anbieters.