RRAS DHCP: નવું સરનામું કે ફક્ત રૂપરેખાંકન વિકલ્પો?

કેપ્ચરમાં DHCPACK ને એ સાબિતી તરીકે વાંચવું કે VPN ક્લાયન્ટને તેનું સરનામું DHCP તરફથી મળ્યું, તે ભૂલ છે. સામાન્ય રીતે તે ફક્ત એ સાબિત કરે છે કે કોઈ DHCP સંદેશનો જવાબ આપવામાં આવ્યો. Windows RRAS પોતાના સ્થિર પૂલમાંથી સત્રના સરનામાં આપી શકે છે જ્યારે DHCP હજી પણ જોડાયેલા ક્લાયન્ટને વિકલ્પો પૂરા પાડે છે. વિનંતીનો પ્રકાર તમને કહે છે કે બેમાંથી કયું કામ ચાલી રહ્યું હતું.

એક જ સંદેશ-પ્રકાર વહેંચતા બે કામ

DHCP બે અલગ વસ્તુઓ કરે છે, અને તે સંદેશ-પ્રકારો વહેંચે છે. એક છે સરનામું અને લીઝ ફાળવવી. બીજું છે એ હોસ્ટને રૂપરેખાંકન પહોંચાડવું જેની પાસે પહેલેથી સરનામું છે, જેને RFC 2131 DHCPINFORM કહે છે. બીજા કિસ્સામાં જવાબ વિકલ્પો ધરાવે છે અને કોઈ લીઝ સમય ધરાવતો નથી.

તેથી ACK જવાબની સાબિતી છે, ફાળવણીની સાબિતી નહીં. તેની પહેલાં આવેલો સંદેશ નક્કી કરે છે કે કયો પ્રશ્ન પૂછવામાં આવ્યો. પહેલાં વિનંતી-લાઈન વાંચો અને બાકીની ટ્રેસ સામાન્ય રીતે પોતાની જાતને સમજાવે છે.

RRAS ને સરનામું ક્યાંથી મળે છે

RRAS પોતાની રૂપરેખાંકિત IPv4 ફાળવણી પદ્ધતિ દ્વારા VPN સરનામાના નિર્ણયનો માલિક છે: કાં તો DHCP સર્વર કાં તો સ્થિર સરનામા પૂલ. જ્યારે પૂલ સ્થિર હોય, ત્યારે પૂલ જ ફાળવનાર છે, અને અલગ DHCP સર્વર પરની આરક્ષણનો તે સત્રમાં કોઈ શબ્દ નથી. બંને પદ્ધતિઓ એક જ નેટવર્ક પર સહઅસ્તિત્વ ધરાવી શકે છે, એક પણ બીજાને નિયંત્રિત કર્યા વિના.

Get-Command -Module RemoteAccess *IPAddress*

સરનામાને ડિબગ કરતાં પહેલાં અમલમાં રહેલી ફાળવણી પદ્ધતિ શોધો. જો તે સ્થિર પૂલ હોય, તો DHCP સ્કોપ જોવા માટે ખોટી જગ્યા છે. ઉપરનો આદેશ તમે ચલાવો છો તે આવૃત્તિ પર ઉપલબ્ધ cmdlets ની સૂચિ આપે છે, અને સેટિંગ શોધવા માટે એ પૂરતું છે.

વપરાશકર્તા વર્ગ શું સાબિત કરી શકે અને શું નહીં

DHCP વપરાશકર્તા વર્ગ એ ક્લાયન્ટ મોકલે છે તે શબ્દમાળા છે, પ્રમાણિત જૂથ સભ્યપદ નહીં. ક્લાયન્ટ એક મોકલે અને સર્વર તેના પર નીતિ લાગુ કરે તોપણ, લેબલ ફક્ત એ સાબિત કરે છે કે શબ્દમાળા પહોંચી. RFC 3004 સ્પષ્ટ કહે છે કે આ વિકલ્પ વર્ગ પરનો હક પ્રમાણિત કરતો નથી.

VPN વપરાશકર્તાનામ, સુરક્ષા-જૂથ ઓળખકર્તા અથવા લેપટોપનું Ethernet સરનામું તે વિનંતીમાં વાપરી શકાય તેવા સ્વરૂપમાં દેખાશે એવી અપેક્ષા રાખશો નહીં. તે પ્રમાણીકરણ અને ડિરેક્ટરીની હકીકતો છે, અને DHCP વિનંતી બંનેમાંથી એક પણ ધરાવતી નથી. જો જરૂરિયાત અધિકૃત લોકોને અલગ પાડવાની હોય, તો તે VPN નીતિમાં લાગુ કરો જ્યાં ઓળખ ખરેખર અસ્તિત્વ ધરાવે છે. એ જ વિભાજન બે સિસ્ટમને સ્વતંત્ર રાખે છે.

ACK નહીં, પુરાવાઓની સરખામણી કરો

એક પેકેટ વાંચવાને બદલે પુરાવાની સાંકળ બનાવો. સત્રને મળેલું સરનામું, વિનંતીનો સંદેશ-પ્રકાર અને ક્ષેત્રો, સર્વરે પરત કરેલા વિકલ્પો અને પછી ક્લાયન્ટનું વાસ્તવિક રૂપરેખાંકન નોંધો. દરેક કડી અલગ પ્રશ્નનો જવાબ આપે છે, અને ખૂટતી કડી એ છે જ્યાં સાચી ખામી સામાન્ય રીતે બેસે છે.

Get-DhcpServerv4OptionValue -ScopeId 10.90.0.0

જો સરનામું RRAS પૂલમાંથી આવ્યું હોય, તો DHCP આરક્ષણ કંઈ સમજાવતું નથી. જો વિકલ્પો આવ્યા પણ ક્લાયન્ટે તેમને અવગણ્યા, તો સર્વરે પોતાનું કામ કર્યું અને હવે પછીનું સ્ટેશન ક્લાયન્ટ રૂપરેખાંકન છે. આ બે પરિણામોની સ્પષ્ટ સરખામણી કરો અને ACK અસ્પષ્ટ રહેવાનું બંધ કરે છે. બે ટ્રેસ, દરેક ફાળવણી પદ્ધતિમાંથી એક, કોઈ પણ દસ્તાવેજ કરતાં ઝડપથી વિવાદ નક્કી કરે છે.