Android ĉiam-aktiva VPN: kiel la nomo de la finpunkto unue solviĝas

La telefono restartas, ĉiam-aktiva estas ŝaltita, bloki konektojn sen VPN estas ŝaltita, kaj la tunelo neniam leviĝas. Nenio estas malĝuste agordita: la blokado faras sian laboron, kaj la propra provo de la kliento atingi sian finpunkton ankaŭ submetiĝas al ĝi. La finpunkto devas esti solvita antaŭ ol la tunelo ekzistas, fare de kliento rajtigita paroli kun la reto dum neniu alia aplikaĵo rajtas. Kompreni kiun komponanton faras tion, kaj en kiu ordo, transformas la misteron en agordan demandon.

Kion la VPN-konstruanto efektive petas

Android VPN-a aplikaĵo ne donas al la platformo servilan adreson. Ĝi konstruas lokan interfacon: adresojn kaj itinerojn por la tunelo, la solvilojn kiujn la aplikaĵoj uzu interne, kaj poste establish() redonas dosierpriskribilon, kiun la aplikaĵo legas kaj skribas kiel krudajn IP-paketojn. La fora finpunkto tute ne aperas en tiu konstruanto.

Tio estas la ŝlosila struktura fakto. La platformo kreas tun-interfacon kaj trudas politikon sur ĝi; la aplikaĵo efektivigas la transporton en uzantspaco, do la aplikaĵo mem solvas sian finpunktan nomon kaj malfermas la ĉifritan konekton. Gastnoma finpunkto do eblas, ne ĉar la platformo subtenas nomojn, sed ĉar la platformo neniam vidas la finpunkton.

Unu kampo de la konstruanto akceptas adresojn: la DNS-servilojn. Ili devas esti numeraj solvilaj adresoj, kutime tiuj, kiujn la operatoro volas demandi tra la tunelo. Tiu kampo priskribas kien la aplikaĵoj sendas demandojn post kiam la tunelo staras. Ĝi diras nenion pri tio, kiel la kliento trovas la finpunkton, kaj trakti ambaŭ kiel la saman agordon estas la komenco de la konfuzo.

Du DNS-demandoj, ne unu

La unua demando estas: kien la aplikaĵoj sendas demandojn kiam la tunelo staras? La respondo estas solvila adreso ene de la tunelo, atingebla tra la tun-interfaco, numera laŭ konstruo.

La dua demando estas: kiel la kliento trovas sian propran finpunkton antaŭ ol tiu tunelo ekzistas? Tiu serĉo okazas ekster la tunelo, sur la suba reto, en la procezo de la kliento. Ĝi povas uzi nomon, kaj ĝi devas uzi solvilon atingeblan de la aparato sen la VPN.

Tri etapoj, tri malsamaj simptomoj. Unu erarmesaĝo kiel ne eblas konektiĝi kunigas ilin, kaj tial homoj redaktas la DNS-servilan kampon por ripari problemon kiu okazas antaŭ ol tiu kampo eĉ legiĝas.

Kial la starto povas deadlockiĝi

Ĉiam-aktiva kun la blokado ŝaltita signifas ke trafiko ekster la VPN estas forĵetata, inkluzive de trafiko de la aplikaĵo kiu posedas la VPN. La elirejo estas eksplicita: la aplikaĵo vokas protect() sur soketo, kiu ligas ĝin al la suba reto por ke ĝi preterpasu la tunelon kaj estu lasata eksteren. Ĉiu VPN-kliento devas fari tion por sia propra transporto, alie ĝi neniam atingus servilon.

Imagu aranĝon kie la sola solvilo kiu konas la finpunktan nomon mem kuŝas ene de la tunelo. La kliento bezonas la tunelon por solvi la nomon, kaj la nomon por konstrui la tunelon. Tio estas vera cirkla dependeco, kaj neniu klienta agordo solvas ĝin. Ĝi estas projekt-eraro, ne cimo.

Tempo malkaŝas la saman dependecon en pli mildaj formoj. Ĉe starto antaŭ la unua malŝloso la aparato eble ankoraŭ ne havas uzeblan reton; ĉe kaptita portalo la reto ekzistas sed blokas ĉion krom la portalo; ĉe transiro de Wi-Fi al poŝtelefona reto la suba reto de la protektita soketo ŝanĝiĝas kaj la kliento devas rimarki tion kaj resolvi denove. Ĉiu el ili estas starta evento kaj indas esti intence testata anstataŭ malkovrita je la 3-a matene.

Kial fiksi la respondon ne estas riparo

La tentiga flankvojo estas solvi la nomon unufoje kaj glui la rezultan adreson en numeran kampon, aŭ malmoligi ĝin en propra konstruo. Ŝajnas ke ĝi funkcias, kaj ĝi transformas nomon en momentfoton. Kiam la operatoro movas la finpunkton, per migrado, anycast-ŝanĝo aŭ nova regiona adreso, la kliento daŭre alvokas la malnovan, kaj nenio en la interfaco klarigas kial.

DNS-rikordoj portas vivdaŭron ĝuste por ke respondoj povu ŝanĝiĝi; kaŝmemorigo estas difinita per tiu daŭro, ne por ĉiam. Fiksi respondon forĵetas la mekanismon kiu faras nomon pli bona ol adreso, dum la operacia kosto de uzado de nomo restas.

Fikso ofte iras kun dua malbona kutimo: malfortigi identecajn kontrolojn ĉar la konekto nun malsukcesas alie. Kontrolo de servila identeco ne estas parto de la starta problemo, kaj malfortigi ĝin interŝanĝas DNS-ĝenon kontraŭ risko de interkapto.

Projektoj kiuj postvivas restartadon

La daŭra aranĝo estas senspektakla. Uzu klienton kiu efektivigas protektitajn soketojn ĝuste kaj solvas sian finpunkton sur la suba reto, kaj donu al ĝi nomon kiu solviĝas publike aŭ per solvilo atingebla antaŭ la tunelo. Lasu la blokadon ŝaltita; malebligi ĝin tute por ke DNS funkciu forigas la econ pro kiu la aranĝo ekzistas.

Kie la finpunkto devas resti privata, provizu eksplicitan startan vojon kiun la platformo povas uzi, ekzemple solvilon atingeblan sen la tunelo aŭ administran konekton prizorgatan de la operatoro, kaj tenu tiun escepton mallarĝa kaj posedata de politiko anstataŭ de uzanta ŝaltilo. La Android VpnService-dokumentaro estas la referenco por kio la platformo garantias, kaj la referenco VpnService.Builder konfirmas ke la DNS-kampo akceptas numerajn adresojn.

Poste kontrolu en la tri etapoj, laŭ ordo, sur freŝa konekto post restartado: la finpunkta nomo solviĝas, la tunelo establiĝas kaj la partnero aŭtentiĝas, kaj privata nomo solviĝas per la solvilo de la tunelo. Se la unua etapo malsukcesas, nenio posta povas funkcii.

• Solvado de la finpunkto okazas en la aplikaĵo, ekster la tunelo, sur protektita soketo.
• La DNS-kampo en la konstruanto estas por aplikaĵoj ene de la tunelo, ne por la propra finpunkto de la kliento.
• Solvilo atingebla nur tra la tunelo estas sakstrato, ne malrapida starto.
• Testu finpunkton, aŭtentigon kaj privatan serĉon aparte post restartado.