Գրավման մեջ DHCPACK-ը կարդալ որպես ապացույց, որ VPN հաճախորդը հասցեն ստացել է DHCP-ից, սխալ է։ Սովորաբար դա ապացուցում է միայն, որ ինչ-որ DHCP հաղորդագրության պատասխանվել է։ Windows RRAS-ը կարող է սեսիայի հասցեներ բաժանել իր սեփական ստատիկ պահոցից, մինչ DHCP-ն դեռ ընտրանքներ է մատակարարում միացված հաճախորդին։ Հարցման տեսակը ձեզ ասում է, թե երկու աշխատանքներից որն էր ընթանում։

Երկու աշխատանք, որոնք կիսում են հաղորդագրության տեսակը

DHCP-ն անում է երկու առանձին բան, և նրանք կիսում են հաղորդագրության տեսակները։ Մեկը հասցե և վարձակալություն հատկացնելն է։ Մյուսը կազմաձևում հանձնելն է այն հոսթին, որն արդեն հասցե ունի, ինչը RFC 2131-ը կոչում է DHCPINFORM։ Երկրորդ դեպքում պատասխանը կրում է ընտրանքներ և ոչ մի վարձակալության ժամանակ։

Այսպիսով ACK-ը պատասխանի ապացույց է, ոչ թե հատկացման ապացույց։ Նրան նախորդած հաղորդագրությունն է որոշում, թե որ հարցն է տրվել։ Նախ կարդացեք հարցման տողը, և հետքի մնացած մասը սովորաբար ինքն իրեն բացատրում է։

Որտեղից է RRAS-ը վերցնում հասցեն

RRAS-ը տիրում է VPN հասցեի որոշմանը իր կազմաձևված IPv4 հատկացման մեթոդով՝ կա՛մ DHCP սերվեր, կա՛մ ստատիկ հասցեների պահոց։ Երբ պահոցը ստատիկ է, պահոցն է հատկացնողը, և առանձին DHCP սերվերի վրա արված ամրագրումը այդ սեսիայում խոսք չունի։ Երկու մեխանիզմները կարող են գոյակցել նույն ցանցում՝ առանց մեկի կողմից մյուսին կառավարելու։

Get-Command -Module RemoteAccess *IPAddress*

Նախ պարզեք գործող հատկացման մեթոդը, ապա զբաղվեք հասցեի խնդրով։ Եթե ստատիկ պահոց է, DHCP շրջանակը սխալ տեղ է նայելու համար։ Վերևի հրամանը թվարկում է ձեր գործարկած տարբերակում հասանելի cmdlet-ները, և դա բավական է կարգավորումը գտնելու համար։

Ինչ կարող է ապացուցել օգտվողի դասը և ինչ՝ ոչ

DHCP օգտվողի դասը տող է, որը ուղարկում է հաճախորդը, ոչ թե նույնականացված խմբի անդամակցություն։ Անգամ երբ հաճախորդն ուղարկում է մեկը, և սերվերը դրա վրա քաղաքականություն է կիրառում, պիտակը ապացուցում է միայն, որ տողը հասել է։ RFC 3004-ը հստակ ասում է, որ ընտրանքը չի նույնականացնում դասի իրավունքը։

Մի՛ սպասեք, որ VPN օգտանունը, անվտանգության խմբի նույնացուցիչը կամ նոթբուքի Ethernet հասցեն այդ հարցման մեջ կհայտնվեն օգտագործելի տեսքով։ Դրանք նույնականացման և գրացուցակի փաստեր են, և DHCP հարցումը ոչ մեկը չի կրում։ Եթե պահանջը լիազորված մարդկանց տարբերելն է, կիրառեք այն VPN քաղաքականության մեջ, որտեղ ինքնությունը իսկապես գոյություն ունի։ Հենց այդ բաժանումն է երկու համակարգերը անկախ պահում։

Համեմատեք ապացույցները, ոչ թե ACK-ը

Կառուցեք ապացույցների շղթան՝ փոխարենը մեկ փաթեթ կարդալու։ Գրանցեք այն հասցեն, որ ստացել է սեսիան, հարցման հաղորդագրության տեսակն ու դաշտերը, սերվերի վերադարձրած ընտրանքները և դրանից հետո հաճախորդի փաստացի կազմաձևումը։ Յուրաքանչյուր օղակ պատասխանում է այլ հարցի, և բացակայող օղակն այն տեղն է, որտեղ սովորաբար նստած է իսկական խափանումը։

Get-DhcpServerv4OptionValue -ScopeId 10.90.0.0

Եթե հասցեն եկել է RRAS պահոցից, DHCP ամրագրումը ոչինչ չի բացատրում։ Եթե ընտրանքները հասել են, բայց հաճախորդն անտեսել է դրանք, սերվերն արել է իր գործը, և հաջորդ կանգառը հաճախորդի կազմաձևումն է։ Համեմատեք այդ երկու արդյունքները բացահայտ, և ACK-ն դադարում է երկիմաստ լինելուց։ Երկու հետք՝ մեկը յուրաքանչյուր հատկացման մեթոդից, վեճը լուծում են ավելի արագ, քան ցանկացած փաստաթուղթ։

Առնչվող հոդվածներ