Zoznam povolených v Android VpnService: prečo povolené stránky stále zamŕzajú

Pridali ste doménu do zoznamu povolených, dopyt sa dostane do vašej aplikácie, porovnávač vráti povolené, a stránka sa napriek tomu nikdy nenačíta. V tom bode väčšina začne prepisovať porovnávač a pridávať porovnania so zástupnými znakmi. Podľa mojich skúseností je porovnávač zvyčajne správny a porucha leží o vrstvu nižšie: v odpovedi DNS, ktorú ste syntetizovali, v trase, ktorú ste nainštalovali, alebo v sockete, ktorý ste použili na preposlanie dopytu. Zoznam je tá ľahká časť; cesta paketu je miesto, kde sa zoznamy povolených lámu.

Porovnávač je zriedka vinníkom

Najprv treba oddeliť blokované od pokazeného. Blokované meno by malo zlyhať rýchlo a viditeľne, pretože prehliadač dostane odpoveď, že meno neexistuje, a zastaví sa. Pokazené meno visí, skúša znova cez IPv6, prepne na iný transport a nechá vás s otáčajúcim sa indikátorom. Ak vidíte otáčajúci sa indikátor, váš zoznam povolených pravdepodobne odpovedá niečím, s čím klient nemôže nič urobiť.

Prázdny záznam A je klasická chyba. Vrátenie NOERROR s nulou odpovedí vyzerá ako platná odpoveď, takže stub rezolver ju prijme, prehliadač to skúsi znova, skúsi AAAA, skúsi iný rezolver a vzdá sa oveľa neskôr. Kód odpovede 3, teda NXDOMAIN, s opakovanou sekciou otázky a skopírovaným ID transakcie ukončí konverzáciu okamžite. Používajte ho na každé meno, ktoré zámerne odmietate.

IPv6 si zaslúži rovnaké rozhodnutie, nie predvolenú hodnotu. Ak odpoviete NXDOMAIN na A a pustíte AAAA, klient sa môže dostať k blokovanému menu cez IPv6 a filter presakuje. Niektoré implementácie odpovedajú na blokované dopyty AAAA adresou loopback, aby spojenie hneď zlyhalo namiesto prechodu na náhradnú cestu. Vyberte jednu politiku, použite ju na oba typy záznamov a logujte oba.

Trasa, ktorá zachytí všetko, vlastní všetko

Návrh iba s DNS nikdy nepridá addRoute("0.0.0.0", 0), takže do rozhrania TUN vstupujú len dopyty a všetko ostatné pokračuje v používaní podsiete. To je bezpečný tvar a vysvetľuje aj to, prečo niektoré zoznamy povolených fungujú na Wi-Fi a zlyhávajú v mobilnej sieti.

V okamihu, keď existuje predvolená trasa, každý tok je váš. Paket TCP, ktorý dorazí na rozhranie a nie je ani preposlaný, ani zodpovedaný, sedí vo fronte, kým klientovi nevyprší čas, a nie je žiadna chyba na zalogovanie, pretože nič nezlyhalo. Videl som niekoho stráviť popoludnie na pokazenom zozname povolených, ktorý bol v skutočnosti chýbajúcim preposielačom pre port 443. Logujte protokol a cieľ každého paketu, ktorý sa rozhodnete zahodiť.

Socket rezolvera musí opustiť tunel

Preposielanie je miesto ďalšej pasce. Rezolvery operátora často žijú na privátnej adrese, kam sa tunel nedostane, takže preposlaný dopyt ide nikam a aplikácia hlási vypršanie času čítania. Posielajte schválené dopyty rezolveru, o ktorom viete, že je dostupný, a ten socket najprv odovzdajte do VpnService.protect(). Nechránený socket pošle dopyt späť do vášho vlastného tunela, kde znova dorazí do aplikácie a krúži, kým nevyprší časový limit.

