RRAS DHCP: uusi osoite vai vain kokoonpanovaihtoehdot?

DHCPACKin lukeminen kaappauksesta todisteena siitä, että VPN-asiakas sai osoitteensa DHCP:ltä, on virhe. Yleensä se todistaa vain, että johonkin DHCP-viestiin vastattiin. Windows RRAS voi jakaa istuntojen osoitteita omasta staattisesta poolistaan, kun taas DHCP toimittaa edelleen vaihtoehtoja yhdistetylle asiakkaalle. Pyynnön tyyppi kertoo, kumpi kahdesta tehtävästä oli käynnissä.

Kaksi tehtävää, jotka jakavat viestityypin

DHCP tekee kahta eri asiaa, ja ne jakavat viestityypit. Toinen on osoitteen ja vuokrauksen myöntäminen. Toinen on kokoonpanon toimittaminen isännälle, jolla on jo osoite, minkä RFC 2131 nimittää DHCPINFORMiksi. Vastaus toisessa tapauksessa sisältää vaihtoehdot eikä lainkaan vuokra-aikaa.

ACK on siis todiste vastauksesta, ei todiste myöntämisestä. Sitä edeltävä viesti ratkaisee, mikä kysymys esitettiin. Lue ensin pyyntörivi, ja jäljen loppuosa selittää yleensä itsensä.

Mistä RRAS saa osoitteen

RRAS omistaa VPN-osoitteen päätöksen määritetyn IPv4-myöntämismenetelmänsä kautta: joko DHCP-palvelimen tai staattisen osoitepoolin kautta. Kun pooli on staattinen, pooli on myöntäjä, eikä erillisen DHCP-palvelimen varauksella ole sananvaltaa siinä istunnossa. Molemmat mekanismit voivat olla samassa verkossa ilman, että toinen hallitsee toista.

Get-Command -Module RemoteAccess *IPAddress*

Selvitä voimassa oleva myöntämismenetelmä ennen osoitteen vianetsintää. Jos kyseessä on staattinen pooli, DHCP-alue on väärä paikka katsoa. Yllä oleva komento luettelee käyttämäsi version komennot, ja se riittää asetuksen löytämiseen.

Mitä käyttäjäluokka voi todistaa ja mitä ei

DHCP-käyttäjäluokka on merkkijono, jonka asiakas lähettää, ei todennettu ryhmäjäsenyys. Vaikka asiakas lähettäisi sellaisen ja palvelin soveltaisi siihen käytäntöä, tunniste todistaa vain, että merkkijono saapui. RFC 3004 sanoo suoraan, että vaihtoehto ei todista oikeutta luokkaan.

Älä odota, että VPN-käyttäjänimi, tietoturvaryhmän tunniste tai kannettavan Ethernet-osoite näkyisi pyynnössä käyttökelpoisessa muodossa. Ne ovat todennukseen ja hakemistoon liittyviä seikkoja, eikä DHCP-pyyntö kanna kumpaakaan. Jos vaatimuksena on erottaa valtuutetut henkilöt, toteuta se VPN-käytännössä, jossa identiteetti todella on. Juuri tämä erottelu pitää kaksi järjestelmää riippumattomina.

Vertaa todisteita, älä ACK:ta

Rakenna todisteketju sen sijaan, että lukisit yhden paketin. Kirjaa osoite, jonka istunto sai, pyynnön viestityyppi ja kentät, vaihtoehdot, jotka palvelin palautti, ja asiakkaan tosiasiallinen kokoonpano sen jälkeen. Jokainen lenkki vastaa eri kysymykseen, ja puuttuva lenkki on yleensä se, missä varsinainen vika on.

Get-DhcpServerv4OptionValue -ScopeId 10.90.0.0

Jos osoite tuli RRAS-poolista, DHCP-varaus ei selitä mitään. Jos vaihtoehdot saapuivat mutta asiakas jätti ne huomiotta, palvelin teki tehtävänsä ja seuraava pysähdys on asiakkaan kokoonpano. Vertaa noita kahta tulosta nimenomaisesti, niin ACK ei ole enää monitulkintainen. Kaksi jälkeä, yksi kummastakin myöntämismenetelmästä, ratkaisee kiistan nopeammin kuin mikään dokumentaatio.