Android OpenVPN: ફોનને રૂટ કર્યા વિના ખાનગી રૂટ ઉમેરો
Android ખરેખર જે પ્રોફાઇલ લોડ કરે છે તેમાં એક રૂટ ઉમેરો, પછી તપાસો કે સર્વર તેને મંજૂરી આપે છે. સંપાદન, ફરીથી કનેક્ટ અને ચાર ચકાસણી માટેની માર્ગદર્શિકા.
તમારે વધુ એક ખાનગી સબનેટની જરૂર છે — કહો 10.60.0.0/24 — જે પ્રોફાઇલમાં હાલમાં નથી. લેપટોપ પર તમે રૂટ ઉમેરીને આગળ વધો છો. Android માં VPN એક એપ છે, tun ઉપકરણ તે એપનું છે, અને root વિના સંપાદિત કરવા માટે કોઈ રૂટિંગ ટેબલ નથી. રૂટ તો હોવો જ જોઈએ, પણ તે ક્લાઇન્ટ જે પ્રોફાઇલ લોડ કરે છે તેમાં જાય છે, અને તે ત્યારે જ કામ કરે છે જ્યારે સામેની બાજુ સહમત હોય. અહીં સંપાદન, ફરીથી કનેક્ટ, સર્વર બાજુ અને રોલબેક છે.
સંપાદન પહેલાં: રૂટ શું કરી શકે અને શું ન કરી શકે
રૂટ એક પ્રશ્નનો જવાબ આપે છે: આ ગંતવ્ય માટેનો ટ્રાફિક કઈ ઇન્ટરફેસ લઈ જાય. તે કંઈપણ અધિકૃત કરતું નથી. જો નેટવર્કના માલિકે સહેમતી ન આપી હોય કે આ ફોન તે સબનેટ સુધી પહોંચી શકે, તો સાચો રૂટ સાચો દેખાતો કન્ફિગ અને ગેટવે પર શાંત ડ્રોપ ઉત્પન્ન કરે છે, અને તમે આગલો કલાક ખોટી ફાઇલ સંપાદિત કરવામાં પસાર કરશો.
પહેલાં તે સહેમતી મેળવો, નેટવર્કનો માલિક હોય તો લેખિતમાં. પછી નોંધો કે તમે શું નથી કરી રહ્યા: તમે ફોનને તે LAN ની અંદર સરનામું આપતા નથી, સર્વરનું લિસનર બદલતા નથી, અને હોસ્ટનામ દ્વારા સાઇટ પસંદ કરતા નથી. આ ચાર અલગ ફેરફારો છે અને ફક્ત પહેલો તમારો છે.
| The route gives you | The route does not give you |
|---|---|
| A destination prefix associated with the tunnel | Permission to forward at the gateway |
| A path for the phone's own traffic | A return route on the target host |
| A scope for the client's virtual interface | A name in DNS, or HTTPS identity |
ક્લાઇન્ટ ખરેખર જે પ્રોફાઇલ લોડ કરે છે તેને સંપાદિત કરો
સામાન્ય OpenVPN વિકલ્પ ટેક્સ્ટ આયાત કરતા સુસંગત ક્લાઇન્ટ માટે, ઉમેરો એક લીટી છે:
route 10.60.0.0 255.255.255.0તેને પ્રોફાઇલના મુખ્ય ભાગમાં, અન્ય રૂટિંગ સૂચનાઓની નજીક ઉમેરો, અને ઓપરેટરનું endpoint, પ્રમાણપત્રો, કી હેન્ડલિંગ અને ચકાસણીની લીટીઓ જેવી હતી તેવી જ રાખો. એક લીટી ઉધાર લેવા માટે આખું જૂનું ઉદાહરણ પેસ્ટ ન કરો: કમ્પ્રેશન, સંપૂર્ણ ફાઇલ પાથ અને જૂની cipher સેટિંગ્સ તેની સાથે આવે છે અને અલગ ડિબગિંગ સેશનનો ખર્ચ કરાવશે.
લોકો જે પગલું ચૂકી જાય છે તે ફાઇલની માલિકી છે. જો એપે પ્રોફાઇલ આયાત કર્યું હોય, તો તે જે કોપી વાપરે છે તે એપની છે, અને ડાઉનલોડ કરેલું મૂળ સંપાદિત કરવાથી કંઈ બદલાતું નથી. ક્લાઇન્ટના સમર્થિત એડિટરનો ઉપયોગ કરો, અથવા સંપાદિત ફાઇલને અપડેટ માર્ગે ફરીથી આયાત કરો, અને સમાન નામો ઘણા હોય તો સક્રિય પ્રોફાઇલનું નામ ખાતરી કરો. તમે કઈ બદલી તે નોંધો.
જો પ્રોફાઇલમાં પહેલેથી route-nopull હોય, તો સર્વરથી કોઈ રૂટ ઇન્સ્ટોલ થતો નથી અને ફોનને જરૂરી દરેક પ્રીફિક્સ સ્પષ્ટ રીતે સૂચિબદ્ધ કરવું પડે છે. તે કાયદેસર ડિઝાઇન છે, પણ તેનો અર્થ એ છે કે ચૂકી ગયેલી લીટી સર્વરના ઇનકાર જેવી જ દેખાય છે.
ફરીથી કનેક્ટ કરો અને ઉપકરણ પર ચકાસો
પહેલા ડિસ્કનેક્ટ કરો, પછી એપને છેલ્લું સેશન પુનઃસ્થાપિત કરવા દેવાને બદલે તમે સંપાદિત કરેલી તે ચોક્કસ પ્રોફાઇલ ફરીથી કનેક્ટ કરો. કનેક્શન લોગ ખોલો અને ખાતરી કરો કે ક્લાઇન્ટે નવી લીટી પાર્સ કરી છે; ફ્રન્ટએન્ડ અવગણે એવી રૂટ સૂચના ખોટી કોપી સંપાદિત કરવાનું સામાન્ય પરિણામ છે.
ગંતવ્યને નામથી નહીં, સરનામાથી ચકાસો. એક જાણીતા સેવા પોર્ટ પર TCP ચેક ping કરતાં વધુ માહિતી આપે છે, કારણ કે ઘણા હોસ્ટ ICMP નો જવાબ આપે છે જ્યારે સેવા પોર્ટ ફિલ્ટર થયેલો હોય છે. જો સરનામું જવાબ આપે અને નામ ન આપે, તો તમારો પ્રશ્ન રિઝોલ્વરનો છે, રૂટિંગનો નહીં, અને આગળનો વિભાગ તમારા માટે નથી.
અહીં બે સ્કોપ ચકાસણી પણ આવે છે. પર-એપ VPN નો અર્થ એ છે કે સરનામા રૂટ હાજર હોઈ શકે જ્યારે તમે જે એપ સાથે ચકાસી રહ્યા છો તે સમાવિષ્ટ સેટની બહાર હોય, તેથી ખરેખર અંદર હોય એવી એપ સાથે ચકાસો. અને IPv4 પ્રીફિક્સ IPv6 માર્ગ વિશે કંઈ કહેતું નથી; જો સેવા dual-stack હોય, તો અનુરૂપ IPv6 રૂટ ઉમેરો અથવા અપેક્ષા રાખો કે ક્લાઇન્ટ તમે ઇચ્છ્યો ન હતો તેવો માર્ગ પસંદ કરશે.
એક નકારાત્મક પરિણામ વહેલો ઓળખવો યોગ્ય છે: જો full-tunnel રૂટ પહેલેથી 0.0.0.0/0 આવરી લે છે, તો પ્રીફિક્સ ખૂટતું નથી અને તેને ફરીથી ઉમેરવાથી કંઈ બદલાતું નથી. બમણું આવરણ સર્વર બાજુના ઇનકાર કે ખૂટતા જવાબને સુધારતું નથી.
સર્વર પર માર્ગ પૂરો કરો
ફોનની બહાર ત્રણ વસ્તુઓ સાચી હોવી જોઈએ. ગેટવેને ગંતવ્ય સુધીનો રૂટ અને ફોનના સ્રોતને તે તરફ ફોરવર્ડ કરવાની પરવાનગી જોઈએ. લક્ષ્યે તે સ્રોત સ્વીકારી ગેટવે દ્વારા જવાબો પાછા મોકલવા જોઈએ, અથવા ડિઝાઇનને egress પર જાણી જોઈને અનુવાદની જરૂર છે. OpenVPN મેન્યુઅલનો route વિકલ્પ ક્લાઇન્ટ બાજુની સૂચના આવરે છે; ફોરવર્ડિંગ અને રિટર્ન રૂટિંગ અલગ મશીનો પર અલગ સેટિંગ્સ છે.
જો ગંતવ્ય ગેટવેની સીધા પાછળ નહીં પણ બીજા VPN ક્લાઇન્ટ પાછળ હોય, તો સર્વરને તે પીઅરના સબનેટ માટે iroute જોઈએ. તે સૂચના સર્વરની માલિકીની છે અને જણાવે છે કે કયો ક્લાઇન્ટ પ્રીફિક્સનો માલિક છે; ફોન તેને પોતાની પ્રોફાઇલમાંથી આપી શકતો નથી, અને ક્લાઇન્ટ બાજુનું કોઈ પણ સંપાદન તેનો વિકલ્પ નથી.
રિટર્ન માર્ગ સ્પષ્ટ રીતે ચકાસો. ટનલને બદલે ડિફોલ્ટ રૂટથી નીકળતો જવાબ ક્લાસિક અડધું-ખુલ્લું લક્ષણ ઉત્પન્ન કરે છે: કનેક્શન એક દિશામાં સ્થપાય છે અને કંઈ પાછું આવતું નથી. લક્ષ્ય પાછું રૂટ કરી શકતું ન હોય ત્યારે ગેટવે પર સ્રોત અનુવાદ કાયદેસર સુધારો છે, પણ તે પોતાના પરિણામો સાથેનો નીતિ નિર્ણય છે.
રોલબેક અને સ્વીકૃતિ
સંપાદન પહેલાં અગાઉની પ્રોફાઇલ રાખો. જો ફેરફાર વસ્તુઓ વધુ ખરાબ કરે, તો તે કોપીને એ જ ફરીઆયાત માર્ગે પુનઃસ્થાપિત કરો, ફરીથી કનેક્ટ કરો, અને જૂનું વર્તન પાછું આવે તેની ખાતરી કરો — તે ખાતરી આપે છે કે તમે જે બદલ્યું તે જ તમે માન્યું હતું. જે રોલબેક જૂની સ્થિતિ પાછી લાવતું નથી તેનો અર્થ એ છે કે એપ પાસે ત્રીજી કોપી છે જે તમને મળી નથી.
જ્યારે ચાર વસ્તુઓ સાચી હોય ત્યારે ફેરફાર સ્વીકારો, નવા કનેક્શન પછી આ ક્રમમાં ચકાસીને: ગંતવ્ય તેના સેવા પોર્ટ પર જવાબ આપે છે, અપેક્ષિત હોય તો ખાનગી નામ રિઝોલ્વ થાય છે, HTTPS હજી ઇચ્છિત હોસ્ટનામ માન્ય કરે છે, અને રીબૂટ કે Wi-Fi થી સેલ્યુલર પર જવા પછી પણ બધું કામ કરે છે. છેલ્લી ચકાસણી એ છે જે એવો રૂટ પકડે છે જે ફક્ત ત્યાં સુધી જ હોય છે જ્યાં સુધી Android ટનલ ફરીથી સ્થાપિત કરે.
- કંઈપણ સંપાદિત કરતા પહેલાં ખાતરી કરો કે નેટવર્કનો માલિક ગંતવ્યને મંજૂરી આપે છે.
- ક્લાઇન્ટ જે પ્રોફાઇલ લોડ કરે છે તેમાં રૂટ મૂકો, પછી ફરીથી આયાત કરો અને ફરીથી કનેક્ટ કરો.
- યોગ્ય સરનામા કુટુંબ માટે, પર-એપ સ્કોપની અંદર, સેવા પોર્ટ દ્વારા ચકાસો.
- ફોરવર્ડિંગ, રિટર્ન રૂટિંગ અને iroute સર્વર પર સુધારો, ફોન પર નહીં.
- રોલબેક કોપી રાખો, અને રીબૂટ પછી ફરીથી ચકાસો.