શા માટે OpenVPN પ્રોફાઇલ ઘરે કામ કરે છે પણ હોટેલમાં નિષ્ફળ જાય છે

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

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

ચાર નેટવર્ક તથ્યો સ્થાન પ્રમાણે બદલાય છે

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

બીજું નામ-ઉકેલ છે. DNSને અટકાવતું પોર્ટલ દરેક પ્રશ્નનો જવાબ પોતાના સરનામાથી આપે છે, તેથી VPN હોસ્ટનામ પોર્ટલ પર ઉકેલાય છે અને ક્લાયન્ટ વેબ પૃષ્ઠ સુધી ટનલ બનાવવાનો પ્રયાસ કરે છે.

ત્રીજું પરિવહન ગાળણી છે. ફક્ત બ્રાઉઝિંગની પરવાનગી આપવા માંગતા નેટવર્ક TCP 443ને મનસ્વી ગંતવ્યો સુધી પસાર કરે છે અને UDP સહિત લગભગ બાકીનું બધું કાઢી નાખે છે.

ચોથું સરનામાંકન છે. સ્થાનિક સબનેટ ટનલ પાછળના નેટવર્ક સાથે ઓવરલેપ થઈ શકે છે, અથવા અપલિંક કોઈ પણ વપરાયોગ્ય IPv4 માર્ગ આપતું ન હોઈ શકે.

નામ-ઉકેલ અને કેપ્ટિવ પોર્ટલ

પ્રોફાઇલમાંનું હોસ્ટનામ સર્વરના આંકડાકીય સરનામાથી બદલો અને ફરી પ્રયાસ કરો. જો IP જોડાય અને નામ ન જોડાય, તો દોષ નામ-ઉકેલનો છે, અને પ્રોફાઇલ પોતે ઠીક છે.

VPNને અડવા પહેલાં બ્રાઉઝર ખોલો અને સામાન્ય HTTP પૃષ્ઠ ખોલવાનો પ્રયાસ કરો. લોગિન પૃષ્ઠ પર રીડાયરેક્ટ થવું એટલે પોર્ટલ હજી બાકી છે; તેને પૂર્ણ કરો, પછી ફરી જોડાઓ. ઘણી હોટેલો થોડા કલાકો પછી સત્ર પણ સમાપ્ત કરે છે, જે લોગિન સમસ્યા કરતાં બપોરના વિચ્છેદ જેવું લાગે છે.

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

પરિવહન ગાળણી: પહેલાં UDP, બેકઅપ તરીકે TCP 443

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

TCP 443 વિશ્વસનીય બેકઅપ છે કારણ કે નેટવર્ક તેને સામાન્ય HTTPSથી અલગ પાડી શકતું નથી. જ્યારે ઓપરેટરની TCP પ્રોફાઇલ હોય ત્યારે તે વાપરો, કારણ કે સર્વરે પણ એ પરિવહન અને પોર્ટ પર સાંભળવું પડે; ફક્ત ક્લાયન્ટ બદલવાથી બીજા પ્રકારની નિષ્ફળતા થાય છે. જો TCP પ્રોફાઇલ ન હોય, તો પોર્ટ સંપાદિત કરીને નવી શોધવાને બદલે ઓપરેટરને પૂછો. સર્વર બાજુએ પણ સહમત થવું પડે, અને અસંગતિ ફરી ફાયરવૉલ સમસ્યા જેવી લાગે છે.

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

સરનામા અથડામણ અને IPv4 વગરના અપલિંક

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

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

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

ટનલ ઊભી થયા પછીનાં લક્ષણો

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

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