RRAS DHCP: jauna adrese vai tikai konfigurācijas opcijas?
ACK VPN izsekojumā pierāda atbildi, nevis piešķīrumu. Adresi var pārvaldīt RRAS, kamēr DHCP tikai piegādā opcijas pievienotajam klientam.
Lasīt DHCPACK uztveršanas failā kā pierādījumu, ka VPN klients saņēma adresi no DHCP, ir kļūda. Parasti tas pierāda tikai to, ka uz kādu DHCP ziņojumu ir atbildēts. Windows RRAS var izdalīt sesijas adreses no sava statiskā kopuma, kamēr DHCP joprojām piegādā opcijas pievienotajam klientam. Pieprasījuma veids pasaka, kurš no diviem darbiem notika.
Divi darbi, kas dala ziņojuma veidu
DHCP dara divas atšķirīgas lietas, un tās dala ziņojumu veidus. Viens ir adreses un nomes piešķiršana. Otrs ir konfigurācijas piegāde saimniekam, kuram jau ir adrese, ko RFC 2131 sauc par DHCPINFORM. Atbilde otrajā gadījumā satur opcijas un nesatur nomas laiku.
Tātad ACK ir atbildes pierādījums, nevis piešķīruma pierādījums. Ziņojums pirms tā izlemj, kurš jautājums tika uzdots. Vispirms izlasiet pieprasījuma rindu, un pārējais izsekojums parasti izskaidro pats sevi.
No kurienes RRAS iegūst adresi
RRAS pārvalda VPN adreses lēmumu ar savu konfigurēto IPv4 piešķiršanas metodi: vai nu DHCP serveri, vai statisku adrešu kopumu. Kad kopums ir statisks, kopums ir piešķīrējs, un rezervācijai atsevišķā DHCP serverī šajā sesijā nav teikšanas. Abi mehānismi var pastāvēt vienā tīklā, nevienam nekontrolējot otru.
Get-Command -Module RemoteAccess *IPAddress*Pirms adreses problēmu meklēšanas noskaidrojiet spēkā esošo piešķiršanas metodi. Ja tas ir statisks kopums, DHCP tvērums ir nepareizā vieta, kur skatīties. Iepriekš dotā komanda uzskaita jūsu versijā pieejamos cmdlet, un ar to pietiek iestatījuma atrašanai.
Ko lietotāja klase var pierādīt un ko ne
DHCP lietotāja klase ir virkne, ko klients sūta, nevis autentificēta grupas piederība. Pat ja klients to sūta un serveris pēc tās piemēro politiku, etiķete pierāda tikai to, ka virkne ir pienākusi. RFC 3004 skaidri saka, ka opcija neautentificē tiesības uz klasi.
Negaidiet, ka VPN lietotājvārds, drošības grupas identifikators vai klēpjdatora Ethernet adrese šajā pieprasījumā parādīsies lietojamā formā. Tie ir autentifikācijas un direktorija fakti, un DHCP pieprasījums nenes nevienu no tiem. Ja prasība ir atšķirt pilnvarotas personas, īstenojiet to VPN politikā, kur identitāte patiešām pastāv. Tieši šī atdalīšana notur abas sistēmas neatkarīgas.
Salīdziniet pierādījumus, nevis ACK
Veidojiet pierādījumu ķēdi, nevis lasiet vienu paketi. Pierakstiet adresi, ko saņēma sesija, pieprasījuma ziņojuma veidu un laukus, servera atgrieztās opcijas un pēc tam faktisko klienta konfigurāciju. Katrs posms atbild uz citu jautājumu, un trūkstošais posms parasti ir vieta, kur slēpjas īstā kļūda.
Get-DhcpServerv4OptionValue -ScopeId 10.90.0.0Ja adrese nāca no RRAS kopuma, DHCP rezervācija neko neizskaidro. Ja opcijas pienāca, bet klients tās ignorēja, serveris izdarīja savu darbu, un nākamā pietura ir klienta konfigurācija. Skaidri salīdziniet šos divus rezultātus, un ACK vairs nav divdomīgs. Divi izsekojumi, pa vienam no katras piešķiršanas metodes, izšķir strīdu ātrāk nekā jebkura dokumentācija.