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 പതിപ്പിന്റെ നടപ്പാക്കലിനെ ലക്ഷ്യമിടുക, അതിന്റെ ഉടമയായ ഘടകത്തിലൂടെ അതിന്റെ ജീവിതചക്രം നിലനിർത്തുക. പ്ലാറ്റ്‌ഫോം ചെയിനുകൾ ഫ്ലഷ് ചെയ്യുന്നതോ ഉയർന്ന മുൻഗണനയുള്ള ഒരു നിയമം ചേർക്കുന്നതോ ഡയഗ്നോസിസിനെ രണ്ടാമത്തെ നെറ്റ്‌വർക്ക് മാനേജറാക്കി മാറ്റുന്നു, ഫോൺ അതനുസരിച്ച് പെരുമാറും.