RRAS DHCP: új cím vagy csak konfigurációs beállítások?

Egy rögzítésben szereplő DHCPACK-et annak bizonyítékaként olvasni, hogy a VPN-kliens a DHCP-től kapta a címét, hiba. Általában csak azt bizonyítja, hogy valamelyik DHCP-üzenetre válasz érkezett. A Windows RRAS a saját statikus készletéből is oszthat ki munkamenet-címeket, miközben a DHCP továbbra is ellátja beállításokkal a csatlakozott klienst. A kérés típusa megmondja, melyik a két feladat zajlott.

Két feladat, amely ugyanazt az üzenettípust használja

A DHCP két külön dolgot tesz, és ezek közös üzenettípusokat használnak. Az egyik cím és bérlet kiosztása. A másik annak a gépnek a konfigurációval való ellátása, amelynek már van címe, amit az RFC 2131 DHCPINFORM-nak nevez. A válasz a második esetben beállításokat hordoz, és semmi bérleti időt nem tartalmaz.

Tehát az ACK egy válasz bizonyítéka, nem a kiosztásé. Az előtte érkező üzenet dönti el, melyik kérdés hangzott el. Először a kéréssort olvassa el, a nyom többi része általában magától megmagyarázza önmagát.

Honnan szerzi a címet a RRAS

A RRAS a beállított IPv4-hozzárendelési módszerén keresztül birtokolja a VPN-címről szóló döntést: vagy egy DHCP-kiszolgáló, vagy egy statikus címkészlet formájában. Ha a készlet statikus, a készlet a kiosztó, és egy külön DHCP-kiszolgálón lévő foglalásnak nincs beleszólása abba a munkamenetbe. A két mechanizmus ugyanazon a hálózaton is együtt létezhet anélkül, hogy bármelyik irányítaná a másikat.

Get-Command -Module RemoteAccess *IPAddress*

A cím hibakeresése előtt állapítsa meg az érvényes hozzárendelési módszert. Ha statikus készletről van szó, a DHCP-tartomány rossz hely a kereséshez. A fenti parancs felsorolja az Ön által futtatott verzióban elérhető parancsmagokat, és ez elegendő a beállítás megtalálásához.

Mit bizonyíthat egy felhasználói osztály, és mit nem

A DHCP felhasználói osztály egy karakterlánc, amelyet a kliens küld, nem hitelesített csoporttagság. Még ha a kliens küld is egyet, és a kiszolgáló szabályzatot illeszt rá, a címke csak azt bizonyítja, hogy a karakterlánc megérkezett. Az RFC 3004 kimondja, hogy a beállítás nem hitelesíti az osztályra való jogosultságot.

Ne várja, hogy egy VPN-felhasználónév, egy biztonsági csoport azonosítója vagy a laptop Ethernet-címe használható formában jelenik meg abban a kérésben. Ezek hitelesítési és címtár-tények, és a DHCP-kérés egyiket sem hordozza. Ha a követelmény a jogosult személyek megkülönböztetése, a VPN-szabályzatban érvényesítse, ahol az identitás valóban létezik. Ez a szétválasztás az oka annak, hogy a két rendszer független marad.

A bizonyítékokat hasonlítsa össze, ne az ACK-t

Építse fel a bizonyítékláncot ahelyett, hogy egyetlen csomagot olvasna. Jegyezze fel a munkamenet által kapott címet, a kérés üzenettípusát és mezőit, a kiszolgáló által visszaadott beállításokat, majd utána a kliens tényleges konfigurációját. Minden láncszem más kérdésre válaszol, és a hiányzó láncszem az, ahol a valódi hiba általában lapul.

Get-DhcpServerv4OptionValue -ScopeId 10.90.0.0

Ha a cím a RRAS készletéből jött, egy DHCP-foglalás semmit nem magyaráz. Ha a beállítások megérkeztek, de a kliens figyelmen kívül hagyta őket, a kiszolgáló végezte a dolgát, és a következő állomás a kliens konfigurációja. Hasonlítsa össze ezt a két eredményt kifejezetten, és az ACK megszűnik kétértelműnek lenni. Két nyom, egy-egy mindkét hozzárendelési módszerből, gyorsabban eldönti a vitát, mint bármilyen dokumentáció.