Android OpenVPN ટનલ સરનામા વિના રૂટ ઉમેરતું નથી
Android OpenVPN ક્લાઇન્ટ ફોન પાસે ટનલ સરનામું ન હોય ત્યાં સુધી રૂટ ઉમેરી શકતા નથી. કોણ તે ફાળવે છે, કયા pull ફિલ્ટર તેને કાઢી નાખે છે અને તમારે ક્યારે જાતે લખવું તે તપાસો.
તમારી Android OpenVPN પ્રોફાઇલ રૂટ ઉમેરી શકતી નથી કારણ કે ફોન પાસે વર્ચ્યુઅલ ઇન્ટરફેસ પર કોઈ સરનામું નથી, તેથી રૂટ કોઈ તરફ ઇશારો કરે તેવું કંઈ નથી. રૂટ ફક્ત એ જવાબ આપે છે કે પેકેટ ક્યાં જવા જોઈએ. ટનલ સરનામું એ જવાબ આપે છે કે ટનલની અંદર ફોન કોણ છે, અને ઇન્ટરફેસ અસ્તિત્વમાં આવે તે પહેલાં ક્લાઇન્ટે એક પૂરું પાડવું જ પડે. નીચેની ચાર તપાસ ક્રમમાં કરો અને પહેલી નિષ્ફળતા પર અટકો, કારણ કે સરનામું હોય તે પહેલાં રૂટ સંપાદિત કરવાથી સાચી સમસ્યા છુપાય છે.
ક્લાઇન્ટ જે ક્રમમાં ચલાવે તે જ ક્રમમાં નિષ્ફળતા વાંચો
Android નું VpnService.Builder બે ખ્યાલોને અલગ રાખે છે: addAddress() એ ઇન્ટરફેસ પર સરનામું મૂકે છે જે એપ બનાવી રહી છે, addRoute() લક્ષ્ય પ્રીફિક્સ ઉમેરે છે, અને establish() ઓછામાં ઓછું એક સરનામું ઉમેરાય ત્યાં સુધી ઇન્ટરફેસ બનાવવાનો ઇનકાર કરે છે. OpenVPN ક્લાઇન્ટ પ્રોફાઇલ અને સર્વર દ્વારા મોકલાયેલા વિકલ્પોને બરાબર એ જ કૉલ્સ પર મેપ કરે છે, તેથી જે કનેક્શન કદી સરનામું પાર્સ કરતું નથી તે ઇન્ટરફેસ જ બનાવી શકતું નથી.
એટલે જ તમે વાંચી રહ્યા છો તે લોગ લાઇન રૂટનું નામ લઈ શકે છે જ્યારે કારણ એક પગલું પહેલાં બેઠું હોય. ક્લાઇન્ટ ઇન્ટરફેસ અસ્તિત્વમાં આવ્યા પછી જ રૂટ તબક્કે પહોંચે છે; સરનામું ન હોય તો રૂટ કૉલ તરત નિષ્ફળ જાય છે અથવા કદી ચાલતો નથી. જ્યારે લોગ કહે કે રૂટ ઉમેરી શકાતો નથી, ત્યારે રૂટ સિન્ટેક્સથી નહીં, સરનામાથી શરૂ કરો.
તપાસ 1: શું સર્વર જવાબમાં સરનામું મૂકે છે?
રૂટેડ OpenVPN સેવા માટે સરનામું સર્વર પૂલમાંથી કે પ્રતિ-ક્લાઇન્ટ ફાળવણીમાંથી આવે છે, અને ટોપોલોજી તેનો આકાર નક્કી કરે છે. OpenVPN 2.4 કે તેથી નવા સર્વર પર, સબનેટ ટોપોલોજીવાળી સેવા આવી દેખાય છે:
topology subnet
server 10.8.0.0 255.255.255.0
client-config-dir ccd
એ આકાર સાથે સર્વર ifconfig 10.8.0.6 255.255.255.0 જેવું કંઈક મોકલે છે. જૂની topology net30 સ્થાપના તેના બદલે પીઅર સરનામું મોકલે છે, ઉદાહરણ તરીકે ifconfig 10.8.0.6 10.8.0.5, તેથી બે મોડેલ વચ્ચે ખસેડાયેલી પ્રોફાઇલ સાચી દેખાઈ શકે છે જ્યારે તે ખોટો નેટમાસ્ક વહન કરે છે.
ક્લાઇન્ટ કનેક્શન લોગમાં મોકલાયેલા વિકલ્પ સેટને શોધો. જો તેમાં ifconfig ની એક પણ લાઇન ન હોય, તો સર્વરે કદી સરનામું મોકલ્યું નથી અથવા ક્લાઇન્ટે વિકલ્પ નકાર્યો છે. જે સર્વર client-config-dir વાપરે છે તેના પર, પ્રમાણપત્રના common name પરથી નામ રાખેલી ફાઇલ અસ્તિત્વમાં હોવી જોઈએ અને ફાળવણી ધરાવવી જોઈએ:
# ccd/phone-anna
ifconfig-push 10.8.0.6 255.255.255.0
તપાસ 2: શું ક્લાઇન્ટને મળેલું સરનામું રાખે છે?
વધારે પડતો પહોળો ફિલ્ટર બીજું સામાન્ય કારણ છે. pull-filter OpenVPN 2.4 અને તેથી નવા સંસ્કરણોમાં છે, અને જ્યારે ઘણા ફિલ્ટર એક જ વિકલ્પ સાથે મેળ ખાય ત્યારે છેલ્લું મેળ ખાતું જીતે છે, તેથી અંતમાં રહેલું catch-all ભૂલ વિના સરનામું દૂર કરી નાખે છે:
# removes every pushed option, including the address
pull-filter ignore "ifconfig"
pull-filter ignore "route"
ફિલ્ટરને તમે ખરેખર દૂર કરવા માંગતા વિકલ્પ સુધી સાંકડું કરો અને સરનામાને અકબંધ રાખો:
# keeps the pushed address, drops one unwanted LAN route
pull-filter ignore "route 10.60.0.0"
બધા pull બંધ કરવાની સલાહ સામાન્ય રીતે એવી વ્યક્તિ તરફથી આવે છે જે એક જ રૂટથી છૂટકારો મેળવવા માંગે છે. route-nopull વધુ સાંકડો સ્વિચ છે: તે ifconfig અને બીજા મોકલાયેલા વિકલ્પો રાખે છે જ્યારે મોકલાયેલા રૂટ અને DHCP જેવા વિકલ્પો નકારે છે. જ્યારે ખરેખર એ જ જોઈએ ત્યારે તે વાપરો, અને સરનામાનો પ્રશ્ન અલગથી જવાબ આપો.
તપાસ 3: સરનામું તમારે લખવાનું છે?
મેન્યુઅલ એડ્રેસિંગ ત્યારે જ વાજબી છે જ્યારે ઓપરેટર તમને મૂલ્ય સોંપે. જો તમે જાતે લખો તો તે VPN ક્લાઇન્ટ સબનેટમાંથી આવવું જોઈએ, સક્રિય સેશનોમાં અનન્ય હોવું જોઈએ અને સર્વર જે ટોપોલોજી ચલાવે છે તેની સાથે મેળ ખાવો જોઈએ. ડેસ્કટોપ બ્રિજ કે દૂરના LAN પરના હોસ્ટનું સરનામું નકલ કરવું બંને રીતે નિષ્ફળ જાય છે: ફોન એવા સરનામાનો દાવો કરશે જે પહેલેથી બીજે ક્યાંય છે, અને ગેટવે પાસે તેનો પરત માર્ગ રહેશે નહીં.
રૂટમાં દૂરના LANનું પ્રીફિક્સ લક્ષ્ય છે, કદી ફોનની ઓળખ નહીં. 10.60.0.0/24 માટેનો રૂટ કહે છે કે ટનલ દ્વારા એ નેટવર્ક સુધી પહોંચો; તે એ કહેતું નથી કે ફોન પાસે કયું 10.60.0.x સરનામું હોવું જોઈએ, અને ફોન પાસે તેમાંથી એક પણ ન હોવું જોઈએ. સ્થિર ફાળવણીઓ સર્વર બાજુની હોય છે, જ્યાં તે ગતિશીલ પૂલ સાથે અથડાઈ શકતી નથી.
એક ઓળખ પર બે સેશન એ જ અથડામણ ઉજાગર કરે છે. જો એ જ પ્રમાણપત્ર બે વાર જોડાય અને સર્વર બંનેને એક નિશ્ચિત સરનામું મોકલે, તો બીજું સેશન પહેલાનું નકલ બની જાય છે, અને ઉકેલ ક્લાઇન્ટ બાજુનું સંપાદન નહીં પણ અલગ ઓળખ કે અલગ ફાળવણી છે.
તપાસ 4: શું બીજું કંઈ ટનલ સ્લોટ ધરાવે છે?
Android એક સમયે ફક્ત એક જ સક્રિય VPN સેવાને મંજૂરી આપે છે. બીજી VPN એપ, અથવા હવે કામ ન કરતી પ્રોફાઇલ માટે ચાલુ રહેલી always-on VPN એન્ટ્રી, તમારો OpenVPN ક્લાઇન્ટ establish() ને કૉલ કરે તે પહેલાં એ સ્લોટ લઈ શકે છે. પછી પ્રોફાઇલ માન્ય હોવા છતાં ઇન્ટરફેસ કદી દેખાતું નથી, તેથી બીજી VPN ડિસ્કનેક્ટ કરો, always-on સેટિંગ બંધ કરો અને પ્રોફાઇલને સ્પર્શ કરતા પહેલાં ફરી જોડાઓ.
ઇથરનેટ બ્રિજિંગ પર ભાર મૂકતી સેવા બીજી બંધ ગલી છે. root વગરની Android એપ IP ટનલ બનાવી શકે છે, બ્રિજ કરેલો ઇથરનેટ સેગમેન્ટ નહીં, તેથી તમે લખો તે કોઈ સરનામું dev tap સર્વરને કામ કરાવશે નહીં; ઓપરેટરે રૂટેડ સેવા આપવી પડશે. સમસ્યા જણાવતી વખતે ક્લાઇન્ટનું નામ અને આવૃત્તિ, મોકલાયેલો વિકલ્પ સેટ, ટોપોલોજી અને સરનામું જ્યાં દેખાવું જોઈએ તે ચોક્કસ પગલું સામેલ કરો.
જો ચારેય તપાસ પસાર થાય અને સરનામું હાજર, અનન્ય અને યોગ્ય રીતે માસ્ક કરેલું હોય, તો રૂટનો પ્રશ્ન સામાન્ય બની જાય છે: સર્વર કયા પ્રીફિક્સને અધિકૃત કરે છે અને ક્લાઇન્ટે તેમને કેવી રીતે સીમિત કરવા. બીજું કંઈ બદલતા પહેલાં ટનલ સરનામું, તેનો નેટમાસ્ક અને ટોપોલોજી લખી રાખો, કારણ કે એ ત્રણ મૂલ્યો જ ઓપરેટરને સર્વરના દૃશ્ય સાથે સરખાવવા જોઈએ.