Android altid-slået VPN: hvordan slutpunktets navn opløses først
Android blokerer trafik, før tunnelen findes, men klienten skal stadig opløse sit slutpunkt. Her er rækkefølgen, og hvor det går i baglås.
Telefonen genstarter, altid slået til og bloker forbindelser uden VPN er aktive, og tunnelen kommer aldrig op. Intet er forkert konfigureret: blokeringen gør sit arbejde, og klientens eget forsøg på at nå slutpunktet er også underlagt den. Slutpunktet skal opløses, før tunnelen findes, af en klient, der må tale med netværket, mens ingen andre apps må.
Hvad VPN-byggeren faktisk beder om
En Android VPN-app giver ikke platformen en serveradresse. Den bygger en lokal grænseflade: adresser og ruter, de resolvere apps skal bruge indeni, og establish() returnerer en fildeskriptor, som appen læser og skriver som rå IP-pakker. Det fjerne slutpunkt optræder slet ikke.
Det er den centrale strukturelle kendsgerning. Platformen opretter en tun-grænseflade og håndhæver politik på den; appen implementerer transporten i brugerrummet, altså opløser den selv sit slutpunktsnavn og åbner den krypterede forbindelse. Et værtsnavn er derfor muligt, ikke fordi platformen understøtter navne, men fordi den aldrig ser slutpunktet.
Ét felt i byggeren tager adresser: DNS-serverne. De skal være numeriske resolveradresser, normalt dem operatøren vil have spurgt gennem tunnelen. Feltet beskriver, hvor apps sender forespørgsler, når tunnelen er oppe. Det siger intet om, hvordan klienten finder slutpunktet, og at behandle de to som samme indstilling er, hvor forvirringen begynder.
To DNS-spørgsmål, ikke ét
Det første spørgsmål er: hvor apps sender forespørgsler, når tunnelen er oppe? Svaret er en resolveradresse inde i tunnelen, nåbar gennem tun, numerisk af natur.
Det andet spørgsmål er: hvordan finder klienten sit eget slutpunkt, før den tunnel findes? Opslaget sker uden for tunnelen, på det underliggende netværk, i klientens proces. Det kan bruge et navn og skal bruge en resolver, enheden kan nå uden VPN.
| Fase | Hvem opløser | Vej | Sådan ser fejl ud |
|---|---|---|---|
| Slutpunktopslag | VPN-appen | Underliggende netværk, beskyttet socket | Forbinder aldrig; ingen trafik på tun |
| Peer-godkendelse | Klient og server | Tunneltransport | Forbinder og falder; certifikat- eller nøglefejl |
| Privat navneopslag | Apps gennem tunnelen | Resolver inde i tun | Tunnel oppe, interne sider opløses ikke |
Tre faser, tre forskellige symptomer. Én fejlmeddelelse som kan ikke forbinde slår dem sammen, og derfor redigerer folk DNS-serverfeltet for at rette et problem, der opstår, før feltet læses.
Hvorfor opstarten kan gå i baglås
Altid slået til med blokeringen aktiv dropper trafik uden for VPN-tunnelen, også fra den app, der ejer den. Undvejen er eksplicit: appen kalder protect() på en socket og binder den til det underliggende netværk, så den omgår tunnelen. Enhver VPN-klient skal gøre dette for sin transport, ellers kunne den aldrig nå en server.
Forestil dig en udrulning, hvor den eneste resolver, der kender slutpunktets navn, selv ligger inde i tunnelen. Klienten har brug for tunnelen til at opløse navnet og navnet til at bygge tunnelen. Det er en ægte cirkulær afhængighed, og ingen klientkonfiguration løser den. Det er en designfejl, ikke en fejl i koden.
Tiden viser samme afhængighed mildere: ved opstart før første oplåsning har enheden måske intet brugbart netværk; på en captive portal blokeres alt undtagen portalen; ved skift fra Wi-Fi til mobilnet ændres den beskyttede sockets netværk, og klienten skal opdage det og opløse igen. Hver af dem er en opstartsbegivenhed og bør testes med vilje frem for at blive opdaget klokken 3 om natten.
Hvorfor fastlåsning af svaret ikke er en rettelse
Den fristende omvej er at opløse navnet én gang og sætte adressen i et numerisk felt eller hardcode den i et eget build. Det ser ud til at virke, og det forvandler et navn til et øjebliksbillede. Når operatøren flytter slutpunktet, ringer klienten stadig til den gamle adresse, og intet i brugerfladen forklarer hvorfor.
DNS-poster har en levetid netop for at svar kan ændre sig; caching defineres ud fra den levetid, ikke for evigt. At fastlåse et svar kasserer den mekanisme, der gør et navn bedre end en adresse.
Fastlåsning følger ofte med en anden dårlig vane: at lempe identitetskontroller, fordi forbindelsen nu fejler anderledes. Verifikation af serveridentitet er ikke en del af opstartsproblemet, og at svække den bytter en DNS-gener til en aflytningsrisiko.
Design, der overlever en genstart
Den holdbare ordning er udramatisk. Brug en klient, der implementerer beskyttede sockets korrekt og opløser sit slutpunkt på det underliggende netværk, og giv den et navn, der opløses offentligt eller gennem en resolver, der kan nås før tunnelen. Lad blokeringen være slået til.
Hvor slutpunktet skal forblive privat, skal du stille en eksplicit opstartsvej til rådighed, som platformen kan bruge, fx en resolver der kan nås uden tunnelen, og holde den undtagelse smal og ejet af politik frem for af en brugertoggle. Android VpnService-dokumentationen er reference for beskyttelse og livscyklus, og VpnService.Builder-referencen bekræfter, at DNS-feltet tager numeriske adresser.
Kontroller derefter de tre faser i rækkefølge på en frisk forbindelse efter en genstart: navnet opløses, tunnelen etableres og peer-godkendelsen lykkes, og et privat navn opløses gennem tunnelens resolver. Hvis fase et fejler, kan intet senere virke.
- Slutpunktets opløsning sker i appen, uden for tunnelen, på en beskyttet socket.
- DNS-feltet i byggeren er til apps inde i tunnelen, ikke til klientens eget slutpunkt.
- En resolver, der kun kan nås gennem tunnelen, er en blindgyde, ikke en langsom start.
- Test slutpunkt, godkendelse og privat opslag hver for sig efter en genstart.