Stabile VPN-Client-Adresse über RADIUS Framed-IP-Address

RADIUS kann mit einer Adresse für einen bestimmten Benutzer antworten; ob der Tunnel sie tatsächlich erhält, hängt vom Gateway ab. Genau in dieser Lücke zwischen zurückgegeben und beachtet scheitern die meisten Pläne für stabile Adressen. Ein Attribut in einer Testantwort beweist, dass der Server es senden kann, nicht dass der Fernzugriffsdienst es anwendet. Die folgende Reihenfolge prüft beide Hälften, bevor die Adresse in Firewallregeln landet.

Bestimmen Sie, welche Schicht die Adresse besitzt

Fernzugriffs-Gateways haben meist einen lokalen Pool, und viele können auch eine Adresse aus der Authentifizierungsantwort annehmen. Welche gewinnt, hängt von Plattform, Protokoll und Dienstkonfiguration ab, lesen Sie also die Vorrangregel für die genau verwendete Version. Wo der lokale Pool Vorrang hat, ist das Attribut reine Dekoration, und der Client landet trotzdem auf einer zufälligen Adresse. Halten Sie die Entscheidung schriftlich fest, einschließlich der Frage, ob ein zurückgegebener Wert innerhalb des Poolbereichs liegen muss oder außerhalb liegen darf.

RFC 2865 definiert Framed-IP-Address als die für den Benutzer zu konfigurierende Adresse und sagt nichts über die Bereitschaft eines bestimmten Gateways aus, sie zu beachten. Maßgeblich für den Vorrang ist die Herstellerdokumentation, nicht die Attributdefinition.

Senden Sie eine Testanfrage und lesen Sie die Antwort

Testen Sie den Server zuerst isoliert, damit ein fehlendes Attribut nicht für ein Gateway-Problem gehalten wird. radtest sendet eine Access-Request und gibt die zurückkommenden Attribute aus.

radtest alice 'S3cret' 127.0.0.1 0 testing123

Suchen Sie Framed-IP-Address in der Access-Accept und bestätigen Sie, dass der Wert der beabsichtigte ist und nicht eine Pooladresse aus einer Ausweichregel. Fehlt das Attribut, passen Benutzereintrag oder Autorisierungsrichtlinie nicht, und Gateway-Tuning kann nicht liefern, was der Server nie gesendet hat. Wiederholen Sie die Anfrage, während der Server im Debug-Modus läuft, wenn sich die Antwort schwer einer bestimmten Regel zuordnen lässt. Halten Sie das gemeinsame Geheimnis aus Shell-Verlauf und Tickets heraus, denn der Platzhalter oben ist kein Zugangsdatum.

Bestätigen Sie, dass das Gateway den Wert beachtet hat

Eine korrekte Antwort ist nur die Hälfte des Vertrags. Die Adresse, die auf der Tunnelschnittstelle erscheint, ist die Beobachtung, auf die es ankommt, und sie wird am Client gelesen statt aus der Gateway-Konfiguration abgeleitet.

ip -4 addr show tun0

Vergleichen Sie diese Adresse mit dem Attribut aus der Access-Accept. Eine Abweichung bedeutet, dass das Gateway den Wert ignoriert oder umgeschrieben hat, was die Vorrangfrage aus dem ersten Abschnitt erneut aufwirft. Verbinden Sie sich noch einmal, denn eine Reservierung, die nur beim ersten Versuch funktioniert, deutet meist auf eine veraltete Sitzung oder ein Lease hin, das die vorherige Verbindung noch hält. Notieren Sie Gateway-Version und Protokoll neben dem Ergebnis, damit die nächste Person erkennen kann, ob das Verhalten versionsspezifisch ist.

Planen Sie Nebenläufigkeit und Widerruf

Ein Benutzername auf zwei Geräten lässt sich nicht einer Adresse zuordnen, solange das Gateway die Sitzungen nicht durch etwas jenseits der Anmeldung unterscheidet. Entscheiden Sie, ob die Zuordnung zu einer Person, einem registrierten Gerät oder einer Zertifikatsidentität gehört, und machen Sie diese Wahl im Richtlinienspeicher ausdrücklich. Testen Sie einen zweiten gleichzeitigen Client und vergleichen Sie beide zugewiesenen Adressen, denn eine Kollision hier taucht später als Routingfehler wieder auf. Dieselbe Sorgfalt gehört in den Widerrufsplan, denn eine Adresse, die neu zugewiesen wird, während alte Firewallregeln noch darauf verweisen, wird zum Autorisierungsfehler.

Stabile Adressierung vereinfacht Regeln und Protokolle, beweist aber nie, wer ein Paket erzeugt hat. Authentifizierung und Zielautorisierung bleiben wichtig, wenn diese Adresse später zu einer anderen Sitzung wandert.