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

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

હોટસ્પોટ શું સ્પર્શી શકે છે અને શું નહીં

એક્સેસ નેટવર્ક DHCP માં રિઝોલ્વર સરનામું આપે છે અને તે સરનામા તરફ પોર્ટ 53 ને અટકાવી શકે છે. તે દરેક અસુરક્ષિત લુકઅપને પોર્ટલ સરનામા કે બ્લોક પેજથી જવાબ આપવા માટે પૂરતું છે. જેનું એન્ડપોઇન્ટ હોસ્ટનામ તરીકે લખાયું છે તેવા VPN ક્લાયન્ટને તોડવા માટે પણ તે પૂરતું છે.

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

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

PathWho answersWhat a failure looks like
Lookup before the tunnel is upThe network's resolverThe client never reaches its endpoint
Lookup inside the tunnelThe resolver pushed by the clientLocal policy or tunnel DNS is misconfigured
Browser secure DNSA DoH provider over port 443Both the hotspot and the tunnel policy are bypassed

પ્રારંભિક લુકઅપ ટનલ બનતા પહેલાં થાય છે

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

ઓપરેટિંગ સિસ્ટમો પોતાની કનેક્ટિવિટી તપાસ અને પોર્ટલ શોધ પણ ચલાવે છે, જે RFC 8910 અને RFC 8952 માં વર્ણવેલ છે, અને તે વિનંતીઓ કોઈપણ VPN ઊભું થાય તે પહેલાં નીકળી જાય છે. તેમને પ્રોક્સી લોગમાં જોવું લીકનો પુરાવો નહીં, અપેક્ષિત વર્તન છે.

વ્યવહારુ ઉપાય એ છે કે ક્લાયન્ટને એવું એન્ડપોઇન્ટ આપવું જેને કોઈ લુકઅપની જરૂર ન હોય. જ્યારે તે અશક્ય હોય, ત્યારે પહેલા સાઇન ઇન પૂરું કરો અને પછી કનેક્ટ કરો.

કયા રિઝોલ્વરે જવાબ આપ્યો તે શોધો

બ્રાઉઝરને નહીં, સિસ્ટમને પૂછો, અને ક્વેરી બે વાર ચલાવો: એક વાર ઉપકરણ હાલમાં જે રિઝોલ્વર વાપરે છે તેના દ્વારા, એક વાર નિશ્ચિત સરનામા સામે.

resolvectl query vpn.example.com
dig +short vpn.example.com
dig +short vpn.example.com @1.1.1.1

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

કનેક્ટ થયા પછી પુનરાવર્તન કરો અને સરખાવો. કેશ થયેલો જવાબ સંક્રમણમાં ટકી રહે છે, તેથી કેશ ફ્લશ કરો અથવા બીજા અવલોકન માટે નવું નામ પૂછો.

પછીના લુકઅપ તમે ઇચ્છેલા માર્ગ પર રાખો

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

Split-DNS ને ઇરાદાપૂર્વક લખાયેલી ડોમેન યાદીની જરૂર છે: કોર્પોરેટ સફિક્સ ટનલ દ્વારા, બાકીનું બધું સ્થાનિક રીતે, અને બંને વચ્ચે કોઈ ઓવરલેપ નહીં.

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

સંબંધિત લેખો