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

નંબરને એક તબક્કા તરીકે વાંચો

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

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

Code familyStageWhere the evidence lives
829, 703Link or dial completionClient event log, remote listener reachability
720PPP negotiation and miniport bindingAdapter state, bindings, client log detail
691, 649, 812Identity and authorizationGateway or authentication server decision
Connected, no trafficAddressing, routing and resolutionRoute table and resolver configuration

પ્રથમ તબક્કો: કડી અને ડાયલ પ્રયાસ

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

Get-VpnConnection -Name 'Corp' | Select-Object Name,ServerAddress,TunnelType,AuthenticationMethod,ConnectionStatus
Test-NetConnection -ComputerName vpn.example.net -Port 443
Get-WinEvent -LogName Application -MaxEvents 200 | Where-Object ProviderName -match 'RasClient' | Select-Object -First 15 TimeCreated,Id,Message

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

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

બીજો તબક્કો: PPP અને મિનીપોર્ટ બાઇન્ડિંગ

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

Get-NetAdapter -IncludeHidden | Where-Object InterfaceDescription -match 'WAN Miniport' | Select-Object Name,Status,ifIndex
Get-NetAdapterBinding | Where-Object ComponentID -match 'ms_pptp|ms_l2tp|ms_sstp|ms_agile' | Select-Object Name,ComponentID,Enabled

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

ત્રીજો તબક્કો: ઓળખ અને અધિકૃતિ

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

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

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

ચોથો તબક્કો: જોડાયેલું, અને કંઈ કામ કરતું નથી

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

Get-NetRoute -DestinationPrefix 10.24.0.0/16 | Select-Object DestinationPrefix,NextHop,InterfaceAlias
Resolve-DnsName files.corp.example.internal
Test-NetConnection -ComputerName 10.24.6.15 -Port 445

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

દરેક પરીક્ષણ માટે ફેરફારો એક સ્તરમાં રાખો. આગલા પ્રયાસ પહેલાં કરેલું દરેક સંપાદન આગલા કોડના સંદર્ભનો ભાગ બને છે, અને તમારા છેલ્લા સંપાદનનું વર્ણન કરતો કોડ કોડ ન હોવા કરતાં ખરાબ છે.

એક પ્રયાસ, એક ફેરફાર, એક રેકોર્ડ

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

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

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

સંબંધિત લેખો