VPN કનેક્શન ટાઇમઆઉટ: DNS, પરિવહન, વાટાઘાટ કે લૉગિન
ટાઇમઆઉટનો અર્થ ફક્ત એ છે કે સમયમર્યાદા વીતી ગઈ. ચાર તબક્કા, નામ ઉકેલ, પરિવહન, વાટાઘાટ અને લૉગિન, ની તુલના કરો કે કયો છેલ્લે પૂર્ણ થયો.
“કનેક્શનનો સમય પૂરો થયો” એ VPN ક્લાયન્ટ છાપી શકે તેવી સૌથી અસ્પષ્ટ ભૂલ છે. તેનો અર્થ છે કે એક ક્રિયાએ તેની સમયમર્યાદા ચૂકી ગઈ, અને નામ ઉકેલવાથી લઈને લૉગિનના જવાબ સુધીના દરેક તબક્કાની સમયમર્યાદા હોય છે. જે ક્લાયન્ટ ફક્ત અંતિમ સંદેશ દેખાડે છે તે તબક્કાઓને સરખા દેખાવડાવે છે, તેથી લોકો સમયમર્યાદા વધારે છે, પોર્ટ બદલે છે અને પ્રોફાઇલ ફરી સ્થાપિત કરે છે, એ જ ક્રમમાં, કંઈ પણ શીખ્યા વિના. તબક્કાઓની તુલના કરવી ઝડપી છે: દરેક અલગ જગ્યાએ નિષ્ફળ જાય છે, અને દરેક નિષ્ફળતા અલગ પ્રકારનો પુરાવો છોડે છે.
ચાર તબક્કા, ચાર જુદી નિષ્ફળતાઓ
ક્રમ નિશ્ચિત છે ભલે ક્લાયન્ટ તેને છુપાવે: નામ ઉકેલાવું જોઈએ, પરિણામી સરનામા સુધી પરિવહન સ્થાપિત થવું જોઈએ, પ્રોટોકોલે તેના પરિમાણો અને કી વિશે વાટાઘાટ કરવી જોઈએ, અને ખાતું પ્રમાણિત થવું જોઈએ. OpenVPN ની કનેક્ટિવિટી મુશ્કેલીનિવારણ માર્ગદર્શિકા તેના પોતાના ક્લાયન્ટ માટે એ જ ક્રમ અનુસરે છે, અને બાકીના તેને નજીકથી અનુસરે છે. બીજા તબક્કામાં ટાઇમઆઉટ અને ચોથા તબક્કામાં ટાઇમઆઉટમાં સ્ક્રીન પરના શબ્દ સિવાય કંઈ સામ્ય નથી.
| Stage | Looks like | What it does not prove |
|---|---|---|
| Name resolution | fails in under a second, before any contact | nothing about the server being up |
| Transport | waits the full timeout, then gives up | nothing about the VPN service behind the port |
| Negotiation | connects, then stalls at handshake | nothing about credentials |
| Login | a reply arrives and is rejected or hangs on a prompt | nothing about reachability |
લૉગમાં ભૂલ પહેલાંની છેલ્લી લીટી નહીં, પરંતુ પ્રગતિ દર્શાવતી છેલ્લી લીટી વાંચો. મોટાભાગના ક્લાયન્ટ ઉકેલાયેલું સરનામું, સ્થાપિત સોકેટ, શરૂ થયેલું હેન્ડશેક કે પ્રમાણીકરણ વિનંતી જેવું કંઈક છાપે છે, અને તે લીટી પછીનો તબક્કો જ સમય પૂરો થયેલો હોય છે.
નામ ઉકેલવું કોઈપણ સંપર્ક પહેલાં નિષ્ફળ જાય છે
જો એન્ડપોઇન્ટ કદી ઉકેલાય નહીં, તો ક્લાયન્ટ પાસે જોડાવા માટે કંઈ નથી અને કોઈ પરિવહન કાર્ય થયું નથી. તે નિષ્ફળતા સામાન્ય રીતે પૂર્ણ ટાઇમઆઉટને બદલે તાત્કાલિક હોય છે, જે તેને બાકીનાથી અલગ પાડવાનો સૌથી સસ્તો રસ્તો છે. નામને સિસ્ટમ રિઝોલ્વર અને બીજા રિઝોલ્વર સાથે ચકાસો, અને સર્વર બંધ છે તેવું તારણ કાઢતાં પહેલાં બંને જવાબોની તુલના કરો.
ફોરમ પોસ્ટમાંથી કૉપી કરેલું જૂનું સરનામું સર્વર સમસ્યા જેવા દેખાતા ટાઇમઆઉટનું સામાન્ય કારણ છે, કારણ કે સરનામું હવે બીજા કંઈકનું છે અથવા કંઈનું નથી. પહેલાં કામ કરતા સરનામાને બદલવાને બદલે ઓપરેટરની વર્તમાન પ્રોફાઇલ વાપરો. ping નો જવાબ ન આવવો કોઈપણ દિશામાં પુરાવો નથી: ઘણા એન્ડપોઇન્ટ ICMP કાઢી નાખે છે અને તેમ છતાં સંપૂર્ણ સારી રીતે સેવા આપે છે.
પરિવહન સ્થાપન એ પેકેટની રાહ જોએ છે જે આવશે નહીં
જ્યારે DNS ઠીક હોય અને ક્લાયન્ટ તોપણ આખો ટાઇમઆઉટ બાળે, ત્યારે પરિવહન સ્તર શંકાસ્પદ છે. TCP પર તમે પોર્ટ સીધો ચકાસી શકો છો; Test-NetConnection Windows પર અથવા nc -vz Linux પર કહે છે કે કંઈક કનેક્શન સ્વીકારે છે કે નહીં, અને તે ping કરતાં વધુ ઉપયોગી છે. UDP પર તમે એ જ રીતે ચકાસી શકતા નથી, કારણ કે તે સ્તરે પૂર્ણ કરવા માટે કોઈ હેન્ડશેક નથી, અને આ અસમાનતા ઘણા ખોટા તારણો લાવે છે.
TCP પરીક્ષણ જે સાબિત કરે છે તે મર્યાદિત છે: 443 પોર્ટ સ્વીકારતી સેવા જરૂરી નથી કે VPN શ્રોતા હોય, અને ફક્ત-UDP એન્ડપોઇન્ટ પાસે કંઈપણ સ્વીકારવા માટે TCP પોર્ટ નથી. પ્રોફાઇલને UDP થી TCP માં ફરી લખવાથી બીજી બાજુ શ્રોતા બનતો નથી; તે ફક્ત બદલે છે કે તમારો ક્લાયન્ટ શેની રાહ જુએ છે. જો નેટવર્ક પ્રોટોકોલ ફિલ્ટર કરે, તો ફેરફાર એ જ તબક્કે અલગ ટાઇમઆઉટ ઉત્પન્ન કરે છે.
કેપ્ટિવ પોર્ટલ આ તબક્કે પોતાની અલગ ચકાસણીને પાત્ર છે. જ્યાં સુધી પોર્ટલ ઉપકરણને અધિકૃત ન કરે, બહાર જતો ટ્રાફિક પોર્ટલ પર જાય છે અને ટનલનો પ્રયાસ ફક્ત લટકી રહે છે. પહેલાં બ્રાઉઝરમાં પોર્ટલ પૂર્ણ કરો, પછી ફરી પ્રયાસ કરો, અને પોર્ટલ હજી બાકી હોય ત્યારે પ્રોફાઇલ ન બદલો.
વાટાઘાટ અને લૉગિન એટલે સર્વરે જવાબ આપ્યો
એકવાર ટનલ સર્વર સુધી પહોંચે, ક્લાયન્ટ હેન્ડશેક શરૂ કરે છે અને ભૂલનું સ્વરૂપ બદલાય છે. અહીં અટકવું પહોંચવાને બદલે સુસંગતતા વિશે છે: મેળ ન ખાતા પ્રોટોકોલ સંસ્કરણો, બીજી બાજુ સ્વીકારશે નહીં તેવું સાઇફર કે ડેટા-ચેનલ સેટિંગ, અથવા એવી પ્રોફાઇલ જે સર્વર આપતું નથી તેવી સુવિધા ધારે છે. OpenVPN એ મુખ્ય સંસ્કરણો વચ્ચે તેના વાટાઘાટના ડિફૉલ્ટ એટલી વાર ખસેડ્યા કે એક પેઢી માટે લખાયેલી પ્રોફાઇલ સર્વર સુધી પહોંચીને પણ ઉપર ન આવી શકે.
પ્રમાણીકરણ છેલ્લો તબક્કો છે અને ખોટું વાંચવું સૌથી સહેલું છે. સ્પષ્ટ નકાર એ એક જવાબ છે, જેનો અર્થ છે માર્ગ કામ કરે છે અને સમસ્યા ઓળખ, પ્રમાણપત્ર કે ખાતાની સ્થિતિમાં છે. બ્રાઉઝર-આધારિત સિંગલ સાઇન-ઓન પ્રવાહ ત્રીજો કિસ્સો છે: ક્લાયન્ટ એવી ક્રિયાની રાહ જુએ છે જે તમે કરી નથી, અથવા એવા બ્રાઉઝરની જે તે શરૂ કરી શકતું નથી, અને તમે તે પગલું પૂર્ણ ન કરો ત્યાં સુધી કંઈ આવશે નહીં.
ફરી પ્રયાસ બદલતાં પહેલાં પુરાવાની તુલના કરો
ઉપકરણ અને પ્રોફાઇલ સ્થિર રાખો અને એક વખતે એક વસ્તુ બદલો, નેટવર્કથી શરૂ કરીને. જો એ જ પ્રોફાઇલ ફોનના હોટસ્પોટ પર જોડાય અને હોટેલ Wi-Fi પર ટાઇમઆઉટ થાય, તો ચલ સર્વર નહીં, માર્ગ છે. જો તે બધે નિષ્ફળ જાય, તો ચલ પ્રોફાઇલ કે એન્ડપોઇન્ટ છે. જો તે દિવસના એક જ સમયે નિષ્ફળ જાય, તો સમયછાપ પકડો અને લોડ વિશે કંઈ ધારવા પહેલાં સર્વર-બાજુની ઘટનાઓ સાથે તેની તુલના કરો.
તમે સંચાલિત કરો છો તે સેવા માટે નિર્ણાયક તુલના એ છે કે પ્રયાસ આખરે પહોંચે છે કે નહીં. જે કનેક્શન શ્રોતા સુધી પહોંચીને પછી અટકે છે તે વાટાઘાટ તબક્કાનું છે; જે શ્રોતાની દૃષ્ટિમાં કદી દેખાતું નથી તે પરિવહન કે ઉકેલ સમસ્યા છે, અને કોઈ પણ ફરી-પ્રયાસ ટ્યુનિંગ તેને ખસેડશે નહીં. સર્વર લૉગ નકારેલા લૉગિનને શાંત ડ્રોપથી પણ અલગ પાડે છે, જે ઓળખ સુધારણા અને ફાયરવૉલ સુધારણા વચ્ચેનો તફાવત છે.
ક્લાયન્ટ સંસ્કરણ, પ્રોફાઇલનું નામ, સમય વિસ્તાર સાથે પ્રયાસનો સમય અને અંતિમ ડિસ્કનેક્ટ લીટીને બદલે પ્રથમ ઉપયોગી ભૂલ નોંધો. અંશ શેર કરતાં પહેલાં કી અને ઓળખપત્ર ધરાવતી સામગ્રી કાઢી નાખો. પછી એક અર્થપૂર્ણ સુધારો કરો અને ફરી પ્રયાસ કરો, કારણ કે લાંબી સમયમર્યાદા ફક્ત દસ્તાવેજીકૃત ધીમી ક્રિયાને મદદ કરે છે અને ખોટા સરનામા કે અવરોધિત પોર્ટ માટે કંઈ કરતી નથી.