Android VPN રાઉટિંગ: main ટેબલ પહેલાં નીતિ-નિયમો
Android કોઈપણ ગંતવ્ય શોધ પહેલાં uid અને નિશાની નિયમોથી રાઉટિંગ ટેબલ પસંદ કરે છે, તેથી main માં ઉમેરાયેલો રૂટ કદાચ ક્યારેય તપાસાય નહીં.
Android પર main ટેબલમાં ઉમેરાયેલો રૂટ દરેક યાદીમાં સાચો દેખાય છે અને છતાં ટ્રાફિક વહન કરતો નથી. કારણ એ છે કે main ટેબલ ઘણા વિકલ્પોમાંથી એક છે, અને તેને પહેલા પૂછવામાં આવતું નથી. Android ની નેટવર્કિંગ સેવા એવા નીતિ-નિયમો બનાવે છે જે ગંતવ્ય સરનામામાં ન હોય તેવી માહિતીથી રાઉટિંગ ટેબલ પસંદ કરે છે — એપ્લિકેશનનું uid, પેકેટ પરની નિશાની, જે ઇન્ટરફેસ પરથી તે આવ્યું — અને ગંતવ્યની શોધ પછી થાય છે, તે ટેબલની અંદર જે તે નિયમોએ પસંદ કર્યું હોય.
નિશ્ચિત ક્રમમાં ત્રણ નિર્ણયો
બહાર જતું પેકેટ ત્રણ અલગ નિર્ણયો લે છે. પ્રથમ, એક નીતિ-નિયમ નક્કી કરે છે કે કયું રાઉટિંગ ટેબલ લાગુ પડે છે. બીજું, તે ટેબલની અંદરનો રૂટ આગલો હોપ અને આઉટગોઇંગ ઇન્ટરફેસ નક્કી કરે છે. ત્રીજું, netfilter હૂક નક્કી કરે છે કે પેકેટ ટકી રહે છે, બદલાય છે કે રીડાયરેક્ટ થાય છે.
ક્રમ મહત્વનો છે કારણ કે દરેક તબક્કો ફક્ત પોતાના પ્રશ્નનો જ જવાબ આપી શકે છે. પેકેટ સ્વીકારતો ફાયરવોલ નિયમ ટેબલ પસંદ કરતો નથી, અને જે ટેબલને કોઈ નિયમ પસંદ કરતું નથી તેમાં ઉમેરાયેલો રૂટ નિષ્ક્રિય રહે છે. Android VPN અંગેની મોટા ભાગની ગૂંચવણ ત્રણમાંથી એક સુધારીને કોઈ ફેરફાર ન દેખાવાથી આવે છે, કારણ કે ખામી બીજામાં હતી.
| Stage | Selector | What it cannot decide |
|---|---|---|
| Policy rule | uid range, mark, incoming interface | Which route exists inside the table |
| Route lookup | Destination prefix, longest match | Whether the packet is allowed out |
| Netfilter hook | Chain position, match conditions | Which table was selected |
નિશાનીઓ પેક કરેલું ક્ષેત્ર છે, તમારી માલિકીનું લેબલ નહીં
Android ઘણી હકીકતોને એક જ નિશાની-મૂલ્યમાં પેક કરે છે: કયું નેટવર્ક પસંદ થયું, એપ્લિકેશને સ્પષ્ટપણે નેટવર્ક પસંદ કર્યું કે નહીં, સોકેટ VPN થી સુરક્ષિત છે કે નહીં, અને પરવાનગી સંબંધિત બિટ્સ. AOSP નું fwmark હેડર વર્તમાન ટ્રી માટે તે લેઆઉટ વ્યાખ્યાયિત કરે છે, અને લેઆઉટ પ્લેટફોર્મની આંતરિક બાબત છે જે રિલીઝ વચ્ચે બદલાય છે.
તેથી જ Android પર iptables -j MARK --set-mark થી આખું નિશાની-મૂલ્ય લખવું જોખમી છે. તે ટેગ ઉમેરતું નથી; તે સિસ્ટમે પહેલેથી કરેલી નેટવર્ક પસંદગીને બદલી નાખે છે. પછી પેકેટ અલગ નિયમો સાથે મેળ ખાય છે, જે કયા બિટ્સ ફરીથી લખાયા તેના આધારે VPN કામ શરૂ કરી ગયું હોય કે અસંબંધિત એપ્લિકેશને કનેક્ટિવિટી ગુમાવી હોય તેવું લાગી શકે છે.
જો નિશાનીઓને સ્પર્શવું જ પડે, તો પહેલા વર્તમાન મૂલ્ય વાંચો અને માસ્ક વાપરો જેથી ફક્ત તમે સમજો તે બિટ્સ બદલાય:
ip rule show
ip route show table all | head -40
ip route get 10.20.4.11કનેક્શન નિશાની પેકેટ નિશાનીથી અલગ ઑબ્જેક્ટ છે, અને બંમાંથી કોઈ રૂટ નથી. જવાબી પેકેટો પર નિશાની પુનઃસ્થાપિત કરવી એ બહાર જતી વખતે ટેબલ પસંદ કરવાથી અલગ પગલું છે, તેથી જ એકદિશીય સુધારા એવા કનેક્શન બનાવે છે જે ખૂલે અને પછી અટકી જાય.
નિયમો અને ટેબલોનો માલિક કોણ છે
Android ની નેટવર્ક સેવા, netd, નિયમો અને પ્રતિ-નેટવર્ક ટેબલો બનાવે છે. AOSP RouteController એ સ્થળ છે જ્યાં VPN, ભૌતિક નેટવર્ક અને uid રેન્જ માટે તે નિયમો એસેમ્બલ થાય છે, અને તેનું જીવનચક્ર કોન્ફિગ ફાઇલ સાથે નહીં પણ નેટવર્ક ઘટનાઓ સાથે જોડાયેલું છે.
બે પરિણામો આવે છે. પ્રથમ, એક હેન્ડસેટ પર મળતી પ્રાથમિકતાઓ અને ટેબલ નંબરો બિલ્ડની આંતરિક બાબતો છે, ઇન્ટરફેસ નહીં: બીજી Android આવૃત્તિ પર એકસરખા દેખાતા નંબરો સાવ બીજું કંઈક અર્થ ધરાવી શકે છે. બીજું, નેટવર્ક બદલાવા પર સ્થિતિ ફરી બને છે, તેથી આજે root શેલમાંથી ઉમેરાયેલો નિયમ આગલા Wi-Fi પરિવર્તન પછી ગાયબ હોઈ શકે છે.
આ અદૃશ્યતા ઘણી વાર એમ જણાવાય છે કે સિસ્ટમ રૂટને અવગણે છે. ખરેખર જે થયું તે એ કે જે નિયમ ટેબલ પસંદ કરતો હતો તે હવે અસ્તિત્વમાં નથી, અને ટેબલની અંદરનો રૂટ હવે પેકેટની દૃષ્ટિએ અગમ્ય છે. જ્યારે કામ કરતું કોન્ફિગરેશન ફરી જોડાણ પછી કામ કરવાનું બંધ કરે, ત્યારે રૂટ યાદી નહીં, નિયમ યાદી તપાસો.
હૂક ક્રમના પ્રશ્નોનો સાર્વત્રિક જવાબ નથી
iptables VPN રાઉટિંગ પહેલા ચાલે છે કે નહીં એ પ્રશ્ન પેકેટનો માર્ગ જણાવ્યા વિના જવાબ નથી. સ્થાનિક રીતે બનેલું પેકેટ output હૂકમાંથી પસાર થાય છે, જ્યાં નિશાનીમાં ફેરફાર પુનઃરાઉટિંગ તપાસ પેદા કરે છે — બીજી શોધ, પહેલીનું પાછળથી સંપાદન નહીં. tether કરેલા ક્લાયન્ટથી આવતું પેકેટ prerouting માર્ગે જાય છે અને તેના બદલે ફોરવર્ડ થાય છે, અને તેને જોતી ચેઇન અલગ હોય છે.
તેથી એક જ નિયમ એપ્લિકેશનના ટ્રાફિક માટે અસરકારક અને tether ટ્રાફિક માટે અદૃશ્ય હોઈ શકે છે, અને શૂન્ય પર રહેતું કાઉન્ટર તમને કહે છે કે પેકેટ કયો માર્ગ લીધો, નિયમ ખોટો છે કે નહીં તે નહીં. કોઈપણ મેચ શરત બદલતા પહેલા કાઉન્ટરથી માર્ગ નક્કી કરો.
આ તે તબક્કો પણ છે જ્યાં નીતિ-રાઉટિંગની ભૂલ જોવી મુશ્કેલ બને છે. જે ટેબલ અસ્તિત્વમાં છે પણ ગંતવ્ય ધરાવતું નથી તેમાં રાઉટ કરવાથી નેટવર્ક અગમ્ય આવે છે જે ફાયરવોલ ડ્રોપ જેવું લાગે છે, જ્યારે ફાયરવોલ ડ્રોપ ટાઇમઆઉટ પેદા કરે છે જે રાઉટિંગ બ્લેક હોલ જેવું લાગે છે.
સિસ્ટમની અંદર નિદાન કરો, અથવા તેને છોડી દો
અધિકૃત સમીક્ષા માટે, કંઈપણ સ્પર્શતા પહેલા ચાર હકીકતો સ્થાપિત કરો: એપ્લિકેશનનું uid અને પ્રોફાઇલ, Android એ તેના માટે પસંદ કરેલું નેટવર્ક, VPN તે એપ્લિકેશનને સમાવે છે કે નહીં, અને સમસ્યા બંને સરનામા પરિવારોમાં છે કે નહીં. પ્રતિ-એપ્લિકેશન બાકાત કોઈપણ રાઉટિંગ ખામી વિના VPN કામ કરતું નથી તેવા ઘણા રિપોર્ટ સમજાવે છે.
પછી ખરેખર અમલમાં હોય તેવા નિયમો, માસ્ક અને ટેબલો વાંચો, અને અવલોકન વિન્ડોમાં નેટવર્ક ફેરબદલ રાખો. જો ફરી જોડાણ દરમિયાન વર્તન બદલાય, તો તમે સંચાલિત જીવનચક્ર જોઈ રહ્યા છો, ખૂટતો રૂટ નહીં.
સામાન્ય જરૂરિયાતો માટે સમર્થિત નિયંત્રણો વાપરો: પ્રતિ-એપ્લિકેશન સમાવેશ અને બાકાત VPN એપ્લિકેશનમાં, અને ચોક્કસ માર્ગ જોઈતી કોઈપણ વસ્તુ માટે પ્લેટફોર્મની પોતાની નેટવર્ક પસંદગી. જો વિશેષાધિકાર પ્રાપ્ત ઇન્ટિગ્રેશનને ખરેખર રાઉટિંગ મશીનરી સાથે સહકાર કરવો પડે, તો તમે સમર્થન આપો તે ચોક્કસ Android આવૃત્તિના અમલીકરણને લક્ષ્ય બનાવો અને તેના માલિક ઘટક દ્વારા તેનું જીવનચક્ર જાળવો. પ્લેટફોર્મ ચેઇન ફ્લશ કરવી કે ઊંચી પ્રાથમિકતાનો નિયમ દાખલ કરવો નિદાનને બીજા નેટવર્ક મેનેજરમાં ફેરવે છે, અને ફોન તે મુજબ વર્તશે.