VPN-Gerätezustandsprüfung blockiert nicht? Verfolgen Sie zuerst den Bericht

Wenn ein Laptop, dessen Antivirus-Signaturen vor Wochen aufgehört haben, sich zu aktualisieren, Ihre interne App weiterhin öffnen kann, ist selten das Richtliniendokument das, was falsch ist. Drei getrennte Systeme müssen übereinstimmen, bevor der Zugriff verweigert wird: Etwas misst den Endpunkt, etwas verwandelt diese Messung in ein Urteil „zulassen“ oder „ablehnen“, und etwas verwirft den Datenverkehr tatsächlich. Wenn ein nicht konformes Gerät trotzdem hineinkommt, fehlt genau eines dieser Glieder, oder es vertraut Belegen, denen es nicht vertrauen sollte. Die Prüfungen unten laufen in dieser Reihenfolge, und jede hat einen Haltepunkt.

Die Sperre ist der letzte Schritt, nicht der erste

Authentifizierung und Gerätezustand beantworten verschiedene Fragen. Eine erfolgreiche Anmeldung beweist, dass ein Berechtigungsnachweis vorgelegt wurde; sie sagt nichts über die Software auf dem Rechner, der ihn vorgelegt hat. Genau diese Lücke erlaubt es einem kopierten Clientprofil, eine gesund wirkende Sitzung auf einen ungesunden Host zu tragen.

Die Arbeit an der Endpunkt-Konformität hat für diese Kette bereits ein Vokabular. Das informative NEA-Referenzmodell in RFC 5209 teilt die Aufgabe in einen Sammler, einen Bewertungsschritt und einen Durchsetzungspunkt und sagt klar, dass ein Client, der über seinen eigenen Zustand lügt, außerhalb des Modells steht. Dieser Vorbehalt ist wichtiger als das Diagramm: Ein vertrauenswürdiges Plattformmodul macht aus einer selbst gemeldeten Messung keine Tatsache.

Halten Sie den Sammler beim Umfang ehrlich. Er sollte die Attribute melden, die Ihre Richtlinie nennt, auf dem Gerät, das Zugriff anfordert, und wenig sonst. Ein Inventar-Agent, der jedes installierte Paket auflistet, ist ein anderes Werkzeug als ein Zustandssammler, und der Unterschied ist zugleich ein Aufbewahrungs- und ein Genauigkeitsproblem. Lässt sich der Bericht nicht an eine Geräteidentität binden, rät der Bewerter, welche Maschine er gerade freigegeben hat.

Ein Dashboard mit rotem Status ist keine Kontrolle. Fragen Sie, was ein abgelehnter Nutzer noch erreichen kann: das Wiki, die Dateifreigabe, den Datenbankport? Die Behebung braucht eine schmale Oberfläche, und alles andere gehört hinter die Sperre.

Lesen Sie den Bericht, bevor Sie die Regel lesen

Beginnen Sie an der Quelle statt beim grünen Haken des Clients. Unter Windows kommt die lokale Messung von Defender oder von dem Produkt, das sich beim Security Center registriert hat, und beides ist ohne Herstellerkonsole lesbar:

Get-MpComputerStatus | Select-Object AMServiceEnabled, RealTimeProtectionEnabled, AntivirusSignatureLastUpdated
Get-CimInstance -Namespace root/SecurityCenter2 -ClassName AntiVirusProduct | Select-Object displayName, productState

Der zweite Befehl gibt eine Ganzzahl namens productState zurück. Ihre Bits sind locker dokumentiert, und Hersteller packen die Flags für Aktivierung und Aktualität unterschiedlich, also bestätigen Sie sie, statt sie zu parsen. Fremdprodukte hinterlassen nach der Deinstallation auch den Eintrag im Security Center, und der berichtet über Software, die nicht mehr auf der Platte liegt.

Das Alter ist das Feld, das Leute überspringen. Ein Signatur-Zeitstempel bedeutet nur etwas gegenüber der Uhr der Maschine, die die Bewertung vornimmt, also wandeln Sie ihn in ein Intervall um, statt ihn zu schätzen:

$sig = (Get-MpComputerStatus).AntivirusSignatureLastUpdated
[int](New-TimeSpan -Start $sig -End (Get-Date)).TotalHours

Jetzt hat die Richtlinie eine Zahl zu lesen. Sagt Ihre Regel 72 Stunden, ist das die Zahl, die sie verwendet, und ein Laptop, der eine Woche schläft, fällt durch, ohne dass jemand ein Etikett deutet. Notieren Sie die Schwelle neben dem Befehl, denn beide driften auseinander, wenn das Endpunkt-Werkzeug ersetzt wird.

