Mail fragt weiter ab, das VPN ist aus, doch das Konto synchronisiert weiterhin. Die App tut, wofür sie konfiguriert wurde; nichts in einem normalen Mailprofil sagt, der Server sei nur über den Tunnel erreichbar. Damit bleiben zwei verschiedene Anforderungen, und sie werden leicht vermischt: Der Dienst soll direkte Clients ablehnen, oder der Mac soll den Versuch gar nicht erst machen.

Wählen Sie die Anforderung, bevor Sie ein Produkt wählen. Eine Serverregel und eine Clientregel scheitern an verschiedenen Stellen, liefern verschiedene Belege und gehören verschiedenen Verantwortlichen. Beides anzuwenden ist gültig, wenn beide Aussagen zutreffen, doch das eine ersetzt das andere nicht. Beide Anforderungen sind berechtigt; sie sind nur nicht dieselbe Kontrolle.

Das Symptom sieht nach dem Mac aus, doch der Server kann das Leck sein

Wenn Mail außerhalb des Tunnels synchronisiert, beginnen Sie damit, was der Server annimmt. Wenn der Mail-Listener eine direkte Verbindung aus dem Internet beantwortet, ändert keine Bequemlichkeitseinstellung auf Clientseite diese Tatsache. Der Mac verhält sich normal gegenüber einem Dienst, der noch offen ist.

Fragen Sie den Mailadministrator, welche Quelladresse der Dienst sieht. Ein VPN-Gateway, ein Reverse-Proxy oder ein Load Balancer kann die Clientadresse übersetzen, sodass der Adresspool in der VPN-Konfiguration nicht mit dem übereinstimmen muss, was am Mailprozess ankommt. Eine Regel gegen die falsche Quelle blockiert entweder alle oder niemanden.

Diese Antwort sagt auch, ob der Dienst VPN-Clients überhaupt unterscheiden kann. Wenn jeder Client über dieselbe Proxyadresse ankommt, kann eine quellbasierte Zulassung sie nicht trennen, und die Anforderung muss auf die Authentifizierung oder auf die Clientseite wandern.

Serverzulassung: die Quelle ablehnen, nicht die App

Eine Host- oder Netzwerkfirewall kann den Mail-Listener auf freigegebene Quellbereiche beschränken und Authentifizierung sowie TLS unverändert lassen. Eine Regelbedingung, die entfernte Adressen, Subnetze oder Bereiche abgleicht, ist der übliche Baustein; die genaue Syntax gehört zum Firewallprodukt des Servers, nicht zur Mail-Anwendung.

Das ist die stärkste Grenze, wenn die Anforderung lautet „der Dienst darf keine direkten Clients bedienen“. Sie hält auch dann, wenn der Benutzer einen anderen Mailclient installiert, weil die Ablehnung vor der Authentifizierung erfolgt. Sie übersteht auch einen Mac, der seine VPN-Richtlinie ignoriert.

Ihre Grenze ist ebenso wichtig. Eine abgelehnte Verbindung beweist, dass der Dienst die Sitzung abgelehnt hat; sie beweist nicht, dass der Mac keinen Versuch gemacht hat. DNS-Auflösung, ein TCP SYN an einen früheren Load Balancer und ein erneuter Versuch nach einem Fehler können alle geschehen, bevor die Serverregel erreicht wird. Wenn es bei der Anforderung um die Offenlegung von Versuchen geht und nicht um Zugriff, ist die Serverzulassung nur die halbe Kontrolle.

Durchsetzung am Client: den Versuch blockieren, nicht nur den Tunnel

Eine clientseitige Regel muss den Verkehr verbieten, nicht bloß einen Tunnel starten, wenn Mail geöffnet wird. Ein Aktivierungsauslöser für eine Mail-Domain kann das VPN im richtigen Moment hochfahren, definiert aber nicht, was passiert, während der Tunnel aus ist oder nachdem er scheitert.

Nutzen Sie die unterstützte Blockierungsrichtlinie des Endpunktprodukts und legen Sie ihren Geltungsbereich bewusst fest. Eine Regel auf App-Ebene erfasst jedes Konto in dieser Mail-App, auch persönliche. Eine Regel auf Zielebene muss die IMAP-, Sende- und Authentifizierungsendpunkte des Arbeitskontos benennen und muss weiter funktionieren, wenn sich diese Adressen ändern.

Decken Sie beide Adressfamilien und bestehende Sitzungen ab. Eine Richtlinie, die neue IPv4-Verbindungen blockiert, IPv6 oder einen etablierten Socket aber unberührt lässt, erzeugt zeitweise Synchronisierungen, die zufällig wirken. Netzwerkwechsel und Schlafzyklen gehören zu demselben Test.

Regeln auf App- und Zielebene haben unterschiedliche Reichweite

Eine Blockade auf App-Ebene ist einfach zu durchdenken: Kein Verkehr aus Mail verlässt das Gerät ohne den Tunnel. Sie ist auch grob, weil dieselbe Anwendung ein persönliches Konto halten kann, das mit der Richtlinie nichts zu tun hat. Nutzer merken das zuerst und melden es als defekte Mail-App.

Eine Blockade auf Zielebene ist enger und schwerer zu pflegen. Sie braucht die vollständige Menge der Endpunkte, die das Konto nutzt, einschließlich Ermittlungs- und Authentifizierungsdiensten, und einen Prozess, um sie zu aktualisieren. Fehlt einer, arbeitet das Konto halb; nimmt man zu viele auf, stoppt unbezogene Mail.

Wählen Sie nach der Formulierung der Anforderung. „Dieses Arbeitskonto darf nicht direkt verbinden“ deutet auf den Zielumfang. „Dieser Mac darf Mail nicht außerhalb des VPNs betreiben“ rechtfertigt die breitere App-Regel, sofern der Verantwortliche den Nebeneffekt für das persönliche Konto akzeptiert.

Ablehnung und Ausbleiben getrennt testen

Verbinden Sie sich mit einem dedizierten Testkonto über das VPN und bestätigen Sie den normalen Betrieb. Trennen Sie dann und testen Sie zweimal: einmal, ob der Server die Anmeldung ablehnt, und einmal, ob der Mac überhaupt eine Verbindung versucht. Das sind verschiedene Beobachtungen, und sie gehören in verschiedene Protokolle.

Achten Sie auf der Clientseite auf einen SYN oder eine DNS-Abfrage, während Sie getrennt sind, und im Serverprotokoll auf eine abgelehnte oder angenommene Sitzung. Wenn der Server ablehnt, der Client aber weiter versucht, funktioniert die Serverregel, und die Clientregel fehlt. Wenn der Client nichts versucht, der Server aber weiter andere Clients annimmt, liegt die Grenze genau dort, wo Sie sie gesetzt haben.

Notieren Sie den Verantwortlichen für die Durchsetzung, die Quelladresse, die der Server tatsächlich sieht, und das verwendete Testkonto. Die nächste Netzwerk- oder Proxyänderung kann diese Quelle verschieben, und eine Notiz, die den beobachteten Wert nennt, ist schneller zu prüfen als eine weitere Runde Rätselraten.

Ähnliche Artikel