Windows માં VPN ભૂલ 720: સરનામું પૂલ કે ક્લાયન્ટ બાઇન્ડિંગ?
ભૂલ 720 નો અર્થ છે કે કનેક્શનને ક્યારેય વપરાયોગ્ય સરનામું મળ્યું નથી. એડેપ્ટર ફરીથી ઇન્સ્ટોલ કરતા પહેલાં એક હોસ્ટની નિષ્ફળતાઓને ઘણા હોસ્ટની નિષ્ફળતાઓથી અલગ કરો.
ભૂલ 720 ઓળખપત્રો સ્વીકારાયા પછી દેખાય છે, તેથી તે લોકોને પાસવર્ડ ક્ષેત્ર પર પાછા મોકલે છે. કનેક્શન તે બિંદુ સુધી પહોંચ્યું જ્યાં સરનામા પર વાટાઘાટ થાય છે અને તેને કોઈ સરનામું મળ્યું નહીં. બે સંપૂર્ણ અલગ નિષ્ફળતાઓ એ જ સંવાદ બનાવે છે: સર્વર પાસે વહેંચવા માટે કંઈ નહોતું, અથવા આ જ ક્લાયન્ટ વાટાઘાટ પૂરી કરી શક્યો નહીં. કંઈપણ સ્પર્શતા પહેલાં આ બેને અલગ કરવું એ સમારકામનો મોટો ભાગ છે, અને આ તફાવત Microsoft ના ભૂલ 720 સમસ્યા-નિવારણ પૃષ્ઠ પર દસ્તાવેજીકૃત છે.
સંવાદ શું નથી કહેતો
સંદેશ PPP વાટાઘાટમાં નિષ્ફળતા વર્ણવે છે, અને તે જાણી જોઈને અસ્પષ્ટ છે કારણ કે ક્લાયન્ટ જોઈ શકતો નથી કે સર્વરે કેમ ઇનકાર કર્યો. આ ઓળખપત્રોની ભૂલ નથી અને ટનલના એન્ક્રિપ્શન વિશેનું નિવેદન નથી. તેનો અર્થ છે કે સરનામું અથવા વાટાઘાટના પરિમાણો પહોંચાડ્યા નહોતા.
સર્વરની બાજુ સામાન્ય કારણ ફાળવણી છે: ખાલી સરનામાં વિનાનું સ્થિર RRAS પૂલ, અથવા એવું DHCP રૂપરેખાંકન જેની શ્રેણી સમાપ્ત અથવા અગમ્ય હોય, પ્રયત્ન કરતા દરેક ક્લાયન્ટમાં બરાબર આ લક્ષણ ઉત્પન્ન કરે છે. ક્લાયન્ટની બાજુ સામાન્ય કારણ બાઇન્ડિંગ છે. PPP વહન કરતું WAN Miniport યોગ્ય ઘટકો સાથે બાંધવું પડે છે, અને અક્ષમ બાઇન્ડિંગ અથવા દાખલ કરેલું નેટવર્ક ફિલ્ટર કોઈ દેખાતી ઉપકરણ સમસ્યા વિના વાટાઘાટ રોકી શકે છે. બંને પરિવારોને અલગ પુરાવા જોઈએ છે, અને તેમની વચ્ચે પસંદ કરવાનો સૌથી ઝડપી રસ્તો એ ગણવું છે કે કેટલા ક્લાયન્ટ પ્રભાવિત છે.
પહેલાં વસ્તી અલગ કરો, પછી પૂલ
કોઈપણ રૂપરેખાંકન વાંચતા પહેલાં પ્રભાવિત ક્લાયન્ટ ગણો. એકસાથે બધાને લાગતી નિષ્ફળતા સર્વરની સ્થિતિ છે, અને એક મશીનનો નેટવર્કો વચ્ચે પીછો કરતી નિષ્ફળતા ક્લાયન્ટની સ્થિતિ છે. આ ગણતરી ચેટ ચેનલમાં એક સંદેશાના ભાવે થાય છે અને એક બપોર બચાવે છે.
| Artifact | How you get it | What it rules out | What it cannot rule out |
|---|---|---|---|
| Affected-client count | One message to the people who failed, or a search of today's tickets | A client-only fault, when every client failed within minutes | Which server-side component stopped allocating |
| RRAS event for one attempt | Get-WinEvent on the System log, filtered to the allocation event id | An allocation failure, when no event matches that attempt | A binding fault that appears later in the same negotiation |
| Hidden WAN Miniport bindings | Get-NetAdapter with hidden adapters, then the binding list on the returned name | A disabled ms_wanarp binding or an inserted filter on this client | Pool exhaustion that would also have hit other clients |
| Free-address count | The RRAS pool view, or the DHCP scope statistics | A committed static range or an exhausted scope | Why the address was not delivered to one specific client |
પછી એક અસફળ પ્રયત્નને સર્વરના પોતાના રેકોર્ડ સાથે સાંકળો, કારણ કે RRAS ફાળવી ન શકે ત્યારે ઘટના નોંધે છે અને તે ઘટના લક્ષણને બદલે નિષ્ફળતાનું નામ આપે છે. જો નિષ્ફળતા ચોક્કસ ક્લાયન્ટ સાથે હોય, તો સર્વર લોગ તે પ્રયત્ન માટે કંઈ દેખાડશે નહીં, જે પોતે જ માહિતીપ્રદ છે. ફાળવણી ભૂલ ન હોવી સમસ્યાને તે જ ક્લાયન્ટની વાટાઘાટ સુધી મર્યાદિત કરે છે અને આગળ કઈ આદેશો ચલાવવાના તે કહે છે.
Get-WinEvent -LogName System -MaxEvents 500 | Where-Object { $_.Id -eq 20167 }
Get-NetAdapter -IncludeHidden | Where-Object { $_.InterfaceDescription -like "WAN Miniport*" }સર્વરની ફાળવણી સ્થિતિ વાંચો
RRAS ની બાજુ પુષ્ટિ કરો કે ખરેખર કઈ ફાળવણી પદ્ધતિ રૂપરેખાંકિત છે, નહીં કે દસ્તાવેજો જે ધારે છે. સ્થિર પૂલ અને DHCP દ્વારા મોકલાયેલું રૂપરેખાંકન અલગ રીતે નિષ્ફળ જાય છે, અને સુધારો વપરાશમાં રહેલી પદ્ધતિનો છે. સ્થિર પૂલમાં ખાલી સરનામાં ગણો અને પ્રતિ વપરાશકર્તા ફાળવણી શોધો જે એવી લીઝ રાખે છે જે કોઈને યાદ નથી કે ક્યારે આપી, કારણ કે મોટું દેખાતું પૂલ સંપૂર્ણ ભરેલું હોઈ શકે છે. DHCP માં તપાસો કે રિલે કોઈ સર્વર સુધી પહોંચે છે અને શ્રેણીમાં ખાલી લીઝ છે.
સામાન્ય ક્લાયન્ટ દ્વારા સમાપ્ત થયેલી શ્રેણી ખોટી રૂપરેખાંકિત પૂલ જેવી જ 720 ઉત્પન્ન કરે છે, અને RRAS કન્સોલ બંને સ્થિતિમાં સંપૂર્ણ સ્વસ્થ દેખાશે. પૂલને નાની શ્રેણીઓમાં વિભાજિત કરવાના વારસાગત ઉપાયનો વિરોધ કરો: મૂળ સલાહ એક વ્યવસ્થાપકના પરિણામનું વર્ણન કરતી હતી, અને તે એવી ફાળવણી નિષ્ફળતાને સુધારતી નથી જેને સર્વરની પોતાની ઘટનાઓ સીધા નામ આપી શકે છે.
ક્લાયન્ટની બાઇન્ડિંગ તોડ્યા વિના વાંચો
જો પુરાવા એક ક્લાયન્ટ તરફ ઇશારો કરે, તો સ્ટેક ફરીથી ઇન્સ્ટોલ કરવાને બદલે છુપાયેલું એડેપ્ટર તપાસો. પહેલો આદેશ WAN Miniport ઇન્ટરફેસ અને તેમના નામ સૂચિબદ્ધ કરે છે; બીજો તે નામ લે છે જે તેણે પરત કર્યું, કોઈ માર્ગદર્શિકામાંથી કૉપિ કરેલું નામ નહીં.
Get-NetAdapterBinding -Name "<name>" -IncludeHidden -AllBindingsયાદી સરનામા-ઉકેલ બાઇન્ડિંગ અને તૃતીય-પક્ષ ફિલ્ટર માટે વાંચો. અક્ષમ બાઇન્ડિંગ લક્ષિત સમારકામ છે, જ્યારે ફિલ્ટરની હાજરી તે સૉફ્ટવેરના માલિકને પ્રશ્ન છે, સુરક્ષા ઉત્પાદન અક્ષમ કરવાની પરવાનગી નહીં. બધા એડેપ્ટર દૂર કરવું એ જ એક પગલું છે જે નિષ્ફળતા પાછી આવે તો જરૂરી પુરાવા નષ્ટ કરે છે.
સુધારા પછી એ જ પ્રોફાઇલ ફરી અજમાવો અને પછી બે-ક્લાયન્ટ કેસ ફરીથી કરો જો તે જ મૂળ લક્ષણ હતું, કારણ કે સફળ પહેલું કનેક્શન બીજો ક્લાયન્ટ જે ફાળવણી સમસ્યા ઉજાગર કરે છે તેને છુપાવે છે. નોંધને ચાર ક્ષેત્રોમાં રાખો: કયો ક્લાયન્ટ, કઈ બાઇન્ડિંગ, કઈ ઘટના અને શું બદલાયું. દરેક પ્રયત્નમાં એક સ્તર બદલો, કારણ કે ક્લાયન્ટ સુધારો અને પૂલ ફેરફાર સાથે લાગુ થાય તો તેમને શ્રેય આપી શકાતો નથી, અને આગલી નિષ્ફળતા એ જ હોવા છતાં નવી દેખાશે.