Android VPN maršrutēšana: politikas noteikumi pirms tabulas main
Android izvēlas maršrutēšanas tabulu pēc uid un atzīmju noteikumiem pirms jebkuras galamērķa meklēšanas, tāpēc main pievienotais maršruts var netikt nekad pārbaudīts.
Maršruts, kas Android sistēmā pievienots tabulai main, izskatās pareizs katrā sarakstā un tomēr nenes satiksmi. Iemesls ir tāds, ka tabula main ir viena no vairākām iespējām, un tā netiek jautāta pirmā. Android tīkla serviss veido politikas noteikumus, kas izvēlas maršrutēšanas tabulu pēc informācijas, kuras galamērķa adresē nav — lietotnes uid, atzīme uz paketes, saskarne, pa kuru tā ieradās — un galamērķa meklēšana notiek pēc tam, tās tabulas iekšienē, kuru izvēlējās šie noteikumi.
Trīs lēmumi fiksētā secībā
Izejošā pakete pieņem trīs atsevišķus lēmumus. Pirmkārt, politikas noteikums nosaka, kura maršrutēšanas tabula ir spēkā. Otrkārt, maršruts šajā tabulā nosaka nākamo lēcienu un izejas saskarni. Treškārt, netfilter āķi nosaka, vai pakete izdzīvo, tiek mainīta vai pāradresēta.
Secība ir svarīga, jo katrs posms var atbildēt tikai uz savu jautājumu. Ugunsmūra noteikums, kas pieņem paketi, neizvēlas tabulu, un maršruts, kas pievienots tabulai, kuru neizvēlas neviens noteikums, ir neaktīvs. Liela daļa apjukumu ap Android VPN nāk no tā, ka izlabo vienu no trim un neievēro nekādas izmaiņas, jo kļūda bija citā.
| 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 |
Atzīmes ir sapakots lauks, nevis etiķete, kas pieder jums
Android sapako vairākus faktus vienā atzīmes vērtībā: kuru tīklu izvēlējās, vai lietotne skaidri izvēlējās tīklu, vai ligzda ir aizsargāta no VPN un ar atļaujām saistītie biti. AOSP fwmark galvene nosaka šo izkārtojumu pašreizējam kokam, un izkārtojums ir platformas iekšēja detaļa, kas mainās starp laidieniem.
Tāpēc Android sistēmā ir bīstami rakstīt visu atzīmes vērtību ar iptables -j MARK --set-mark. Tas nepievieno atzīmi; tas aizstāj tīkla izvēli, ko sistēma jau veikusi. Pēc tam pakete atbilst citiem noteikumiem, kas var izskatīties tā, it kā VPN sācis darboties, vai it kā nesaistīta lietotne zaudējusi savienojumu, atkarībā no tā, kuri biti tika pārrakstīti.
Ja atzīmes tomēr jāaizskar, vispirms nolasiet pašreizējo vērtību un izmantojiet masku, lai mainītos tikai tie biti, kurus jūs saprotat:
ip rule show
ip route show table all | head -40
ip route get 10.20.4.11Savienojuma atzīme ir atsevišķs objekts no paketes atzīmes, un neviena no tām nav maršruts. Atzīmes atjaunošana atbildes paketēs ir atsevišķs solis no tabulas izvēles izejā, tāpēc vienvirziena labojumi rada savienojumus, kas atveras un pēc tam iekaras.
Kam pieder noteikumi un tabulas
Android tīkla serviss netd veido noteikumus un tabulas katram tīklam. AOSP RouteController ir vieta, kur šie noteikumi tiek salikti VPN, fiziskajiem tīkliem un uid diapazoniem, un tā dzīves cikls ir saistīts ar tīkla notikumiem, nevis ar konfigurācijas failu.
No tā izriet divas sekas. Pirmkārt, prioritātes un tabulu numuri, ko atrodat vienā ierīcē, ir būvējuma iekšējas detaļas, nevis saskarne: vienādi izskatoši numuri citā Android versijā var nozīmēt ko pavisam citu. Otrkārt, stāvoklis tiek pārbūvēts, kad tīkli mainās, tāpēc noteikums, kas šodien ievietots no root čaulas, pēc nākamās Wi-Fi pārejas var būt pazudis.
Šo pazušanu bieži ziņo kā sistēmas maršruta ignorēšanu. Patiesībā notika tas, ka noteikums, kas izvēlējās tabulu, vairs neeksistē, un maršruts tabulas iekšienē tagad ir nesasniedzams no paketes skatpunkta. Pārbaudiet noteikumu sarakstu, nevis maršrutu sarakstu, kad strādājoša konfigurācija pārstāj strādāt pēc atkārtotas pievienošanās.
Jautājumiem par āķu secību nav universālas atbildes
Uz jautājumu, vai iptables darbojas pirms VPN maršrutēšanas, nevar atbildēt, nenosaucot paketes ceļu. Lokāli ģenerēta pakete šķērso output āķi, kur atzīmes maiņa izraisa maršrutēšanas pārbaudi — otra meklēšana, nevis pirmās retrospektīva labošana. Pakete, kas nāk no tether klienta, šķērso prerouting ceļu un tiek pārsūtīta, un ķēdes, kas to redz, ir citas.
Tātad viens un tas pats noteikums var būt efektīvs lietotnes satiksmei un neredzams tether satiksmei, un skaitītājs, kas paliek uz nulles, pasaka, kuru ceļu pakete izvēlējās, nevis to, vai noteikums ir nepareizs. Pirms mainīt jebkuru atbilstības nosacījumu, nosakiet ceļu ar skaitītājiem.
Šis ir arī posms, kurā politikas maršrutēšanas kļūda kļūst grūti saskatāma. Maršrutēšana uz tabulu, kas eksistē, bet nesatur galamērķi, rada tīklu nesasniedzams, kas izskatās kā ugunsmūra nomešana, savukārt ugunsmūra nomešana rada taimautu, kas izskatās kā maršrutēšanas melnais caurums.
Diagnosticējiet sistēmas iekšienē vai atstājiet to mierā
Autorizētai pārbaudei pirms kaut kā aizskaršanas nosakiet četrus faktus: lietotnes uid un profilu, tīklu, ko Android tai izvēlējās, vai VPN vispār ietver šo lietotni, un vai problēma pastāv abās adrešu saimēs. Izslēgšana pa lietotnēm izskaidro ļoti daudzus ziņojumus VPN nedarbojas bez jebkādas maršrutēšanas kļūdas.
Pēc tam izlasiet noteikumus, maskas un tabulas, kas faktiski ir spēkā, un turiet tīkla pārslēgšanu novērošanas logā. Ja uzvedība mainās atkārtotas pievienošanās laikā, jūs skatāties pārvaldītu dzīves ciklu, nevis trūkstošu maršrutu.
Parastām prasībām izmantojiet atbalstītos vadības līdzekļus: iekļaušana un izslēgšana pa lietotnēm VPN lietotnē, un pašas platformas tīkla izvēli visam, kam nepieciešams konkrēts ceļš. Ja privileģētai integrācijai patiešām jāsadarbojas ar maršrutēšanas mehānismu, mērķējiet uz tieši tās Android versijas ieviešanu, kuru atbalstāt, un uzturiet tās dzīves ciklu caur komponentu, kuram tā pieder. Platformas ķēžu iztīrīšana vai augstas prioritātes noteikuma ievietošana pārvērš diagnostiku otrajā tīkla pārvaldniekā, un tālrunis uzvedīsies atbilstoši.