Číst DHCPACK v zachycené komunikaci jako důkaz, že klient VPN dostal adresu z DHCP, je chyba. Obvykle to dokazuje jen to, že na nějakou zprávu DHCP bylo odpovězeno. Windows RRAS může rozdávat adresy relace z vlastního statického fondu, zatímco DHCP stále dodává volby připojenému klientovi. Typ požadavku vám řekne, který z těch dvou úkolů probíhal.

Dva úkoly, které sdílejí typ zprávy

DHCP dělá dvě oddělené věci a obě sdílejí typy zpráv. Jedna je přidělení adresy a pronájmu. Druhá je doručení konfigurace hostiteli, který už adresu má, což RFC 2131 nazývá DHCPINFORM. Odpověď v druhém případě nese volby a žádnou dobu pronájmu.

ACK je tedy důkazem odpovědi, ne důkazem přidělení. Zpráva, která mu předcházela, rozhoduje o tom, jaká otázka byla položena. Přečtěte nejdřív řádek požadavku a zbytek stopy se obvykle vysvětlí sám.

Odkud RRAS bere adresu

RRAS vlastní rozhodnutí o adrese VPN prostřednictvím nakonfigurované metody přidělování IPv4: buď serveru DHCP, nebo statického fondu adres. Když je fond statický, je fond přidělujícím prvkem a rezervace na samostatném serveru DHCP do této relace nemluví. Oba mechanismy mohou na stejné síti existovat vedle sebe, aniž by jeden ovládal druhý.

Get-Command -Module RemoteAccess *IPAddress*

Než začnete hledat chybu v adrese, zjistěte platnou metodu přidělování. Pokud jde o statický fond, rozsah DHCP je špatné místo. Výše uvedený příkaz vypíše rutiny dostupné ve vaší verzi a to stačí k nalezení nastavení.

Co třída uživatele prokázat může a co ne

Třída uživatele DHCP je řetězec, který klient posílá, ne ověřené členství ve skupině. I když klient nějakou pošle a server na ni použije zásadu, štítek dokazuje jen to, že řetězec dorazil. RFC 3004 říká jasně, že volba neověřuje nárok na třídu.

Nečekejte, že se v tom požadavku objeví uživatelské jméno VPN, identifikátor bezpečnostní skupiny nebo ethernetová adresa notebooku v použitelné podobě. To jsou fakta o ověřování a o adresáři a požadavek DHCP nenese ani jedno. Pokud je požadavkem rozlišit oprávněné lidi, prosazujte to v zásadě VPN, kde identita skutečně existuje. Právě toto oddělení drží oba systémy nezávislé.

Porovnávejte důkazy, ne ACK

Sestavte řetězec důkazů, místo abyste četli jeden paket. Zapište adresu, kterou relace dostala, typ a pole požadavku, volby, které server vrátil, a skutečnou konfiguraci klienta potom. Každý článek odpovídá na jinou otázku a skutečná závada obvykle sedí v chybějícím článku.

Get-DhcpServerv4OptionValue -ScopeId 10.90.0.0

Pokud adresa přišla z fondu RRAS, rezervace DHCP nic nevysvětluje. Pokud volby dorazily, ale klient je ignoroval, server udělal svou práci a další zastávkou je konfigurace klienta. Porovnejte ty dva výsledky výslovně a ACK přestane být nejednoznačný. Dvě stopy, jedna z každé metody přidělování, uzavřou spor rychleji než jakákoli dokumentace.

Související články