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

ભૂલના કોડને ચુકાદો નહીં, તબક્કા તરીકે વાંચો

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

What the client saysStage that failedFirst thing to run
868, name did not resolveDNS, before any packet leaves for the serverResolve-DnsName vpn.example.net
721 or 806, remote computer did not respondOuter protocol filtered, typically GRE or UDPA capture on the local interface
809, server not respondingA device in the path is dropping the outer flowThe same capture, from a second network
789, security layer errorThe security exchange started and was rejectedCertificate and proposal settings on both ends

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

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

ટનલને દોષ આપતા પહેલા નામ તપાસો

હોટેલ અને એરપોર્ટના નેટવર્ક સતત DNS ને અટકાવે છે, અને પોર્ટલ સરનામા સાથે જવાબ આપતું રિઝોલ્વર એવી નિષ્ફળતા ઉત્પન્ન કરે છે જે મૃત સર્વર જેવી બરાબર લાગે છે. સ્થાનિક રિઝોલ્વર શું કહે છે તેની સરખામણી સાર્વજનિક રિઝોલ્વર શું કહે છે તેની સાથે કરો:

Resolve-DnsName vpn.example.net -Type A
nslookup vpn.example.net 1.1.1.1
ipconfig /all | findstr /i "DNS Servers"

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

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

કયું બહારનું પેકેટ અદૃશ્ય થાય છે તે શોધો

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

pktmon filter remove
pktmon filter add -p 500 -t UDP
pktmon start --capture --pkt-size 128
pktmon stop
pktmon etl2txt PktMon.etl

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

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

એક ટ્રાન્સપોર્ટ બદલો અને ફરી ચકાસો

એક વાર તમે જાણો કે બહારનો પ્રવાહ પડતો મૂકાય છે, ત્યારે વ્યવહારુ પ્રશ્ન એ છે કે નેટવર્ક કયા પ્રવાહને મંજૂરી આપે છે. મોટા ભાગના પ્રતિબંધિત નેટવર્ક બહાર જતા TCP 443 ને મંજૂરી આપે છે કારણ કે તેમનાથી બીજી રીતે ચાલે જ નહીં, તેથી શ્રોતાને ત્યાં ખસેડવો સામાન્ય જવાબ છે. OpenVPN પર આ સર્વર બદલાય ત્યાં સુધી ક્લાયન્ટ-બાજુનો સ્વિચ છે:

openvpn --config corp.ovpn --proto tcp-client --remote vpn.example.net 443 --verb 4

IPsec ક્લાયન્ટની પોતાની સેટિંગ પેનલમાં સમાન સ્વિચ હોય છે, સામાન્ય રીતે IPsec over TCP અથવા NAT traversal તરીકે વર્ણવાય છે. તેને બદલવું પણ એક નિદાન છે: જો ટનલ TCP પર ઉપર આવે અને UDP પર મરી જાય, તો તમે સાબિત કર્યું કે નેટવર્ક UDP ને ગાળે છે, અને તે સેટિંગ પણ શોધી કાઢી જે તમને એ સાઇટની દરેક મુલાકાતે જરૂર પડશે.

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

બીજા નેટવર્ક પર એ જ પ્રોફાઇલ ચકાસો

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

pktmon filter add -p 443 -t TCP
pktmon start --capture
Get-VpnConnection -Name "Corp" | Select-Object ConnectionStatus, TunnelType, ServerAddress

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

પછી એ શોધ ત્યાં લખો જ્યાં આગલી વ્યક્તિ જોશે. "આ સાઇટ પર કોર્પોરેટ પ્રોફાઇલને TCP 443 ની જરૂર છે; UDP 500 હોટેલ ગાળે છે" એ એવું વાક્ય છે જેના પર સહકર્મી કાર્ય કરી શકે. "હોટેલમાં VPN અસ્થિર છે" એવું નથી, અને તે ખાતરી આપે છે કે આવતા મહિને એ જ કલાક ફરી વેડફાશે.

સંબંધિત લેખો