Windows VPN કનેક્ટ થતું નથી? કોડને ઇવેન્ટ લોગ સાથે મેળવો

Windows VPN સંવાદ નિષ્ફળ ગયેલું તબક્કો છુપાવે છે. પરિણામ કોડ વાંચો, તે પ્રયાસ માટે RasClient ઇવેન્ટ ખેંચો અને ફક્ત તૂટેલું સ્તર બદલો.

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

સંવાદનું લખાણ છેલ્લું પગલું છે, કારણ નહીં

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

તમે હજી પણ પિન કરી શકો તે પ્રયાસ પોતે છે. કનેક્શનનું નામ, પ્રોફાઇલમાં સંગ્રહિત ટનલનો પ્રકાર — PPTP, L2TP/IPsec, SSTP અથવા IKEv2 — સેકંડ સુધીનો સમય અને કોડ લખો. જો તમને ખાતરી ન હોય કે કયો પ્રોટોકોલ ખરેખર ચાલ્યો, તો મેમરી પર ભરોસો કરવાને બદલે %APPDATA%\Microsoft\Network\Connections\Pbk\rasphone.pbk ખોલો અને પ્રવેશ વાંચો; નવા પ્રોટોકોલ માટે ફરી વપરાયેલી પ્રોફાઇલ તેનું જૂનું પ્રદર્શન નામ રાખે છે.

શબ્દો વાંચતા પહેલાં સંખ્યા વાંચો

કોડ ત્રણ તબક્કામાં પડે છે, અને તબક્કો ચોક્કસ શબ્દરચના કરતાં વધુ મહત્ત્વનો છે: એવી પ્રમાણીકરણ આપલે જ્યાં પહોંચાયું અને નકારવામાં આવી, એવો સર્વર જેણે કદી જવાબ આપ્યો નહીં, અથવા એવી વાટાઘાટ જે લિંક ઉપર આવ્યા પછી ધરાશાયી થઈ. 691 પ્રથમ પ્રકાર છે — ઓળખપત્રની ચકાસણી ચાલી અને નિષ્ફળ ગઈ, પછી ભલે ખરાબ પાસવર્ડ, લોક થયેલું કે મુદત વીતેલું ખાતું, અથવા સર્વર સ્વીકારે નહીં તેવો પ્રમાણીકરણ પ્રોટોકોલ હોય. 812 પણ નકાર છે, પણ માન્ય ઓળખપત્રો સાથે: દૂરસ્થ ઍક્સેસ સર્વર પરની નીતિએ તમારી વિરુદ્ધ નિર્ણય લીધો. Microsoft કેનોનિકલ ડાયલ-અપ અને VPN કનેક્શન માટે ભૂલ કોડની યાદી રાખે છે, અને સંદેશનું લખાણ શોધતા પહેલાં તમારો નંબર ત્યાં વાંચવો યોગ્ય છે.

809 વિરુદ્ધ વર્ગ છે: કંઈ પાછું આવ્યું નહીં. તે માર્ગની સમસ્યા છે — SSTP માટે TCP 443 ફિલ્ટર થયેલું, PPTP માટે GRE બ્લોક થયેલું, IPsec પસાર થવા માટે UDP 500 અને 4500 અથવા ESP છોડી દેવાયેલા. નવો પાસવર્ડ તેને સુધારી શકતો નથી અને નવું પ્રમાણપત્ર પણ નહીં. 720 નો અર્થ છે કે લિંક ઉપર આવી અને PPP એ વાટાઘાટ કદી પૂરી કરી નહીં, જે પ્રોટોકોલની અસંગતિ અથવા સર્વર જે સરનામું સોંપી શક્યું નહીં તે તરફ ઇશારો કરે છે. 789, અથવા IKEv2 પર 13801, એ IPsec ની અંદરની ઓળખ છે: એવું પ્રમાણપત્ર જેનો વિષય તમે ડાયલ કરો છો તે નામ સાથે મેળ ખાતો નથી, અવિશ્વસનીય સાંકળ, અથવા બે છેડા વચ્ચે અલગ પડતી પૂર્વ-શેર કરેલી કી.

