Firebox-Geolokalisierungs-Ablehnung: erst die VPN-Eintrittsstufe finden

Jemand in einem anderen Land kann keine Verbindung aufbauen, und der erste Instinkt ist, die Regel anzusehen, die Zugriff auf interne Ressourcen gewährt. Diese Regel greift erst nach der Zulassung, kann also nicht die Instanz sein, die den Tunnel ablehnt. Die blockierende Stufe liegt irgendwo im Eintrittspfad, und die Firebox hat je nach VPN-Dienst mehr als einen Eintrittspfad. Arbeiten Sie die Prüfungen der Reihe nach ab und hören Sie auf, sobald eine davon die Ablehnung erklärt.

Prüfung 1: den eingehenden Dienst benennen

Bei Mobile VPN mit SSL, Access Portal und BOVPN über TLS ist der eingehende Eintritt die WatchGuard SSLVPN-Richtlinie. Wenden Sie die beabsichtigte Einschränkung dort an, auf dem tatsächlich konfigurierten Dienst, statt sie aus einer Benutzerzugriffsregel abzuleiten, die später greift.

IPsec nimmt einen anderen Pfad. Die integrierte IPSec-Richtlinie erlaubt externen IPsec-Verkehr zur Firebox für die zutreffenden Branch- und mobilen VPN-Dienste und hat Vorrang vor einer manuell erstellten IPSec-Richtlinie. Ist Ihr Client IKEv2, sind Sie auf diesem zweiten Pfad, und die SSLVPN-Richtlinie ist irrelevant.

Das hier falsch zu machen, ist der häufigste vergeudete Nachmittag in diesem Bereich: eine Richtlinie bearbeiten, die das Paket nie sieht, und dann schließen, dass die Einschränkung nicht funktioniert.

Prüfung 2: die Ablehnung lesen, nicht die Theorie

Führen Sie einen kontrollierten erlaubten Versuch durch und bringen Sie vier Dinge zusammen: die öffentliche Quelladresse des Clients, den getroffenen Eintrittsdienst, die passende Richtlinie und einen etwaigen Ablehnungsgrund im Protokoll. Die IKEv2-Fehlerbehebungsanleitung von WatchGuard weist darauf hin, dass Geolokalisierung und Standard-Paketbehandlung Verkehr noch vor der Zulassung durch die integrierte Richtlinie ablehnen können, was bedeutet, dass die Ablehnung, die Sie sehen, eine Stufe benennen kann, die Sie nicht bedacht haben.

Die Länderklassifizierung folgt der beobachteten Netzwerkquelle. Ein Roaming-Nutzer, ein vorgelagertes NAT oder ein anderer genehmigter Pfad können ändern, was die Firebox sieht, bestätigen Sie also die Adresse statt der Beschreibung des Nutzers, wo er sich befindet. Fragen Sie nach der öffentlichen Adresse, die der Client sieht, und vergleichen Sie sie mit der Quelle im Firebox-Protokoll. Weichen sie voneinander ab, folgt die Klassifizierung einem Pfad, den niemand erwähnt hat.

Prüfung 3: Ist die integrierte Richtlinie noch der Eigentümer?

Wenn eine manuelle IPSec-Richtlinie ignoriert zu werden scheint, prüfen Sie, ob die integrierte noch aktiviert ist. Eine manuelle Regel, die von einer integrierten Regel mit höherem Vorrang überlagert wird, und eine manuelle Regel, die die einzige Zulassung ist, sind verschiedene Konfigurationen mit gleich aussehender Oberfläche.

Entscheiden Sie, welche den Pfad besitzen soll. Ist es die manuelle Richtlinie, muss die integrierte für diesen Verkehr deaktiviert werden, und dort beginnt die nächste Prüfung.

Prüfung 4: den Ersatz planen, bevor Sie deaktivieren

Das Deaktivieren der integrierten IPSec-Richtlinie entfernt deren Zulassung für die betroffenen VPN-Dienste. Das schließt Branch-Tunnel ein, an die Sie vielleicht nicht denken, während Sie die Verbindung eines mobilen Nutzers reparieren.

Planen Sie zuerst den vollständigen Ersatz: welche Dienste eine Zulassung brauchen, welche Quellbereiche sie erhalten und wie Sie die Box verwalten, wenn die Änderung schiefgeht. Halten Sie einen unabhängigen Verwaltungs- und Wiederherstellungspfad offen, denn ein Fehler hier kann den Tunnel entfernen, den Sie zur Reparatur nutzen würden. Notieren Sie die Wiederherstellungsschritte im Änderungsdatensatz, einschließlich des Wegs zur Box, falls der VPN-Pfad weg ist. Testen Sie dann die Erneuerung, nicht nur die erste Verbindung.

Aktive Konnektivität und spätere Neuverhandlung können beide von der Zulassung abhängen. Eine Änderung, die für die getestete Sitzung funktioniert und beim nächsten Schlüsselwechsel scheitert, ist ein klassisches Ergebnis davon, die Zulassung zu ersetzen, ohne die Erneuerung zu testen.

Prüfung 5: Identität getrennt vom Standort halten

Geolokalisierung fügt einer Eintrittsentscheidung Kontext hinzu. Sie stellt nicht fest, wer der Nutzer ist, und sollte Gateway-Identitätsprüfungen, Kontoberechtigung oder MFA nicht ersetzen.

Wenn die geschäftliche Anforderung nur genehmigte Nutzer von genehmigten Orten ist, brauchen Sie beide Kontrollen. Eine Standortregel, die ein ganzes Land zulässt, ist kein Ersatz für Authentifizierung, und ein authentifizierter Nutzer in einem blockierten Land ist eine Richtlinienfrage, kein Fehler.

Prüfung 6: festhalten und beide Pfade verifizieren

Notieren Sie den Dienst, die Eintrittsrichtlinie, den beabsichtigten Standortbereich, die Ausnahmen und den Verantwortlichen für die Wiederherstellung. Testen Sie danach den mobilen Pfad und mindestens einen Standortpfad, damit die Einschränkung an den Dienst gebunden bleibt, für den sie gedacht ist.

Lesen Sie schließlich die Ablehnung noch einmal, mit der Sie begonnen haben. Hat sie sich von einer Standortablehnung zu einem Authentifizierungs- oder Berechtigungsfehler gewandelt, ist das Eintrittsproblem gelöst und ein anderes ist nun sichtbar. WatchGuard-Anleitung zu IKEv2-Ablehnungen ist die Referenz für die oben beschriebene Stufenreihenfolge.