Android હંમેશા-ચાલુ VPN: એન્ડપોઇન્ટ નામ પહેલા કેવી રીતે ઉકેલાય છે

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

VPN બિલ્ડર ખરેખર શું માંગે છે

Android VPN એપ પ્લેટફોર્મને સર્વર સરનામું આપતી નથી. તે સ્થાનિક ઇન્ટરફેસ બનાવે છે: ટનલ માટે સરનામાં અને રૂટ, એપ્સ અંદર વાપરવાના રિઝોલ્વર, અને પછી establish() ફાઇલ ડિસ્ક્રિપ્ટર પરત આપે છે જે એપ કાચા IP પેકેટ તરીકે વાંચે અને લખે છે. દૂરનું એન્ડપોઇન્ટ તે બિલ્ડરમાં ક્યારેય દેખાતું નથી.

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

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

બે DNS પ્રશ્નો, એક નહીં

પહેલો પ્રશ્ન છે: ટનલ ઉપર આવ્યા પછી એપ્સ તેમના પ્રશ્નો ક્યાં મોકલે છે? જવાબ છે ટનલની અંદરનું રિઝોલ્વર સરનામું, tun ઇન્ટરફેસ દ્વારા પહોંચી શકાય તેવું, સ્વભાવે સંખ્યાત્મક.

બીજો પ્રશ્ન છે: તે ટનલ પહેલા ક્લાયન્ટ પોતાનું એન્ડપોઇન્ટ કેવી રીતે શોધે છે? તે શોધ ટનલની બહાર, નીચલા નેટવર્ક પર, ક્લાયન્ટની પ્રક્રિયામાં થાય છે. તે નામ વાપરી શકે છે, અને એવું રિઝોલ્વર વાપરવું પડે જ્યાં ઉપકરણ VPN વગર પહોંચી શકે.

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

બૂટસ્ટ્રેપ કેમ અટકી શકે

અવરોધ સક્રિય સાથે હંમેશા-ચાલુ એટલે VPN અંદર ન હોય તેવો ટ્રાફિક કાઢી નાખવામાં આવે, જેમાં VPN ધરાવતી એપનો ટ્રાફિક પણ સામેલ છે. બહાર નીકળવાનો રસ્તો સ્પષ્ટ છે: એપ સોકેટ પર protect() બોલાવે છે, જે તેને નીચલા નેટવર્ક સાથે બાંધે છે જેથી તે ટનલ ટાળીને બહાર જઈ શકે. દરેક VPN ક્લાયન્ટે પોતાના વાહનવ્યવહાર માટે આ કરવું પડે, નહીં તો સર્વર સુધી ક્યારેય પહોંચી ન શકે.

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

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

જવાબ પિન કરવો ઉપાય કેમ નથી

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

DNS રેકોર્ડ જીવનકાળ ધરાવે છે જેથી જવાબો બદલાઈ શકે; કેશિંગ તે કાળ દ્વારા વ્યાખ્યાયિત છે, કાયમ માટે નહીં. જવાબ પિન કરવો નામને સરનામા કરતાં સારું બનાવતી પદ્ધતિ ફેંકી દે છે, જ્યારે નામ વાપરવાનો કાર્યભાર રહે છે.

પિન કરવા સાથે ઘણી વાર બીજી ખરાબ ટેવ આવે છે: ઓળખ ચકાસણી ઢીલી કરવી કારણ કે કનેક્શન હવે બીજી રીતે નિષ્ફળ જાય છે. સર્વર ઓળખ ચકાસણી બૂટસ્ટ્રેપ સમસ્યાનો ભાગ નથી, અને તેને નબળી કરવી DNS તકલીફને અટકાવના જોખમ સાથે બદલે છે.

રીબૂટ ટકી શકે તેવી રચનાઓ

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

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

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

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