Vi aldonis domajnon al la permeslisto, la peto atingas vian aplikaĵon, la kongruigilo redonas permesita, kaj la paĝo tamen neniam ŝargiĝas. En tiu punkto la plej multaj komencas reverki la kongruigilon kaj aldoni anstataŭsignajn komparojn. Laŭ mia sperto la kongruigilo kutime estas ĝusta, kaj la paneo situas unu tavolon pli malalte: en la DNS-respondo, kiun vi sintezis, en la enkursigo, kiun vi instalis, aŭ en la ingo, kiun vi uzis por plusendi la peton. La listo estas la facila parto; la paka vojo estas kie permeslistoj rompiĝas.

La kongruigilo malofte estas la kulpulo

La unua afero apartigi estas blokita de rompita. Blokita nomo devus malsukcesi rapide kaj videble, ĉar la retumilo ricevas respondon, ke la nomo ne ekzistas, kaj haltas. Rompita nomo frostas, reprovas tra IPv6, falas al alia transporto, kaj lasas vin kun turniĝanta indikilo. Se vi vidas turniĝantan indikilon, via permeslisto verŝajne respondas per io, pri kio la kliento ne povas agi.

Malplena A-rikordo estas la klasika eraro. Redoni NOERROR kun nulo da respondoj aspektas kiel valida respondo, do la stub-solvilo akceptas ĝin, la retumilo reprovas, provas AAAA, provas alian solvilon kaj rezignas multe pli poste. Respondkodo 3, NXDOMAIN, kun la demando-sekcio ripetita kaj la transakcia ID kopiita, finas la konversacion tuj. Uzu ĝin por ĉiu nomo, kiun vi intence rifuzas.

IPv6 meritas la saman decidon anstataŭ defaŭlto. Se vi respondas NXDOMAIN por A kaj lasas AAAA pasi, la kliento povas atingi la blokitan nomon tra IPv6 kaj la filtrilo likas. Iuj efektivigoj respondas al blokitaj AAAA-petoj per loopback-adreso, por ke la konekto malsukcesu tuj anstataŭ fali al alia vojo. Elektu unu politikon, apliku ĝin al ambaŭ rikordtipoj, kaj registru ambaŭ.

Enkursigo, kiu kaptas ĉion, posedas ĉion

Dezajno nur per DNS neniam aldonas addRoute("0.0.0.0", 0), do nur petoj eniras la TUN-interfacon kaj ĉio alia daŭre uzas la suban reton. Tio estas la sekura formo, kaj ĝi ankaŭ klarigas, kial iuj permeslistoj ŝajne funkcias en Wi-Fi kaj paneas en la poŝtelefona reto.

En la momento, kiam ekzistas defaŭlta enkursigo, ĉiu fluo estas via. TCP-paketo, kiu alvenas al la interfaco kaj nek estas plusendita nek respondita, restas en la vico ĝis la kliento tempolimas, kaj ne estas eraro por registri, ĉar nenio eraris. Mi vidis iun pasigi posttagmezon sur rompita permeslisto, kiu fakte estis mankanta plusendilo por pordo 443. Registru la protokolon kaj celon de ĉiu paketo, kiun vi decidas forĵeti.

La ingo de la solvilo devas forlasi la tunelon

Plusendado estas kie sidas la sekva kaptilo. Solviloj de la operatoro ofte loĝas sur privata adreso, kiun la tunelo ne atingas, do la peto, kiun vi plusendas, iras nenie kaj la aplikaĵo raportas legotempon. Sendu aprobitajn petojn al solvilo, pri kiu vi scias, ke ĝi estas atingebla, kaj unue donu tiun ingon al VpnService.protect(). Neprotektita ingo resendas la peton en vian propran tunelon, kie ĝi denove atingas la aplikaĵon kaj cirkulas ĝis la tempolimo ekfunkcias.

La paneo aspektas idente al reta interrompo, kaj tial ĝi postvivas tiel longe en cimraportoj. Tenu nombrilojn por senditaj petoj kaj ricevitaj respondoj: se la unua nombro grimpas kaj la dua restas nulo, vi rigardas la ingon, ne la liston.

