Android VPN routinga: politika-arauak main taularen aurretik

Androiden main taulara gehitzen den ibilbide bat zuzena dirudi zerrenda guztietan, eta hala ere ez du trafikoa eramaten. Arrazoia da main taula hainbat aukeren artean bat dela, eta ez zaiola lehenengo kontsultatzen. Androiden sare-zerbitzuak politika-arauak eraikitzen ditu, routing taula bat aukeratzen dutenak helburuko helbideak eduki ez dituen informazioarekin — aplikazioaren uida, paketean marka bat, iritsi zen interfazea — eta helburuaren bilaketa geroago gertatzen da, arau horiek aukeratu zuten taularen barruan.

Hiru erabaki ordena finkoan

Irten doan pakete batek hiru erabaki bereizi hartzen ditu. Lehenik, politika-arau batek zehazten du zein routing taula aplikatzen den. Bigarrenik, taula horren barruko ibilbide batek hurrengo jauzia eta irteerako interfazea zehazten ditu. Hirugarrenik, netfilter kakoek erabakitzen dute paketea bizirik irauten duen, aldatzen den edo birbideratzen den.

Ordenak garrantzia du, etapa bakoitzak bere galderari bakarrik erantzun baitiezaioke. Pakete bat onartzen duen suebaki-arau batek ez du taula bat aukeratzen, eta inongo arulek aukeratzen ez duen taula batera gehitutako ibilbidea inertea da. Android VPNen inguruko nahasmen handia hiruretako bat konpondu eta aldaketarik ez ikustetik dator, hutsegitea beste batean zegoelako.

Markak eremu bildua dira, ez duzun etiketa bat

Androidek hainbat gertaera marka-balio berean biltzen ditu: zein sare aukeratu zen, aplikazio batek sare bat berariaz aukeratu zuen ala ez, socket bat VPNtik babestuta dagoen ala ez, eta baimenei lotutako bitak. AOSPren fwmark goiburuak uneko zuhaitzerako diseinu hori definitzen du, eta diseinua plataformaren barneko kontua da, bertsioen artean aldatzen dena.

Horregatik da arriskutsua Androiden marka-balio oso bat idaztea iptables -j MARK --set-mark erabiliz. Ez du etiketa bat gehitzen; sistemak jada egin zuen sare-hautaketa ordezten du. Orduan paketea beste arau batzuekin bat egiten da, eta horrek VPNa lanean hasi dela edo erlaziorik gabeko aplikazio batek konexioa galdu duela dirudi, gainidatzitako biten arabera.

Markak ukitu behar badituzu, irakurri lehenik uneko balioa eta erabili maskara bat, ulertzen dituzun bitak bakarrik alda daitezen:

ip rule show
ip route show table all | head -40
ip route get 10.20.4.11

Konexio-marka bat pakete-marka batetik bereizitako objektua da, eta ez bata ez bestea ez dira ibilbide bat. Erantzun-paketeetan marka leheneratzea irteeran taula bat aukeratzeaz beste urrats bat da, eta horregatik norabide bakarreko konponketek irekitzen diren eta gero zintzilikatzen diren konexioak sortzen dituzte.

Nork du arauen eta taulen jabetza

Androiden sare-zerbitzuak, netdek, arauak eta sare bakoitzeko taulak sortzen ditu. AOSP RouteController da arau horiek VPNetarako, sare fisikoetarako eta uid tarteetarako muntatzen diren tokia, eta haren bizi-zikloa sare-gertaerei lotuta dago, ez konfigurazio-fitxategi bati.

Bi ondorio datoz. Lehenik, telefono batean aurkitzen dituzun lehentasunak eta taula-zenbakiak eraikuntzaren barneko xehetasunak dira, ez interfaze bat: beste Android bertsio batean berdin diruditen zenbakiek erabat beste zerbait esan dezakete. Bigarrenik, egoera berreraiki egiten da sareak aldatzen direnean, beraz gaur root shell batetik txertatutako arau bat desagertuta egon daiteke hurrengo Wi-Fi aldaketaren ondoren.

Desagerpen hori sarritan sistemak ibilbide bat baztertzen duela jakinarazten da. Benetan gertatu dena da taula aukeratzen zuen araua ez dela existitzen jada, eta taularen barruko ibilbidea ezinezkoa da orain paketearen ikuspegitik. Egiaztatu arauen zerrenda, ez ibilbideen zerrenda, konfigurazio batek berriz konektatu ondoren funtzionatzeari uzten dionean.

Kakoen ordenari buruzko galderak ez du erantzun orokorrik

iptables VPNen routingaren aurretik exekutatzen den ala ez ezin da erantzun paketearen bidea izendatu gabe. Bertan sortutako pakete bat output kakotik igarotzen da, eta han marka-aldaketa batek berrouting egiaztapena eragiten du — bigarren bilaketa bat, ez lehenengoaren atzeraeraginezko aldaketa. Tethering bidez konektatutako bezero batetik datorren paketea prerouting bidetik igarotzen da eta, horren ordez, birbidali egiten da, eta hura ikusten duten kateak beste batzuk dira.

Beraz, arau bera eraginkorra izan daiteke aplikazio baten trafikorako eta ikusezina tethering trafikorako, eta zeroan geratzen den kontagailu batek paketeak zein bide hartu zuen esaten dizu, ez araua oker dagoen ala ez. Erabili kontagailuak bidea zehazteko bat-etortze baldintzaren bat aldatu aurretik.

Hau da, halaber, politika-routing hutsegitea ikusteko zaila bihurtzen den etapa. Badagoen baina helburua ez duen taula batera routatzeak sare eskuragaitza sortzen du, suebakiaren bazterketa baten antza duena, eta suebakiaren bazterketa batek routing zulo beltz baten antza duen denbora-muga sortzen du.

Diagnostikatu sistemaren barruan, edo utzi bakean

Baimendutako berrikuspen bat egiteko, ezarri lau gertaera ezer ukitu aurretik: aplikazioaren uida eta profila, Androidek hartarako aukeratu zuen sarea, VPNak aplikazio hori barne hartzen duen ala ez, eta arazoa helbide-familia bietan existitzen den ala ez. Aplikazioko kanporatze batek asko azaltzen du VPNa ez dabil txostenik routing hutsegiterik gabe.

Ondoren irakurri benetan indarrean dauden arauak, maskarak eta taulak, eta eduki sare-aldaketa bat behaketa-leihoaren barruan. Portaera berriz konektatzean aldatzen bada, kudeatutako bizi-ziklo bat ikusten ari zara, ez falta den ibilbide bat.

Ohiko eskakizunetarako, erabili onartutako kontrolak: aplikazioko barne hartzea eta kanporatzea VPN aplikazioan, eta plataformaren beraren sare-hautaketa bide zehatz bat behar duen ororentzat. Integrazio pribilegiatu batek routing makineriaz benetan elkarlanean aritu behar badu, zuk onartzen duzun Android bertsio zehatzaren inplementazioa hartu helburutzat eta mantendu haren bizi-zikloa hura duen osagaiaren bidez. Plataformaren kateak garbitzeak edo lehentasun handiko arau bat txertatzeak diagnostiko bat bigarren sare-kudeatzaile bihurtzen du, eta telefonak horren arabera jokatuko du.