Android VPN સર્વર: root ફોનને પહોંચપાત્ર બનાવતું નથી
ત્રણ અલગ સમસ્યાઓ નક્કી કરે છે કે ફોન VPN ક્લાયન્ટની સેવા કરી શકે છે કે નહીં: આવતો માર્ગ, વિશેષાધિકાર મોડલ અને ફોરવર્ડિંગ. root ફક્ત વચ્ચેના ભાગને જ સ્પર્શે છે.
root બદલે છે કે પ્રોસેસ કઈ નેટવર્ક ક્રિયાઓ કરવાનો પ્રયાસ કરી શકે. તે ફોનને જાહેરમાં પહોંચપાત્ર સરનામું આપતું નથી, ઓપરેટર પાસે આવતું મેપિંગ અનામત રાખતું નથી, અને રીબૂટ પછી ડેમનને જીવંત રાખતું નથી. જો તમે નક્કી કરી રહ્યા છો કે Android ફોન VPN સર્વર તરીકે કાર્ય કરી શકે છે કે નહીં, તો ત્રણ પ્રશ્નો અલગ કરો: ઇચ્છિત ક્લાયન્ટ લિસનર સુધી પહોંચી શકે છે કે નહીં, સર્વર અમલીકરણને કયા વિશેષાધિકાર મોડલની જરૂર છે, અને ટનલ ઊભી થયા પછી શું ફોરવર્ડ કરવું પડશે.
કોણે અને ક્યાંથી ફોન સુધી પહોંચવું છે
એક જ મંજૂર LAN પરનો ક્લાયન્ટ અને મોબાઇલ ડેટા પરનો ક્લાયન્ટ બે અલગ નેટવર્ક ચકાસે છે. પહેલા ઇચ્છિત નક્કી કરો, કારણ કે જવાબો એકમાંથી બીજામાં પસાર થતા નથી. Wi-Fi પર, વિનંતી વગરનું આવતું ટ્રાફિક સામાન્ય રીતે અપસ્ટ્રીમ રાઉટર પર મેપિંગ અને તેની આગળ વાપરી શકાય તેવો જાહેર માર્ગ માંગે છે. સેલ્યુલર પર, carrier-grade NAT નો અર્થ છે કે આવતું IPv4 ઘણી વાર ઉપલબ્ધ નથી હોતું, ફોન શું મંજૂરી આપે તેમ છતાં.
તે છેલ્લો મુદ્દો એવો છે જેને root સ્પર્શી શકતું નથી. ફોનનું સ્થાનિક ફાયરવોલ અને ઓપરેટરનું NAT અલગ સિસ્ટમો છે, અને પહેલું બદલવાની બીજા પર કોઈ અસર થતી નથી. ખાનગી ઇન્ટરફેસ સરનામું, મોબાઇલ-ડેટા આઇકન કે સાંભળતું સોકેટ પહોંચપાત્રતાનો પુરાવો નથી. જો ઓપરેટરનો માર્ગ વૈશ્વિક રીતે રાઉટ કરી શકાય તેવું IPv6 આપે છે, તો પણ તેના માટે જાણી જોઈને લિસનર અને ફાયરવોલ નીતિની જરૂર છે; સરનામું હોવું એ કનેક્શન સ્વીકારવા જેવું નથી.
| Client path | What actually decides reachability |
|---|---|
| Same LAN | The phone's listener and its local firewall |
| Wi-Fi, from the internet | A mapping on the upstream router plus a usable public path beyond it |
| Cellular IPv4 | The carrier's NAT, which the handset does not control |
| Cellular IPv6 | Address, listener and firewall policy together |
સેવા આપવી અને ફોરવર્ડ કરવું બે અલગ સફળતાઓ છે
પૂર્ણ થયેલો VPN હેન્ડશેક સાબિત કરે છે કે ટનલ અસ્તિત્વમાં છે. તે સાબિત કરતું નથી કે ક્લાયન્ટ ફોન પાછળની LAN સુધી પહોંચી શકે છે, અને સાબિત કરતું નથી કે ફોન ઇન્ટરનેટ એક્ઝિટ તરીકે કાર્ય કરી શકે છે. તે અલગ ગોઠવણીઓ છે જે આંતરિક સરનામા યોજના, રૂટ, પરત વર્તન અને તમે ખરેખર ઇચ્છો તે કાર્ય માટે સંકુચિત ફોરવર્ડિંગ નીતિ પર બને છે.
નિષ્ફળતાનો પ્રકાર અનુમાનિત છે: હેન્ડશેક સફળ થાય છે, ક્લાયન્ટ જોડાયેલું દેખાય છે, અને કંઈપણ લોડ થતું નથી. ક્લાયન્ટ ડિબગ કરતા પહેલા નક્કી કરો કે બે ભૂમિકાઓમાંથી કઈ બનાવી રહ્યા છો. ફોનના નેટવર્ક પરના ઉપકરણ સુધીની દૂરસ્થ પહોંચ અને પૂર્ણ-ટનલ ઇન્ટરનેટ એક્ઝિટને અલગ ફોરવર્ડિંગ નિયમોની જરૂર છે, અને એક જોઈએ ત્યારે બંને આપવાથી તમે માંગેલી ક્ષમતા ઉમેર્યા વગર જોખમ વધે છે.
વિશેષાધિકાર મોડલ એક પસંદગી છે, root અથવા કંઈ નહીં એવું નથી
kernel TUN ઉપકરણ વાપરતા પરંપરાગત OpenVPN ડેમનને અનુરૂપ ક્ષમતાઓ, ઉપકરણ નોડમાં પ્રવેશ અને Androidની સુરક્ષા નીતિનો સહયોગ જોઈએ. root એ SELinuxમાંથી સર્વગ્રાહી મુક્તિ નથી; વિશેષાધિકાર પ્રાપ્ત પ્રોસેસ પણ પ્લેટફોર્મ નીતિથી મર્યાદિત રહે છે. તેથી જ Linux સર્વર પર સરળતાથી ચાલતું બાઇનરી ફોન પર પરવાનગીઓ વિશે સ્પષ્ટ ભૂલ વગર નિષ્ફળ જઈ શકે છે.
યુઝરસ્પેસ ગેટવે અમલીકરણનું વિશેષાધિકાર મોડલ સંપૂર્ણપણે અલગ હોઈ શકે, તેથી Android પરના દરેક VPN સર્વરને root જોઈએ એ સામાન્ય દાવો ઘણો વિશાળ છે. root તમને વધુ ક્રિયાઓનો પ્રયાસ કરવાની ક્ષમતા આપે છે, તે મંજૂર થશે કે પરિણામ પહોંચપાત્ર હશે તેની ખાતરી નહીં.
Androidની પોતાની VPN-સેવા નોંધણી ફરી એક અલગ પદ્ધતિ છે. તે એપને નિર્ધારિત જીવનચક્ર સાથે સંચાલિત ક્લાયન્ટ ઇન્ટરફેસ આપે છે; તે સામાન્ય સર્વર ઇન્સ્ટોલર નથી, અને ટર્મિનલથી ડેમન શરૂ કરવાથી તેને સતત ચાલુ સંચાલન, પ્રતિ-એપ નીતિ કે પોતાનો રિકવરી માર્ગ મળતો નથી.
જો તમને એક્ઝિટ પોઇન્ટ જોઈએ, તો આર્કિટેક્ચર બદલો
જ્યારે ધ્યેય હાલના OpenVPN પ્રોફાઇલ સાથે સુસંગતતા નહીં, પણ ફક્ત ફોન દ્વારા દૂરસ્થ ઇન્ટરનેટ એક્ઝિટ હોય, ત્યારે સપોર્ટેડ ઓવરલે એક્ઝિટ નોડ વધુ યોગ્ય ડિઝાઇન છે. Tailscale પોતાના નોંધણી, અધિકૃતતા અને ક્લાયન્ટ-પસંદગી પગલાં સાથે Android એક્ઝિટ-નોડ ભૂમિકાનું દસ્તાવેજીકરણ કરે છે.
આ અદલાબદલી વાસ્તવિક છે અને સ્પષ્ટ કહેવા જેવી છે: તમે અલગ પ્રોટોકોલ, અલગ વિશ્વાસ મોડલ અને તે એકાઉન્ટ તથા સંકલન સેવા પર આધાર સ્વીકારો છો. તે બદલ્યા વગરના OpenVPN ક્લાયન્ટને ઓવરલેમાં જોડાવા મજબૂર કરતું નથી, અને તમને જાહેર સરનામા પર OpenVPN લિસનર આપતું નથી.
તૈનાતીને હજી શું જોઈએ
તમે કોઈ પણ માર્ગ પસંદ કરો, ઓપરેશનલ પાયો નક્કી કરે છે કે તે એક અઠવાડિયું ટકશે કે નહીં. સર્વરની ઓળખપત્રો ખાનગી રાખો, અલગ ક્લાયન્ટ ઓળખ જારી કરો, અને જરૂર પડે તે પહેલાં રદ કરવાની યોજના બનાવો. અપડેટ કેવી રીતે આવે છે, બેકગ્રાઉન્ડમાં સેવા શું ચાલુ રાખે છે અને રીબૂટ કે નેટવર્ક ફેરફાર પછી તે કેવી રીતે પુનઃપ્રાપ્ત થાય છે તે નક્કી કરો.
અનુકૂળ લાગતા શોર્ટકટ ટાળો: જૂનું સ્ટેટિક બાઇનરી, હાર્ડકોડેડ ઇન્ટરફેસ નામો, અને હાલની ફાયરવોલ નીતિ ભૂંસી નાખતી સ્ટાર્ટઅપ સ્ક્રિપ્ટ. પછી પરિણામ ફક્ત એક ચોક્કસ પરીક્ષણ પર જ સ્વીકારો: અધિકૃત દૂરસ્થ ક્લાયન્ટ ઇચ્છિત સ્ત્રોત સુધી પહોંચે છે, પ્રતિબંધિત ગંતવ્યો ઉપલબ્ધ નથી રહેતા, અને સપોર્ટેડ જીવનચક્ર ઘટના પછી ઉપકરણ જાતે પાછું આવે છે. root પ્રવેશ તે પરિણામનો એક શક્ય ઘટક છે, અને ભાગ્યે જ નિર્ણાયક.