Warum eine RADIUS-VLAN-Antwort für einen VPN-Benutzer nichts bewirkt

Sie fügen das VLAN-Attribut zur NPS-Richtlinie hinzu, der VPN-Benutzer verbindet sich, und der Laptop landet weiterhin im Standardpool. Der RADIUS-Server gibt zurück, was Sie angefordert haben, weshalb der Fehler wie ein Cache-Problem aussieht. Meist ist er keines. Ein Access-Accept trägt Autorisierungshinweise, und nur der Netzwerkzugriffsserver, der sie empfangen hat, kann einen davon in eine Netzzuweisung umwandeln.

Beginnen Sie beim Gateway, nicht bei der Richtlinie

Gehen Sie die Kette vom Client nach innen, bevor Sie etwas ändern. Der Client bittet das Gateway um eine Sitzung, das Gateway fragt RADIUS, ob der Benutzer eine erhalten darf, und RADIUS antwortet mit einem Ergebnis und einer Reihe von Attributen. Danach wendet das Gateway an, was es anzuwenden versteht.

Ihr Durchlauf beginnt bei Schritt vier, deshalb wirken die ersten drei gesund. Nichts im Austausch verpflichtet das Gateway, ein empfangenes Attribut umzusetzen. Die Antwort ist eine Anfrage an das Gateway, keine Tatsache über den Client.

Was der Switch kann, was das VPN nicht kann

Ein 802.1X-Zugangsswitch ist ein Authentifikator mit Ports, und die dynamische VLAN-Zuweisung verschiebt einen dieser Ports in ein VLAN, das der Switch bereits führt. Die RADIUS-Tunnelattribute beschreiben diese Absicht in einer Form, die der Switch versteht. Ein geroutetes VPN beendet Tunnel, nicht Switch-Ports, und seine Clients erhalten meist eine Adresse und eine Route statt der Mitgliedschaft in einer Broadcast-Domäne. Es gibt keinen Port zu verschieben, also hat dasselbe Attribut nichts, worauf es wirken könnte.

Das ist ein Modellunterschied, kein Herstellerfehler. Manche Gateways fügen eine eigene Gruppenrichtlinie, Poolauswahl oder einen Filtermechanismus hinzu, der auf einem Screenshot ähnlich aussieht. Andere setzen nichts davon um, und das Attribut wird protokolliert und ignoriert. Lesen Sie die Dokumentation für den Fernzugriffsmodus, den Sie tatsächlich aktiviert haben, nicht für den auf dem Screenshot.

Lesen Sie die Antwort, die der Server tatsächlich gesendet hat

Bestätigen Sie, was RADIUS zurückgegeben hat, statt was der Richtlinieneditor anzeigt. Eine Testanfrage mit demselben Benutzernamen und einem bekannten Kennwort druckt die Antwortattribute in lesbarer Form aus, was die Frage in einem Schritt klärt.

radtest alice secret 10.0.0.10 0 testing123

Fehlen die VLAN-Attribute in dieser Antwort, korrigieren Sie zuerst die Richtlinienübereinstimmung. Sind sie vorhanden, hat der Server seinen Teil getan, und die Lücke liegt weiter hinten.

Beweisen Sie zuerst die Sitzungsrichtlinie, dann die Erreichbarkeit

Sehen Sie sich nun die Sitzung an, die das Gateway aufgebaut hat. Die Liste der aktiven Sitzungen zeigt den Pool, die zugewiesene Adresse und jede Gruppenrichtlinie, die das Gateway angehängt hat, und das ist der einzige Beweis, der für die Durchsetzung zählt. Vergleichen Sie das mit dem, was der Benutzer erreichen kann, nicht mit dem, was die Richtlinie beabsichtigte.

swanctl --list-sas

Testen Sie dann vom Client eine erlaubte und eine verweigerte Ressource, denn eine Adresse aus dem richtigen Pool beweist keine Isolation. Hat das Gateway keinen Mechanismus für die gewünschte Zuweisung, erzeugen weitere Kopien des Attributs keinen. Eine Adresse aus dem erwarteten Pool kann neben vollständigem Zugriff auf jeden anderen Pool bestehen. Wählen Sie einen unterstützten Richtlinienmechanismus oder ändern Sie das Netzwerkdesign bewusst.