Android VpnService atļauto saraksts: kāpēc atļautās lapas joprojām karājas

Jūs pievienojāt domēnu atļauto sarakstam, vaicājums nonāk jūsu lietotnē, salīdzinātājs atgriež atļauts, un lapa joprojām nekad neielādējas. Tajā brīdī lielākā daļa sāk pārrakstīt salīdzinātāju un pievienot aizstājējzīmju salīdzināšanu. Manā pieredzē salīdzinātājs parasti ir pareizs, un kļūme atrodas vienu slāni zemāk: jūsu sintezētajā DNS atbildē, jūsu instalētajā maršrutā vai ligzdā, ko izmantojāt vaicājuma pārsūtīšanai. Saraksts ir vieglā daļa; paketes ceļš ir vieta, kur atļauto saraksti lūzt.

Salīdzinātājs reti ir vainīgais

Vispirms jānošķir bloķēts no salauzta. Bloķētam vārdam vajadzētu neizdoties ātri un redzami, jo pārlūks saņem atbildi, ka vārds neeksistē, un apstājas. Salauzts vārds karājas, mēģina vēlreiz pa IPv6, pāriet uz citu transportu un atstāj jūs ar griežošu indikatoru. Ja redzat griežošu indikatoru, jūsu atļauto saraksts, visticamāk, atbild ar kaut ko tādu, ar ko klients neko nevar darīt.

Tukšs A ieraksts ir klasiskā kļūda. NOERROR atgriešana ar nulli atbilžu izskatās kā derīga atbilde, tāpēc stub risinātājs to pieņem, pārlūks mēģina vēlreiz, izmēģina AAAA, izmēģina citu risinātāju un padodas daudz vēlāk. Atbildes kods 3, tas ir, NXDOMAIN, ar atkārtotu jautājuma sadaļu un nokopētu transakcijas ID nekavējoties izbeidz sarunu. Izmantojiet to katram vārdam, ko apzināti noraidāt.

IPv6 arī pelnījis to pašu lēmumu, nevis noklusējuma vērtību. Ja atbildat NXDOMAIN uz A un palaižat AAAA, klients var sasniegt bloķēto vārdu pa IPv6, un filtrs noplūst. Dažas implementācijas uz bloķētiem AAAA vaicājumiem atbild ar loopback adresi, lai savienojums nekavējoties neizdotos, nevis pārietu uz alternatīvu. Izvēlieties vienu politiku, piemērojiet to abiem ierakstu tipiem un reģistrējiet abus.

Maršruts, kas notver visu, pārvalda visu

Konstrukcija tikai ar DNS nekad nepievieno addRoute("0.0.0.0", 0), tāpēc TUN saskarnē nonāk tikai vaicājumi, un viss pārējais turpina izmantot apakšējo tīklu. Tā ir drošā forma, un tas arī izskaidro, kāpēc daži atļauto saraksti šķietami darbojas Wi-Fi tīklā un neizdodas mobilajā tīklā.

Tajā brīdī, kad pastāv noklusējuma maršruts, katrs plūsma ir jūsu. TCP pakete, kas ierodas saskarnē un netiek ne pārsūtīta, ne atbildēta, sēž rindā, līdz klientam beidzas laiks, un nav kļūdas, ko reģistrēt, jo nekas neizdevās. Esmu redzējis, kā kāds pavada pēcpusdienu pie salauzta atļauto saraksta, kas patiesībā bija trūkstošs pārsūtītājs portam 443. Reģistrējiet katra paketes, ko nolemjat atmest, protokolu un galamērķi.

Risinātāja ligzdai jāiziet no tuneļa

Pārsūtīšana ir vieta, kur slēpjas nākamais slazds. Operatora risinātāji bieži dzīvo privātā adresē, kuru tunelis nesasniedz, tāpēc pārsūtītais vaicājums nekur nenonāk, un lietotne ziņo par lasīšanas taimautu. Sūtiet apstiprinātos vaicājumus risinātājam, par kuru zināt, ka tas ir sasniedzams, un vispirms nododiet šo ligzdu VpnService.protect(). Neaizsargāta ligzda nosūta vaicājumu atpakaļ jūsu pašu tunelī, kur tas atkal nonāk lietotnē un griežas, līdz iedarbojas taimauts.