તે જ મિનિટની RasClient ઇવેન્ટ ખેંચો

ઇવેન્ટ વ્યૂઅરમાં, સ્રોત RasClient પર ફિલ્ટર કરેલી Windows Logs > Application એ પહેલું જોવાનું સ્થળ છે. ભૂલ 720 વિશેનું Microsoft નું લખાણ તે લોગમાંની ઇવેન્ટ 20227 તરફ ઇશારો કરે છે. એ જ પ્રદાતા બીજા પરિણામો માટે બીજા ઓળખકર્તા બહાર પાડે છે, તેથી ID ને નિદાન માનવાને બદલે સંદેશ અને તેમાં સમાયેલો પરિણામ કોડ વાંચો; સામાન્ય સંવાદ અને 720 ધરાવતી 20227 પહેલેથી જ ઘણી સાંકડી વાર્તા છે.

PowerShell થી, GUI માંથી ક્લિક કર્યા વિના:

Get-WinEvent -FilterHashtable @{
  LogName      = 'Application'
  ProviderName = 'RasClient'
  StartTime    = (Get-Date).AddMinutes(-15)
} | Format-List TimeCreated, Id, Message

ખાલી પરિણામ માહિતીપ્રદ છે. તેનો સામાન્ય અર્થ એ છે કે ડાયલ કદી એટલું દૂર ગયું નહીં કે RAS કંઈ લોગ કરે, અથવા જે સૉફ્ટવેર નિષ્ફળ ગયું તે મૂળ ક્લાયન્ટ જ નથી — તૃતીય-પક્ષના ક્લાયન્ટ પોતાનું નિદાન રાખે છે અને ઘણી વાર Application લોગમાં કંઈ લખતા નથી. ઇવેન્ટ લોગિંગ તૂટેલું છે તેવું નિષ્કર્ષ કાઢતા પહેલાં વિક્રેતાનો લોગ તપાસો.

ઇવેન્ટના ઢગલાને બદલે એક સમયરેખા બનાવો

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

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

પુનરાવર્તનયોગ્ય કેપ્ચર માટે, આદેશ લાઇનમાંથી ડાયલ કરો અને તેને પરિણામ છાપવા દો:

rasdial "Office VPN"
rasdial "Office VPN" /disconnect

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

દરેક તબક્કો તમને શું બદલવાનું કહે છે

તબક્કાનું નામ આપવું ત્યારે જ ઉપયોગી છે જ્યારે તે ફેરફારનો સમૂહ એક સ્તર સુધી ઘટાડે:

  • 691 — પ્રમાણીકરણ: ક્લાયન્ટ જે EAP પદ્ધતિ ઓફર કરે છે તેની સામે સર્વર જે સ્વીકારે છે, ખાતાની સ્થિતિ, પાસવર્ડની મુદત, ડાયલ-ઇન પરવાનગી.
  • 812 — સર્વર નીતિ: આ વપરાશકર્તા અને આ સમય-વિન્ડો સાથે મેળ ખાતી દૂરસ્થ ઍક્સેસ નીતિ અથવા NPS નિયમ.
  • 809 — પહોંચ: માર્ગ પરના ફાયરવોલ નિયમો, NAT અને પ્રોટોકોલ પસાર થવું, પસંદ કરેલા ટનલ પ્રકારને જરૂરી પોર્ટ.
  • 720 — PPP વાટાઘાટ: પ્રમાણીકરણ પ્રોટોકોલની અસંગતિ, સરનામું સોંપણી, સર્વર-બાજુનું PPP સેટિંગ.
  • 789 / 13801 — IPsec ઓળખ: તમે ડાયલ કરો છો તે નામ સામે પ્રમાણપત્રનો વિષય, વિશ્વાસ સાંકળ, પૂર્વ-શેર કરેલી કી.

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

પુરાવા વહેંચો, પર્યાવરણ નહીં

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

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

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

સંબંધિત લેખો