Porucha vyzerá rovnako ako výpadok siete, a preto v hláseniach chýb prežíva tak dlho. Veďte počítadlá odoslaných dopytov a prijatých odpovedí: ak prvé číslo rastie a druhé zostáva na nule, pozeráte sa na socket, nie na zoznam.

Veľkosť a kontrolné súčty zlyhávajú bez správy

Tiché zahadzovanie prichádza aj z veľkosti. Odpoveď DNS s veľkou sadou odpovedí alebo TCP handshake so štedrými možnosťami môže prekročiť MTU cesty, ktoré ste nikdy explicitne nenastavili; fragment zmizne vyššie a klient buď skúsi menší, alebo prestane skúšať. Nastavenie MTU rozhrania na 1280 je konzervatívna voľba, ktorá prežije väčšinu mobilných ciest, a byť explicitný je lepšie ako dediť predvolenú hodnotu, ktorú nikto nezmeral.

Ak si pakety staviame sami, kontrolný súčet je druhý tichý zabijak. Kontrolný súčet UDP vypočítaný cez pseudo-hlavičku, ktorá vynecháva dĺžku UDP alebo pole protokolu, vytvorí paket, ktorý na vašej strane vyzerá správne a príjemca ho bez stopy zahodí. Porovnajte svoju pseudo-hlavičku so špecifikáciou pole po poli a pri ladení vypíšte vypočítaný kontrolný súčet pre jeden známy tok.

Čo za vás VpnService neurobí

Dva limity stoja za to poznať, kým okolo nich začnete navrhovať. Žiadna bežná aplikácia nemôže nainštalovať systémové proxy ani súbor PAC mimo Wi-Fi a tá časť sa nezmenila. Cesta pre jednotlivé aplikácie áno: pred API 29 nemohol VpnService.Builder niesť proxy vôbec a od API 29 setHttpProxy(ProxyInfo.buildPacProxy(uri)) odovzdáva platforme skript PAC na vyhodnotenie pre sieť VPN. Vyhodnocujte pravidlá vo vlastnom kóde, keď cielite na staršie API alebo keď model PAC nevie vyjadriť pravidlo. UDP tiež nie je zadarmo: prehliadače posielajú cez SOCKS proxy iba TCP a väčšina klientov SOCKS5 nikdy neimplementuje UDP ASSOCIATE, takže návrh založený na proxy zahadzuje alebo prepúšťa UDP, kým TCP vyzerá zdravo.

Tento druhý limit je dôvod, prečo protokol založený na UDP môže fungovať v bežnej sieti a zlyhať v okamihu, keď sa vaša VPN pripojí. Ak sa od tunela očakáva, že ponesie UDP, preposielač musí implementovať preposielaciu cestu aj preň, nielen cestu TCP s iným typom socketu.

Kontrolujte v tomto poradí

Prejdite zoznam po poradí a zastavte sa pri prvom kroku, ktorý zlyhá, pretože každá ďalšia kontrola je šum, kým predchádzajúca nedrží.

1. Vypíšte nainštalované trasy a potvrďte, či pakety, ktoré nie sú DNS, vôbec vstupujú do rozhrania TUN.
2. Zalogujte meno dopytu, rozhodnutie a kód odpovede pre jedno blokované a jedno schválené meno.
3. Potvrďte, že socket rezolvera je chránený a že zvolený rezolver odpovedá zvnútra tunela.
4. Potvrďte MTU rozhrania a kontrolný súčet jednej odpovede zostavenej ručne.
5. Zopakujte tú istú stránku na Wi-Fi a v mobilnej sieti, pretože rezolvery operátora a MTU cesty sa líšia.

Ak všetkých päť drží a stránka stále zamŕza, ďalším podozrivým je samotný preposielač: porovnajte zachytenú požiadavku so zachytenou odpoveďou a hľadajte chýbajúci počet bajtov alebo polouzavretý socket. Referenčná príručka VpnService.Builder pokrýva zmluvy o trase, DNS a MTU a protect() je samostatné volanie VpnService, nie voľba buildera; pripojené rozhranie znamená len to, že prvá zmluva je splnená.