Kļūme izskatās identiski tīkla pārtraukumam, un tāpēc tā tik ilgi izdzīvo kļūdu ziņojumos. Turiet skaitītājus nosūtītajiem vaicājumiem un saņemtajām atbildēm: ja pirmais skaitlis kāpj un otrais paliek nullē, jūs skatāties uz ligzdu, nevis uz sarakstu.

Izmērs un kontroles summas neizdodas bez ziņojuma

Klusās atmešanas nāk arī no izmēra. DNS atbilde ar lielu atbilžu kopu vai TCP roku saspišana ar dāsnu opciju kopu var pārsniegt ceļa MTU, ko nekad neesat skaidri iestatījis; fragments pazūd augšup, un klients vai nu mēģina vēlreiz mazāku, vai pārstāv mēģināt. Saskarnes MTU iestatīšana uz 1280 ir konservatīva izvēle, kas iztur lielāko daļu mobilo ceļu, un būt skaidram ir labāk nekā mantot noklusējuma vērtību, ko neviens nav mērījis.

Ja paketes veidojat paši, kontroles summa ir nākamais klusais slepkava. UDP kontroles summa, kas aprēķināta pār pseido galveni, kurā izlaists UDP garums vai protokola lauks, rada paketi, kas jūsu pusē izskatās pareizi, un uztvērējs to izmet bez pēdām. Salīdziniet savu pseido galveni ar specifikāciju lauks pa laukam un atkļūdošanas laikā izdrukājiet aprēķināto kontroles summu vienam zināmam plūsmam.

Ko VpnService nedarīs jūsu vietā

Divi ierobežojumi ir vērts zināt pirms projektēšanas ap tiem. Neviena parasta lietotne nevar instalēt sistēmas līmeņa starpniekserveri vai PAC failu ārpus Wi-Fi, un šī daļa nav mainījusies. Ceļš pa lietotnēm ir mainījies: pirms API 29 VpnService.Builder vispār nevarēja pārnest starpniekserveri, un no API 29 setHttpProxy(ProxyInfo.buildPacProxy(uri)) nodod platformai PAC skriptu novērtēšanai VPN tīklam. Novērtējiet noteikumus savā kodā, kad mērķējat uz vecākiem API vai kad PAC modelis nevar izteikt noteikumu. UDP arī nav bez maksas: pārlūki caur SOCKS starpniekserveri sūta tikai TCP, un lielākā daļa SOCKS5 klientu nekad neievieš UDP ASSOCIATE, tāpēc uz starpniekserveri balstīta konstrukcija atmet vai noplūdina UDP, kamēr TCP izskatās vesels.

Šis otrais ierobežojums ir iemesls, kāpēc uz UDP balstīts protokols var darboties parastā tīklā un neizdoties tajā brīdī, kad pievienojas jūsu VPN. Ja tiek gaidīts, ka tunelis pārnēsās UDP, pārsūtītājam ir jāievieš pārsūtīšanas ceļš tam, nevis tikai TCP ceļš ar citu ligzdas tipu.

Pārbaudiet šajā secībā

Izejiet sarakstu secībā un apstājieties pie pirmā neizdevušā posma, jo katra nākamā pārbaude ir troksnis, kamēr iepriekšējā neturas.

1. Uzskaitiet instalētos maršrutus un apstipriniet, vai paketes, kas nav DNS, vispār nonāk TUN saskarnē.
2. Reģistrējiet vaicājuma nosaukumu, lēmumu un atbildes kodu vienam bloķētam un vienam apstiprinātam vārdam.
3. Apstipriniet, ka risinātāja ligzda ir aizsargāta un izvēlētais risinātājs atbild no tuneļa iekšpuses.
4. Apstipriniet saskarnes MTU un vienas ar roku veidotas atbildes kontroles summu.
5. Atkārtojiet to pašu lapu Wi-Fi un mobilajā tīklā, jo operatora risinātāji un ceļa MTU atšķiras.

Ja visi pieci turas un lapa joprojām karājas, nākamais aizdomās turamais ir pats pārsūtītājs: salīdziniet uztverto pieprasījumu ar uztverto atbildi un meklējiet trūkstošu baitu skaitu vai puslīdz aizvērtu ligzdu. VpnService.Builder uzziņa aptver maršruta, DNS un MTU līgumus, un protect() ir atsevišķs VpnService izsaukums, nevis builder opcija; pievienota saskarne nozīmē tikai to, ka pirmais līgums ir izpildīts.