Android VPN આખું હોસ્ટનામ ઉકેલે છે, પણ ટૂંકું નામ નહીં

તમેfilesટર્મિનલ એમ્યુલેટરમાં લખો છો અને કંઈ પાછું આવતું નથી; તમેfiles.corp.exampleલખો છો અને એ જ સર્વર તરત જ જવાબ આપે છે. VPN ઓળખપત્રોમાં કંઈ બદલાયું નથી, અને ખાનગી DNS સર્વર ક્યારેય બગડ્યું નથી. Android માં ટૂંકું લેબલ અને આખું નામ રિઝોલ્વરમાંથી અલગ રસ્તે જાય છે, અને એ રસ્તાઓમાંથી એક એવી સેટિંગ પર આધાર રાખે છે જે ટનલના માલિકે પૂરી પાડવી પડે. તમારી સામેનો નિર્ણય એ નથી કે કયું DNS સર્વર બદલવું, પણ એ છે કે એપ ખરેખર જે નેટવર્ક વાપરે છે તે કોણ નિયંત્રિત કરે છે.

સર્ચ ડોમેન એ સરનામું નથી. એ એવા પ્રત્યયોની યાદી છે જે રિઝોલ્વર હાર માની લે તે પહેલાં નગ્ન લેબલ સાથે જોડે છે.

સર્ચ પ્રત્યય અને DNS સર્વર અલગ ક્ષેત્રો છે

રિઝોલ્વરનું સરનામું Android ને કહે છે કે ક્યાં પૂછવું. સર્ચ પ્રત્યય કહે છે કે જ્યારે તમે ફક્ત ડાબી બાજુનું લેબલ આપો ત્યારે શું પૂછવું. બંને એક જ નેટવર્ક ઑબ્જેક્ટ પર રહે છે, અને બંનેમાંથી કોઈ પણ એકલું ખૂટી શકે છે.

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

Android એ વિભાજનને આ દ્વારા દર્શાવે છેLinkProperties. DNS સર્વરોની યાદી અને ડોમેન સર્ચ યાદી એક જ ઑબ્જેક્ટ પર બેસે છે, અને પહેલી સંપૂર્ણ ભરેલી હોય તોપણ બીજી સામાન્ય રીતે ખાલી હોય છે. રિઝોલ્વર હોય પણ ડોમેન ન હોય એવું નેટવર્ક એ નેટવર્ક છે જ્યાં પ્રત્યય ક્યારેય લાગુ થયો જ નહીં — એ સર્વર નહીં જેણે ટૂંકું નામ નકાર્યું હોય.

કંઈ બદલતા પહેલાં અસરકારક નેટવર્ક વાંચો

Wi-Fi, મોબાઇલ નેટવર્ક અને VPN ઇન્ટરફેસ ત્રણ અલગ નેટવર્ક છે, અને ટનલ ઉપર આવતાં જ ડિફોલ્ટ બને છે. તેથી ઑફિસના Wi-Fi પર કામ કરતો પ્રત્યય સ્વતઃ ટનલ સક્રિય હોય ત્યારે લાગુ પડતો પ્રત્યય નથી. એપ ખરેખર જે નેટવર્ક પર પસંદ થયેલી છે તે તપાસો, ગયા અઠવાડિયે તમે ગોઠવેલું નહીં.

ઉપકરણ પરનું ટર્મિનલ શેલ અહીં નબળો સાક્ષી છે, કારણ કે તેનુંresolv.confદરેક એપના બદલે રિઝોલ્વરનું એક જ દૃશ્ય પ્રતિબિંબિત કરે છે.

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

જો તમે VPN એપ બનાવો છો, તો બિલ્ડરમાં જ પ્રત્યય જોડો

જ્યારે તમારી એપ આ દ્વારા ઇન્ટરફેસ સ્થાપે છેVpnService,addSearchDomainત્યારે એ આ માટે સમર્થિત ઇનપુટ છે. તે આ પ્રકારની ડોમેન શબ્દમાળા લે છેcorp.example, અને તે સર્વર સરનામું મોકલવાની વૈકલ્પિક રીત નથી.

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

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

જો તમે ફક્ત VPN વાપરો છો, તો આ તમારે સેટ કરવાનું નથી

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

ડેસ્કટોપ પ્રોફાઇલ ફરી આયાત કરવાથી મોબાઇલ મેપિંગ વિશે ફરી કંઈ સાબિત થતું નથી.

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

જ્યારે પ્રત્યય હાજર હોય અને ટૂંકા નામ તોપણ નિષ્ફળ જાય

જો ડોમેન સર્ચ યાદી પહેલેથી જcorp.exampleબતાવે છે, તો પ્રત્યયને દોષ આપવાનું બંધ કરો. તપાસો કે રિઝોલ્વર વિસ્તૃત નામ માટે બધેથી જવાબ આપે છે કે નહીં, કારણ કે પ્રત્યય ફક્ત તમે પૂછેલો પ્રશ્ન બદલે છે. તે સર્વરને કદી એવા ઝોન માટે સત્તાવાર બનાવતું નથી જે તે હોસ્ટ કરતું નથી.

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

પ્રમાણપત્રો પોતાનું અલગ ઉલ્લેખ પાત્ર છે. HTTPS માન્યતા તમે ખરેખર ટાઇપ કરેલા હોસ્ટનામનો ઉપયોગ કરે છે, તેથી સાચી રીતે વિસ્તરતું ટૂંકું નામ હેન્ડશેકમાં હજી પણfilesરજૂ કરે છે. જે પ્રમાણપત્રfiles.corp.exampleમાટે જારી કરાયું છે તે તેના માટે માન્ય નહીં થાય, અને એ ભૂલ સાચું વર્તન છે, તમે શરૂ કરેલી DNS સમસ્યાનું લક્ષણ નહીં.

હવે શું કરવું

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

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