Rrugëtimi VPN në Android: rregullat e politikës përpara tabelës main

Një rrugë e shtuar në tabelën main në Android duket e saktë në çdo listim dhe përsëri nuk e mbart trafikun. Arsyeja është se tabela main është vetëm një opsion midis disave, dhe nuk pyetet e para. Shërbimi i rrjetit i Android ndërton rregulla politike që zgjedhin një tabelë rrugëtimi duke përdorur informacion që adresa e destinacionit nuk e përmban — uid i aplikacionit, një shenjë në paketë, ndërfaqja nga e cila mbërriti — dhe kërkimi i destinacionit ndodh më pas, brenda tabelës që zgjodhën ato rregulla.

Tre vendime në një rend fiks

Një paketë në dalje merr tre vendime të ndara. Së pari, një rregull politike përcakton cila tabelë rrugëtimi zbatohet. Së dyti, një rrugë brenda asaj tabele përcakton hapin tjetër dhe ndërfaqen e daljes. Së treti, grepat e netfilter vendosin nëse paketa mbijeton, modifikohet ose ridrejtohet.

Rendi ka rëndësi sepse çdo fazë mund t'i përgjigjet vetëm pyetjes së vet. Një rregull muri zjarri që pranon një paketë nuk zgjedh tabelë, dhe një rrugë e shtuar në një tabelë që asnjë rregull nuk e zgjedh është inerte. Pjesa më e madhe e konfuzionit rreth VPN-ve në Android vjen nga rregullimi i njërës prej të treve dhe mosvërejtja e ndryshimit, sepse defekti ishte në një tjetër.

Shenjat janë një fushë e paketuar, jo një etiketë që ju zotëroni

Android paketon disa fakte në të njëjtën vlerë shenje: cila rrjet u zgjodh, nëse një aplikacion zgjodhi në mënyrë të shprehur një rrjet, nëse një socket mbrohet nga VPN dhe bitet që lidhen me lejet. Koka fwmark e AOSP përcakton atë plan për pemën aktuale, dhe plani është një hollësi e brendshme e platformës që ndryshon midis versioneve.

Për këtë arsye është e rrezikshme në Android të shkruash një vlerë të plotë shenje me iptables -j MARK --set-mark. Ajo nuk shton një etiketë; zëvendëson zgjedhjen e rrjetit që sistemi ka bërë tashmë. Paketa pastaj përputhet me rregulla të tjera, gjë që mund të duket sikur VPN filloi të funksionojë, ose sikur një aplikacion i palidhur humbi lidhjen, në varësi të biteve të mbishkruara.

Nëse duhet t'i prekni shenjat, lexoni fillimisht vlerën aktuale dhe përdorni një maskë, që të ndryshojnë vetëm bitet që kuptoni:

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

Shenja e lidhjes është një objekt i veçantë nga shenja e paketës, dhe asnjëra nuk është rrugë. Rikthimi i shenjës në paketat e përgjigjes është një hap i veçantë nga zgjedhja e tabelës në dalje, prandaj rregullimet njëdrejtimëshe prodhojnë lidhje që hapen dhe pastaj ngecin.

Kush i zotëron rregullat dhe tabelat

Shërbimi i rrjetit i Android, netd, krijon rregullat dhe tabelat për çdo rrjet. AOSP RouteController është vendi ku ato rregulla montohen për VPN, rrjetet fizike dhe intervalet uid, dhe cikli i tij i jetës lidhet me ngjarje rrjeti e jo me një skedar konfigurimi.

Pasojnë dy pasoja. Së pari, prioritetet dhe numrat e tabelave që gjeni në një pajisje janë hollësi të brendshme të ndërtimit, jo ndërfaqe: numra që duken njësoj në një version tjetër të Android mund të nënkuptojnë diçka krejt tjetër. Së dyti, gjendja rindërtohet kur rrjetet ndryshojnë, kështu që një rregull i futur sot nga një shell root mund të ketë humbur pas kalimit të ardhshëm të Wi-Fi.

Ajo zhdukje raportohet shpesh si sistem që injoron një rrugë. Ajo që ndodhi në të vërtetë është se rregulli që zgjidhte tabelën nuk ekziston më, dhe rruga brenda tabelës tani është e paarritshme nga këndvështrimi i paketës. Kontrolloni listën e rregullave, jo listën e rrugëve, kur një konfigurim që funksiononte ndalon së punuari pas një rilidhjeje.

Pyetjet për rendin e grepave nuk kanë përgjigje universale

Pyetja nëse iptables ekzekutohet përpara rrugëtimit të VPN nuk mund të përgjigjet pa emërtuar rrugën e paketës. Një paketë e gjeneruar lokalisht kalon nëpër grepin output, ku një ndryshim shenje shkakton një kontroll ri-rrugëtimi — një kërkim i dytë, jo një redaktim retrospektiv i të parit. Një paketë që vjen nga një klient tether kalon nëpër rrugën prerouting dhe përcillët në vend të kësaj, dhe zinxhirët që e shohin janë të tjerë.

Pra, i njëjti rregull mund të jetë efektiv për trafikun e një aplikacioni dhe i padukshëm për trafikun tether, dhe një numërues që mbetet në zero ju tregon cilën rrugë mori paketa, jo nëse rregulli është i gabuar. Përdorni numërues për të përcaktuar rrugën përpara se të ndryshoni çdo kusht përputhjeje.

Kjo është gjithashtu faza ku një gabim rrugëtimi politik bëhet i vështirë për t'u parë. Rrugëtimi drejt një tabele që ekziston por nuk e përmban destinacionin prodhon një rrjet të paarritshëm që duket si hedhje e murit të zjarrit, ndërsa një hedhje e murit të zjarrit prodhon një skadim kohe që duket si vrimë e zezë rrugëtimi.

Diagnostiko brenda sistemit, ose lëre të qetë

Për një shqyrtim të autorizuar, përcaktoni katër fakte përpara se të prekni gjithçka: uid dhe profilin e aplikacionit, rrjetin që Android zgjodhi për të, nëse VPN përfshin fare atë aplikacion dhe nëse problemi ekziston për të dy familjet e adresave. Përjashtimi për aplikacion shpjegon shumë raportime VPN nuk funksionon pa asnjë defekt rrugëtimi.

Pastaj lexoni rregullat, maskat dhe tabelat që janë realisht në fuqi, dhe mbani një ndryshim rrjeti brenda dritares së vëzhgimit. Nëse sjellja ndryshon gjatë një rilidhjeje, po shikoni një cikël jete të menaxhuar, jo një rrugë që mungon.

Për kërkesa të zakonshme, përdorni kontrollet e mbështetura: përfshirja dhe përjashtimi për aplikacion në aplikacionin VPN, dhe zgjedhja e rrjetit të vetë platformës për çdo gjë që kërkon një rrugë të caktuar. Nëse një integrim i privilegjuar vërtet duhet të bashkëpunojë me mekanizmin e rrugëtimit, synoni zbatimin e versionit të saktë të Android që mbështesni dhe mbani ciklin e tij të jetës përmes komponentit që e zotëron. Zbrazja e zinxhirëve të platformës ose futja e një rregulli me prioritet të lartë e kthen një diagnozë në një menaxher të dytë rrjeti, dhe telefoni do të sillet në përputhje me këtë.