Verwandeln Sie jeden Gerätezustand in ein schriftliches Urteil

Die meisten Streitigkeiten über den Zustand sind eigentlich Streitigkeiten über die unbekannte Zeile. Entscheiden Sie sie vor dem ersten Vorfall, in einer Tabelle, die Beleg, Urteil und Verantwortlichen nennt, damit niemand an der Gateway-Konsole improvisiert.

Die untere Zeile ist der Punkt, an dem sich Produkte unterscheiden. Manche Gateways weisen die Verbindung ab und erklären warum; andere lassen den Tunnel hochkommen und wenden eine eingeschränkte Richtlinie an; wenige fallen auf den letzten bekannten guten Bericht zurück. Nur die ersten beiden sind vertretbar, und es lohnt sich zu testen, welches Ihres tut.

Halten Sie Identität und Berechtigung ebenfalls in eigenen Spuren. Ein Laptop, der jeden Zustandstest besteht, braucht für die Anwendung trotzdem die richtige menschliche Autorisierung, und ein Gerätezertifikat beweist den Besitz eines Schlüssels, nicht den Zustand des Dateisystems. Die drei zu einem einzigen Boolean zu verschmelzen ist der Weg, auf dem ein Helpdesk-Konto dauerhaften Zugriff auf die Produktion bekommt.

Prüfen Sie den Durchsetzungspfad mit einer Anfrage, nicht mit einem Dashboard

Durchsetzung ist eine Eigenschaft einer Anfrage, also messen Sie sie mit einer. Setzen Sie eine nicht konforme Maschine in den Tunnel und machen Sie den Aufruf, den ein echter Nutzer machen würde:

curl -sS -o /dev/null -w '%{http_code}
' --max-time 5 https://app.internal.example/health

Ein 200 von einem Gerät, das blockiert werden müsste, bedeutet, dass die Entscheidung den Datenpfad nie erreicht hat. Zwei übliche Ursachen: Die Richtlinie hängt an einer Gruppe, der das Testkonto nie beigetreten ist, oder die Anwendung ist über eine Route erreichbar, die das VPN nicht besitzt.

Prüfen Sie zuerst die Routing-Annahme. Löst sich der interne Name zu einer Adresse auf, die der Client bereits über das lokale LAN erreicht, ist der Tunnel irrelevant, und keine Richtlinie wird greifen. Vergleichen Sie diese Adresse mit der Route, die das Gateway schiebt. Bei OpenVPN lebt die Richtlinie pro Client in Dateien, die nach dem Common Name benannt sind, also ist die Prüfung leicht:

ls /etc/openvpn/ccd/
cat /etc/openvpn/ccd/laptop-17

Eine Datei, die disable enthält, trennt diesen Client sofort, während eine Zeile push "route ..." verengt, was er erreichen kann. Beides ist Durchsetzung, und beides ist für jeden sichtbar, der den Bericht debuggt.

Testen Sie die vier Fälle an einem einzigen Testkonto

Die abschließende Prüfung ist eine kleine Matrix, kein Happy Path. Führen Sie ein Testkonto durch vier Zustände: aktuell, abgelaufene Signatur, Schutz deaktiviert, Agent nicht installiert. Notieren Sie für jeden das Urteil im Bewertungsprotokoll, den HTTP-Status, den die App zurückgibt, und ob die Behebungsseite geladen wurde.

foreach ($case in 'current', 'stale', 'disabled', 'absent') {
  Get-MpComputerStatus | Select-Object AMServiceEnabled, AntivirusSignatureLastUpdated
  curl.exe -sS -o NUL -w "%{http_code}
" --max-time 5 https://app.internal.example/health
}

Zwei Details sind leicht zu übersehen. Zuerst die Wiederholung: Ein Bericht, der aufgenommen wurde, als die Maschine gesund war, darf für eine spätere Sitzung auf demselben Gerät nicht akzeptiert werden, also suchen Sie nach einem Zeitstempel, der an die aktuelle Verbindung gebunden ist. Dann die Entfernung: Das Deinstallieren des Agenten sollte dieselbe Ablehnung erzeugen wie ein veralteter Bericht, keinen sauberen Durchlauf, und genau dieser Fall wird am häufigsten nie getestet.

Wenn die Matrix zur Tabelle passt, übergeben Sie drei Dinge an denjenigen, der das Gateway als Nächstes betreibt: die Befehle, die Schwelle und die vier erwarteten Ergebnisse. Diese Übergabe ist das eigentliche Ergebnis, denn ein Zustandsdesign, das nur in einem Richtliniendokument lebt, driftet beim ersten Mal, wenn das Endpunkt-Werkzeug sein Berichtsfeld ändert.