Nola baztertu azpisare bat Android VPN tunel batetik

VpnService-k ezin du ibilbiderik baztertu, beraz osagarria gehitzen duzu: /8 baterako sortutako zortzi aurrizki, gehi gainerakoa harrapatzen duten IPv6, DNS eta bilaketa egiaztapenak.

Androiden VpnService-k ez du baztertze-ibilbiderik, eta API irakurketa kopuru handiak ez du bat sortuko. Builder.addRoute()-k beti gehitzen dizkio helmugak tunelari, beraz LAN segmentu bat lokal mantentzeak esan nahi du segmentu hori ez dela inoiz ibilbide-zerrendan sartzen. Horren ordez gehitzen duzuna segmentuaren osagarria da, aurrizki arrunt gisa adierazia. Lana aritmetika da, eta leku gutxi batzuetan huts egiten du, aurreikusgarriak direnak.

Egin beheko egiaztapenak ordenan. Bakoitzak aurrekoa bete dela suposatzen du, beraz gelditu lehen hutsegitean, beherago dauden sintomak adabakitu beharrean.

Hasi tunelak aldarrikatzen duenetik

0.0.0.0/0 addRoute()-ri pasatzeak Androidi esaten dio IPv4 helmuga bakoitza tunelari dagokiola. Horregatik hainbat bezerok ez dute tunelatze zatitua egiteko gaitasunik ematen: helbide-espazio osoa aldarrikatzen dute eta gero hortik kentzen saiatzen dira. Eraikitzailean ezerk ez du kentzen. Lokal mantendu nahi zenuen sarearentzat ibilbide zehatzago batek jendeak espero duenaren kontrakoa egiten du, aurrizki luzeenak irabazten baitu eta sare hori tunelaren barruan geratzen baita.

Ibilbide-zerrenda politika osoa da. Ez dago helmugako betorik haren atzean, eta Builder erreferentziak ez du hori emango lukeen metodorik zerrendatzen.

Sortu osagarria aurrizki-aritmetikatik

Baztertutako aurrizki baten osagarria zuhaitzaren erroaren biderako haren anai-arreben multzoa da. 1etik baztertutako luzerara arteko luzera bakoitzerako, hartu zure aurrizkia duen luzera horretako blokea, irauli aurrizkiaren azpiko bita eta eman emaitza. Abstraktua dirudi exekutatu arte.

10.0.0.0/8 baztertezak zortzi ibilbide ematen ditu: 128.0.0.0/1, 64.0.0.0/2, 32.0.0.0/3, 16.0.0.0/4, 0.0.0.0/5, 12.0.0.0/6, 8.0.0.0/7, 11.0.0.0/8. Horietako batek ere ez du 10.0.0.0/8 barnean, eta elkarrekin gainerako guztia estaltzen dute.

Zortzi lerrok zerrenda hori sortzen dute edozein aurrizkirentzat:

import ipaddress
def complement(addr, length):
    base = int(ipaddress.IPv4Address(addr))
    out = []
    for k in range(1, length + 1):
        block = base & (0xFFFFFFFF << (32 - k))
        sibling = block ^ (1 << (32 - k))
        out.append(f"{ipaddress.IPv4Address(sibling)}/{k}")
    return out
print(complement("10.0.0.0", 8))

Ibilbide kopurua aurrizkiaren luzeraren berdina da, eta hori da begiratu beharreko zenbakia. /21 baztertze bakar batek 21 ibilbide kostatzen ditu eta irakurgarri jarraitzen du. Hamar baztertzek ehunka batzuk kostatu ditzakete, eta horrek normalean sarearen diseinua aldatu behar dela esan nahi du, ez sortzailea.

Egiaztatu helbide-familia eta tunelaren irismena

IPv4 ibilbideek ez dute ezer egiten IPv6rentzat. Tunelak IPv6 helbide bat aldarrikatzen badu, IPv6 LAN aurrizki batek bere osagarria behar du, 128 biten gaineko aritmetika berarekin sortua. Baztertzeak paperean funtzionatzea eta gailu lokala iristezin jarraitzea eragiten duen arrazoi ohikoa hau da: hosta IPv6 bidez iritsi zen, eta IPv4 bakarrik moztu zen. Egiaztatu bi familiak, matematika okerra dela ondorioztatu aurretik.

Irismena egiaztapenaren beste erdia da. Androidek bideratzea sareka eta aplikazioka egiten du, beraz aurrizki berak tunel bidez joan daiteke aplikazio batentzat eta zuzenean beste batentzat, VPN nola deklaratu den arabera.

Jarri DNS eta aplikazioko arauak dagokien tokian

Ibilbide-baztertzeek ez dute resolver-a aldatzen. Host-izen lokal bati tunelaren DNS zerbitzariak erantzun diezaioke oraindik, haren helbidea lokalki bideratzen den bitartean, eta desdoitzeak LANak iritsi ezin duen zerbaitetara ebazten den izen gisa agertzen da. Ezarri resolver politika nahita, bilaketa-domeinu batekin edo DNS zatituaren arau batekin. Ez pentsa ibilbideek erabaki dutenik zuretzat.

addDisallowedApplication()-k aplikazio bat tunelatik kanpo mantentzen du; ez du helmugarik kanpo mantentzen barruan geratzen diren aplikazioentzat. protect()-k irekitzen duzun socket bat tunela saihestea ahalbidetzen du, eta horrela tunel batek bere garraioa harrapatzea saihesten du. Biak ere ez dira osagarriaren ordezko.

Egiaztatu bilaketa batekin, ez zure zerrendarekin

Tunela martxan dagoenean, galdetu gailuari helbide bat benetan nora doan, eraiki duzun zerrenda berriro irakurri beharrean. iproute2 daraman build batean, adb shell ip route get 10.1.2.3-k kernelak hautatutako interfazea izendatzen du. Exekutatu komando bera helbide publiko batentzat eta baieztatu tunela izendatzen duela.

Beste bi egiaztapenek zikloa ixten dute. Ebatzi lehenengo izen lokal bat, gero exekutatu adb shell ip route get ebatzitako helbidean eta eskatu tunela ez den interfaze bat, adb shell ping -c 1 host.lan arrakastatsuak irisgarritasuna frogatzen baitu, ez bidea. Errepikatu helbide-familiaren proba IPv6ren gainean tunelak bat aldarrikatzen badu. Probatu bidaltzen duzun API mailan, VPN sareak bideratze-taulara nola azaltzen diren aldatu egin baita kaleratzeen artean. Paperean zuzena dirudien ibilbide-zerrenda eta interfaze okerra hautatzen duen bilaketa akats desberdinak dira, eta bigarrena soilik iristen da erabiltzaileengana.

Baztertze-zerrenda hazten jarraitzen badu, utzi ibilbideak sortzeari eta zenbaki berriztatu urrutiko sarea edo estutu tunela. Sortzailea falta den APIaren inguruko konponbidea da, ez diseinu-tresna.

Erlazionatutako artikuluak