GVC Acquiring IP પર અટકી ગયું છે: આ પાસવર્ડની સમસ્યા નથી

Global VPN Client Acquiring IP પર અટકી જાય છે, અને પહેલી પ્રતિક્રિયા પાસવર્ડ ફરી લખવાની અથવા ક્લાયન્ટ ફરી ઇન્સ્ટોલ કરવાની હોય છે. બંમાંથી કોઈ પણ જે તબક્કો નિષ્ફળ ગયો તેને અડતું નથી. ક્લાયન્ટે સરનામું માંગ્યું તે પહેલાં જ પ્રમાણીકરણ પૂરું થઈ ગયું હતું, તેથી તમને એ લાઇન પર રોકતું ઓળખપત્ર નથી. તમને ત્યાં રોકતું અધૂરું રહેલું DHCP વિનિમય છે, અને તે ત્રણ જુદી જગ્યાએ અટકી શકે છે.

પ્રમાણીકરણ અને સરનામા ફાળવણી અલગ તબક્કા છે

GVC પહેલા સાબિત કરે છે કે તમે કોણ છો, પછી તમારા કનેક્શનને ફાળવેલી નીતિ અનુસાર તેના વર્ચ્યુઅલ એડેપ્ટર માટે સેટિંગ્સ માંગે છે. આ જુદા જુદા નિષ્ફળતાના સંકેતો ધરાવતા ક્રમિક પગલાં છે. ખોટા ઓળખપત્ર સામાન્ય રીતે વહેલા નિષ્ફળ જાય છે, સરનામાની લાઇનને બદલે પ્રમાણીકરણ કે વાટાઘાટનો સંદેશ સાથે.

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

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

લીઝ ખરેખર ક્યાંથી આવે છે

બે મોડેલ સામાન્ય છે. ફાયરવોલ પોતે VPN ક્લાયન્ટ માટે DHCP શ્રેણી ચલાવી શકે છે, અથવા વિનંતીને આંતરિક નેટવર્ક પરના બાહ્ય DHCP સર્વર પર મોકલી શકે છે. મોડેલ નક્કી કરે છે કે કયા લોગ મહત્ત્વના છે અને કોને કૉલ કરવો.

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

કંઈ પણ પરીક્ષણ કરતા પહેલાં લખો કે તમારું ડિપ્લોયમેન્ટ કયું મોડેલ વાપરે છે. ઑનલાઇન વિરોધાભાસી સલાહમાંથી અડધી બીજાને ધારી લે છે.

ટનલ ચાલુ હોઈ શકે અને તોપણ લીઝ ગુમાવી શકે

સ્થાપિત કંટ્રોલ કનેક્શન સાબિત કરે છે કે વાટાઘાટ કામ કર્યું, એ નહીં કે ટનલના ડેટા બંને દિશામાં પસાર થાય છે. DHCP વિનિમયને ડેટા માર્ગ પાર કરવા માટે વિનંતી અને જવાબ જોઈએ, અને ત્યાં જ એન્ક્રિપ્શન સેટિંગ્સ, VPN ઝોનની નીતિ અને MTU સમસ્યાઓ રહે છે.

NAT traversal અંગેની સલાહ સંદર્ભના મહત્ત્વનું સૌથી સ્પષ્ટ ઉદાહરણ છે. કેટલાક માર્ગોને તે ચાલુ જોઈએ, બીજા ફક્ત બંધ હોય ત્યારે કામ કરે, અને વચ્ચેનું NAT તથા વાટાઘાટ કરેલું કનેક્શન નક્કી કરે છે કયું. ક્લાયન્ટ સેટિંગ્સ પણ બદલતી વખતે તેને આંધળા બદલવાનો અર્થ એ છે કે કયા ફેરફારે પરિણામ આપ્યું તે તમને ખબર નહીં પડે. એન્કેપ્સ્યુલેશન બદલતા પહેલાં વાટાઘાટ કરેલો માર્ગ અને પુરાવા નોંધો.

ઘરના રાઉટરને ફરી ચાલુ કરવું એ જ શ્રેણીમાં આવે છે. તે ક્યારેક લક્ષણ દૂર કરે છે, પણ લીઝ કેમ નિષ્ફળ ગઈ તે ઓળખતું નથી, અને સમસ્યા આગલા કનેક્શન પર પાછી આવે છે.

લીઝનો માર્ગ ક્રમમાં ચાલો

એડેપ્ટરથી શરૂ કરો અને બહાર તરફ જાઓ, જેથી દરેક પગલું ફક્ત એક કારણથી નિષ્ફળ જઈ શકે:

> Get-NetAdapter | Where-Object Name -like "*GVC*"
> ipconfig /all | findstr /i /c:"GVC" /c:"IPv4" /c:"DHCP"
> Test-NetConnection 10.60.0.1 -Port 443

169.254.x.x જેવું સરનામું એટલે એડેપ્ટર અસ્તિત્વમાં છે અને તેને કોઈ જ જવાબ મળ્યો નથી, જે લીઝના સ્રોત કે ડેટા માર્ગ તરફ ઇશારો કરે છે. VPN શ્રેણીમાં સાચું સરનામું પણ ખોટી DNS એન્ટ્રીઓ સાથે હોય તો તે બીજી ખામી છે: લીઝ કામ કરી ગઈ અને નીતિએ અપૂર્ણ સેટિંગ્સ આપી. જે એડેપ્ટર ક્યારેય દેખાતું નથી તેનો અર્થ ક્લાયન્ટ તેને બનાવવા સુધી પહોંચ્યો નથી.

લીઝ દેખાય કે તરત સરનામાની લાઇન પર વિજય જાહેર કરવાને બદલે વાસ્તવિક સંસાધન અજમાવો. જો ફાઇલ કે ઇન્ટ્રાનેટ ઍક્સેસ હજી પણ નિષ્ફળ જાય, તો સફળ લીઝને પુરાવા તરીકે રાખો અને નામ ઉકેલવા કે નીતિ તરફ આગળ વધો, કારણ કે તમે મૂળ ખામી પાછળ છોડી દીધી છે.

વર્ચ્યુઅલ એડેપ્ટર વિશે SonicWallની નોંધ તેમાં કેટલીક અલગ શાખાઓની યાદી છે, અને તેના જૂના સ્ક્રીનશોટને વર્તમાન મેનુ નકશા તરીકે વાંચવા જોઈએ નહીં. તમે પહોંચેલા તબક્કાની પુષ્ટિ કરવા તેનો ઉપયોગ કરો, સંપૂર્ણ રીતે લાગુ કરવાની ચેકલિસ્ટ તરીકે નહીં.