Grando kaj kontrolsumoj paneas sen mesaĝo

Silentaj forĵetoj venas ankaŭ de grando. DNS-respondo kun granda respondaro, aŭ TCP-manpremo kun malavaraj opcioj, povas superi voj-MTU, kiun vi neniam eksplicite agordis; la fragmento malaperas suprenvoje kaj la kliento aŭ reprovas pli malgrande aŭ ĉesas reprovi. Agordi la interfacan MTU al 1280 estas konservativa elekto, kiu postvivas plej multajn poŝtelefonajn vojojn, kaj esti eksplicita estas pli bone ol heredi defaŭlton, kiun neniu mezuris.

Se vi mem konstruas paketojn, la kontrolsumo estas la alia silenta mortiganto. UDP-kontrolsumo kalkulita sur pseŭdokapo, kiu ellasas la UDP-longon aŭ la protokol-kampon, produktas paketon, kiu aspektas bone formita ĉe vi kaj estas forĵetata de la ricevanto sen spuro. Komparu vian pseŭdokapon kun la specifikaĵo kampo post kampo, kaj presu la kalkulitan kontrolsumon por unu konata fluo dum vi sencimigas.

Kion VpnService ne faros por vi

Du limojn indas scii antaŭ ol dizajni ĉirkaŭ ili. Neniu ordinara aplikaĵo povas instali sistemampleksan prokuron aŭ PAC-dosieron ekster Wi-Fi, kaj tiu parto ne ŝanĝiĝis. La vojo por unuopa aplikaĵo jes: antaŭ API 29 VpnService.Builder tute ne povis porti prokuron, kaj ekde API 29 setHttpProxy(ProxyInfo.buildPacProxy(uri)) donas al la platformo PAC-skripton por taksi por la VPN-reto. Taksu regulojn en via propra kodo, kiam vi celas pli malnovajn API-ojn aŭ kiam la PAC-modelo ne povas esprimi la regulon. UDP ankaŭ ne estas senpaga: retumiloj sendas nur TCP tra SOCKS-prokuro, kaj la plej multaj SOCKS5-klientoj neniam efektivigas UDP ASSOCIATE, do prokurbazita dezajno forĵetas aŭ likas UDP dum TCP aspektas sana.

Tiu dua limo estas la kialo, ke UDP-bazita protokolo povas funkcii en ordinara reto kaj panei en la momento, kiam via VPN konektiĝas. Se la tunelo devas porti UDP, la plusendilo devas efektivigi la plusendan vojon por ĝi, ne nur la TCP-vojon kun alia inga tipo.

Kontrolu en ĉi tiu ordo

Trairu la liston laŭ ordo kaj haltu ĉe la unua etapo, kiu paneas, ĉar ĉiu posta kontrolo estas bruo ĝis la antaŭa teniĝos.

  1. Listigu la instalitajn enkursigojn kaj konfirmu, ĉu ne-DNS-paketoj entute eniras la TUN-interfacon.
  2. Registru la petan nomon, la decidon kaj la respondkodon por unu blokita kaj unu aprobita nomo.
  3. Konfirmu, ke la ingo de la solvilo estas protektita kaj ke la elektita solvilo respondas de interne la tunelo.
  4. Konfirmu la interfacan MTU kaj la kontrolsumon de unu permane konstruitan respondon.
  5. Ripetu la saman paĝon en Wi-Fi kaj poŝtelefona reto, ĉar solviloj de la operatoro kaj voj-MTU malsamas.

Se ĉiuj kvin teniĝas kaj la paĝo ankoraŭ frostas, la sekva suspektato estas la plusendilo mem: komparu kaptitan peton kun kaptita respondo kaj serĉu mankan bajtokalkulon aŭ duone fermitan ingon. La referenco de VpnService.Builder kovras la kontraktojn pri enkursigo, DNS kaj MTU, kaj protect() estas aparta VpnService-voko, ne konstruila opcio; konektita interfaco signifas nur, ke la unua kontrakto plenumiĝis.

Rilataj artikoloj