RRAS-DHCP: neue Adresse oder nur Konfigurationsoptionen?

Ein DHCPACK in einem Mitschnitt als Beweis zu lesen, dass der VPN-Client seine Adresse von DHCP erhalten hat, ist ein Fehler. Meist beweist er nur, dass irgendeine DHCP-Nachricht beantwortet wurde. Windows RRAS kann Sitzungsadressen aus seinem eigenen statischen Pool vergeben, während DHCP dem verbundenen Client weiterhin Optionen liefert. Der Anfragetyp sagt Ihnen, welche der beiden Aufgaben gerade lief.

Zwei Aufgaben, die sich einen Nachrichtentyp teilen

DHCP erledigt zwei getrennte Dinge, und sie teilen sich Nachrichtentypen. Das eine ist die Zuweisung einer Adresse und einer Lease. Das andere ist die Zustellung von Konfiguration an einen Host, der bereits eine Adresse hat, was RFC 2131 DHCPINFORM nennt. Die Antwort im zweiten Fall trägt Optionen und keine Leasezeit.

Ein ACK ist also ein Beweis für eine Antwort, nicht für eine Zuweisung. Die Nachricht davor entscheidet, welche Frage gestellt wurde. Lesen Sie zuerst die Anforderungszeile, und der Rest des Mitschnitts erklärt sich meist von selbst.

Woher RRAS die Adresse bezieht

RRAS besitzt die Entscheidung über die VPN-Adresse durch seine konfigurierte IPv4-Zuweisungsmethode: entweder einen DHCP-Server oder einen statischen Adresspool. Ist der Pool statisch, ist der Pool der Zuteiler, und eine Reservierung auf einem separaten DHCP-Server hat in dieser Sitzung nichts zu sagen. Beide Mechanismen können im selben Netz koexistieren, ohne dass einer den anderen steuert.

Get-Command -Module RemoteAccess *IPAddress*

Ermitteln Sie die geltende Zuweisungsmethode, bevor Sie die Adresse debuggen. Ist es ein statischer Pool, ist der DHCP-Bereich die falsche Stelle. Der Befehl oben listet die Cmdlets auf, die in Ihrer Version verfügbar sind, und das genügt, um die Einstellung zu finden.

Was eine Benutzerklasse beweisen kann und was nicht

Eine DHCP-Benutzerklasse ist eine Zeichenkette, die der Client sendet, keine authentifizierte Gruppenmitgliedschaft. Selbst wenn ein Client eine sendet und der Server eine Richtlinie darauf anwendet, beweist das Etikett nur, dass die Zeichenkette ankam. RFC 3004 sagt deutlich, dass die Option den Anspruch auf die Klasse nicht authentifiziert.

Erwarten Sie nicht, dass ein VPN-Benutzername, eine Kennung einer Sicherheitsgruppe oder die Ethernet-Adresse des Laptops in dieser Anforderung in brauchbarer Form auftaucht. Das sind Authentifizierungs- und Verzeichnisfakten, und die DHCP-Anforderung trägt keines von beiden. Wenn die Anforderung lautet, berechtigte Personen zu unterscheiden, setzen Sie das in der VPN-Richtlinie durch, wo die Identität tatsächlich existiert. Genau diese Trennung hält beide Systeme unabhängig.

Vergleichen Sie die Belege, nicht das ACK

Bauen Sie die Beweiskette auf, statt ein einzelnes Paket zu lesen. Notieren Sie die Adresse, die die Sitzung erhielt, Nachrichtentyp und Felder der Anforderung, die Optionen, die der Server zurückgab, und danach die tatsächliche Konfiguration des Clients. Jedes Glied beantwortet eine andere Frage, und das fehlende Glied ist die Stelle, an der der echte Fehler meist sitzt.

Get-DhcpServerv4OptionValue -ScopeId 10.90.0.0

Kam die Adresse aus dem RRAS-Pool, erklärt eine DHCP-Reservierung nichts. Kamen die Optionen an, aber der Client ignorierte sie, hat der Server seine Arbeit getan, und die Clientkonfiguration ist der nächste Halt. Vergleichen Sie diese beiden Ergebnisse ausdrücklich, und das ACK ist nicht mehr mehrdeutig. Zwei Mitschnitte, einer je Zuweisungsmethode, entscheiden den Streit schneller als jede Dokumentation.