Android VpnService tilletingsliste: kvifor tillatne sider enno heng

Du la eit domene til i tilletingslista, spørjinga når appen din, matcharen returnerer tillate, og sida blir framleis aldri lasta. På det punktet byrjar dei fleste å skrive om matcharen og leggje til jokerteiknsamanlikningar. Etter mi erfaring er matcharen som regel korrekt, og feilen ligg eitt lag lenger nede: i DNS-svaret du syntetiserte, i ruta du installerte, eller i sokkelen du brukte for å senda spørjinga vidare. Lista er den enkle delen; pakkestien er der tilletingslister blir brotne.

Matcharen er sjeldan feilen

Det fyrste som må skiljast, er blokkert frå øydelagt. Eit blokkert namn bør feile raskt og synleg, fordi nettlesaren får eit svar om at namnet ikkje finst og stoppar. Eit øydelagt namn heng, prøver på nytt over IPv6, fell tilbake til ein annan transport og lèt deg sitje att med ein snurrande indikator. Ser du ein snurrande indikator, svarar tilletingslista di truleg noko klienten ikkje kan bruke.

Ein tom A-post er den klassiske feilen. Å returnere NOERROR med null svar ser ut som eit gyldig svar, så stub-resolveren godtek det, nettlesaren prøver på nytt, prøver AAAA, prøver ein annan resolver og gir opp mykje seinare. Ein svarkode 3, altså NXDOMAIN, med spørsmålsdelen gjenteken og transaksjons-ID-en kopiert, avsluttar samtalen med ein gong. Bruk han for kvart namn du med vilje avviser.

IPv6 fortener same avgjerda i staden for ein standardverdi. Svarar du NXDOMAIN på A og slepp AAAA gjennom, kan klienten nå det blokkerte namnet over IPv6, og filteret lek. Nokre implementasjonar svarar på blokkerte AAAA-spørjingar med ei loopback-adresse slik at tilkoplinga feilar med ein gong i staden for å falle tilbake. Vel éin politikk, bruk han på begge posttypane, og logg begge.

Ei rute som fangar alt, eig alt

Eit design med berre DNS legg aldri til addRoute("0.0.0.0", 0), så berre spørjingar kjem inn i TUN-grensesnittet, og alt anna held fram med å bruke det underliggjande nettet. Det er den trygge forma, og det forklarer òg kvifor nokre tilletingslister ser ut til å verke på Wi-Fi og feile på mobilnettet.

I det augneblinken ei standardrute finst, er kvar straum din. Ei TCP-pakke som kjem til grensesnittet og korkje blir send vidare eller svara på, blir liggjande i køa til klienten får tidsavbrot, og det er ingen feil å logge fordi ingenting feila. Eg har sett nokon bruke ein ettermiddag på ei øydelagd tilletingsliste som i røynda var ein manglande videresendar for port 443. Logg protokollen og målet for kvar pakke du bestemmer deg for å forkaste.

Resolver-sokkelen må forlate tunnelen

Videresending er der den neste fella sit. Resolvarar hos operatøren bur ofte på ei privat adresse som tunnelen ikkje når, så spørjinga du sender vidare går ingen stad, og appen rapporterer lesetidsavbrot. Send godkjende spørjingar til ein resolver du veit er tilgjengeleg, og gi den sokkelen til VpnService.protect() fyrst. Ein uverna sokkel sender spørjinga tilbake i din eigen tunnel, der ho når appen igjen og sirkulerer til tidsavbrotet blir utløyst.

Feilen ser identisk ut med eit nettavbrot, og difor overlever han så lenge i feilrapportar. Hald teljarar for sende spørjingar og mottekne svar: stig det fyrste talet og blir det andre ståande på null, ser du på sokkelen, ikkje på lista.

Storleik og kontrollsummar feilar utan melding

Stille dropp kjem òg frå storleik. Eit DNS-svar med eit stort svarsett, eller eit TCP-handtrykk med romslege val, kan overskride ein sti-MTU du aldri sette eksplisitt; fragmentet forsvinn oppstraums, og klienten prøver anten på nytt med mindre eller sluttar å prøve. Å setje grensesnittets MTU til 1280 er eit konservativt val som overlever dei fleste mobilstiane, og å vere eksplisitt er betre enn å arve ein standard ingen har målt.

Byggjer du pakkane sjølv, er kontrollsummen den andre stille mordaren. Ein UDP-kontrollsum rekna ut over ein pseudo-header som utelèt UDP-lengda eller protokollfeltet, gir ei pakke som ser velforma ut hos deg og blir kasta av mottakaren utan spor. Samanlikn pseudo-headeren din med spesifikasjonen felt for felt, og skriv ut den utrekna kontrollsummen for ein kjend straum medan du feilsøkjer.

Kva ein VpnService ikkje gjer for deg

To grenser er verd å kjenne før du designar rundt dei. Ingen vanleg app kan installere ein systemvid proxy eller PAC-fil utanfor Wi-Fi, og den delen har ikkje endra seg. Stien per app har det: før API 29 kunne VpnService.Builder ikkje bere proxy i det heile, og frå API 29 gir setHttpProxy(ProxyInfo.buildPacProxy(uri)) plattforma eit PAC-skript å evaluere for VPN-nettet. Evaluer reglar i din eigen kode når du rettar deg mot eldre API-ar, eller når PAC-modellen ikkje kan uttrykkje regelen. UDP er heller ikkje gratis: nettlesarar sender berre TCP gjennom ein SOCKS-proxy, og dei fleste SOCKS5-klientar implementerer aldri UDP ASSOCIATE, så eit proxybasert design droppar eller lek UDP medan TCP ser sunt ut.

Den andre grensa er grunnen til at ein UDP-basert protokoll kan verke på eit vanleg nett og feile i det augneblinken VPN-en din koplar til. Er tunnelen venta å bere UDP, må videresendaren implementere videresendingsstien for det, ikkje berre TCP-stien med ein annan sokkeltype.

Sjekk i denne rekkjefølgja

Arbeid deg gjennom lista i rekkjefølgje og stopp ved det fyrste trinnet som feilar, fordi kvar seinare sjekk er støy til den førre held.

1. List opp dei installerte rutene og stadfest om ikkje-DNS-pakkar i det heile kjem inn i TUN-grensesnittet.
2. Logg spørringsnamnet, avgjerda og svarkoden for eitt blokkert og eitt godkjent namn.
3. Stadfest at resolver-sokkelen er verna og at den valde resolveren svarar frå innsida av tunnelen.
4. Stadfest grensesnittets MTU og kontrollsummen til eitt svar du bygde for hand.
5. Gjentak den same sida på Wi-Fi og mobilnett, fordi operatørresolvarar og sti-MTU er ulike.

Held alle fem og heng sida enno, er den neste mistenkte videresendaren sjølv: samanlikn ein fanga førespurnad med eit fanga svar og sjå etter eit manglande bytetal eller ein halvlukka sokkel. VpnService.Builder-referansen dekkjer kontraktane for rute, DNS og MTU, og protect() er eit eige VpnService-kall og ikkje eit builder-val; eit tilkopla grensesnitt tyder berre at den fyrste kontrakten er oppfylt.