Androidi alati sisse lülitatud VPN: kuidas lõpp-punkti nimi kõigepealt lahendatakse

Telefon taaskäivitub, alati sees on lubatud, ühenduste blokeerimine ilma VPN-ita on sisse lülitatud ja tunnel ei tõuse kunagi. Miski pole valesti seadistatud: blokeering teeb oma tööd ja kliendi enda katse oma lõpp-punkti jõuda on samuti sellele allutatud. Lõpp-punkt tuleb lahendada enne, kui tunnel olemas on, kliendi poolt, kellel on lubatud võrguga rääkida, samal ajal kui ühelgi teisel rakendusel pole. Arusaamine, milline komponent seda teeb ja mis järjekorras, muudab mõistatuse seadistusküsimuseks.

Mida VPN-i ehitaja tegelikult küsib

Androidi VPN-rakendus ei anna platvormile serveri aadressi. See ehitab kohaliku liidese: tunnelile aadressid ja marsruudid, lahendajad, mida rakendused sees kasutama peavad, ja siis tagastab establish() failideskriptori, mida rakendus loeb ja kirjutab toores IP-pakettidena. Kauglõpp-punkt ei esine selles ehitajas üldse.

See on võtmeline struktuurne fakt. Platvorm loob tun-liidese ja rakendab sellel poliitikat; rakendus teostab transpordi kasutajaruumis, st rakendus ise lahendab oma lõpp-punkti nime ja avab krüpteeritud ühenduse. Hostinimi lõpp-punktina on seega võimalik, mitte sellepärast, et platvorm toetab nimesid, vaid sellepärast, et platvorm ei näe lõpp-punkti kunagi.

Üks ehitaja väli võtab aadresse: DNS-serverid. Need peavad olema numbrilised lahendaja aadressid, tavaliselt need, mida operaator tahab läbi tunneli küsida. See väli kirjeldab, kuhu rakendused päringuid saadavad, kui tunnel on üleval. See ei ütle midagi selle kohta, kuidas klient lõpp-punkti leiab, ja mõlema pidamine samaks seadeks on segaduse algus.

Kaks DNS-küsimust, mitte üks

Esimene küsimus on: kuhu rakendused päringuid saadavad, kui tunnel on üleval? Vastus on lahendaja aadress tunneli sees, kättesaadav tun-liidese kaudu, oma ehituselt numbriline.

Teine küsimus on: kuidas leiab klient oma lõpp-punkti enne, kui see tunnel olemas on? See otsing toimub väljaspool tunnelit, alusvõrgus, kliendi protsessis. See võib kasutada nime ja peab kasutama lahendajat, kuhu seade pääseb ilma VPN-ita.

Kolm etappi, kolm erinevat sümptomit. Üks veateade nagu ei saa ühendust ühendab need kokku ja seetõttu muudavad inimesed DNS-serveri välja, et parandada probleemi, mis tekib enne, kui seda välja üldse loetakse.

Miks algkäivitus võib tupikusse minna

Alati sees koos aktiivse blokeeringuga tähendab, et väljaspool VPN-i olev liiklus visatakse ära, sealhulgas selle rakenduse liiklus, kellele VPN kuulub. Väljapääs on selgesõnaline: rakendus kutsub socketil protect(), mis seob selle alusvõrguga, nii et see läheb tunnelist mööda ja lastakse välja. Iga VPN-klient peab seda oma transpordi jaoks tegema, muidu ei jõuaks ta kunagi serverini.

Kujutage ette paigutust, kus ainus lahendaja, kes teab lõpp-punkti nime, asub ise tunneli sees. Kliendil on tunnelit vaja nime lahendamiseks ja nime tunnelit ehitamiseks. See on tõeline sõltuvus iseendast ja ükski kliendi seadistus seda ei lahenda. See on projekteerimisviga, mitte viga koodis.

Aeg paljastab sama sõltuvuse kergemal kujul. Enne esimest avamist käivitumisel ei pruugi seadmel veel kasutatavat võrku olla; captive portalil on võrk olemas, aga blokeerib kõik peale portaali; Wi-Fi-lt mobiilile üleminekul muutub kaitstud socketi alusvõrk ja klient peab seda märkama ja uuesti lahendama. Igaüks neist on algkäivituse sündmus ja väärib teadlikku testimist, mitte avastamist kell 3 öösel.

Miks vastuse kinnitamine pole parandus

Kiusatus on lahendada nimi korra ja kleepida saadud aadress numbrilisse välja või kõvakodeerida see oma koostes. See näib töötavat ja muudab nime hetktõmmiseks. Kui operaator lõpp-punkti liigutab, migratsiooni, anycast-muudatuse või uue piirkondliku aadressi tõttu, helistab klient endiselt vanale ega miski liideses ei selgita, miks.

DNS-kirjed kannavad eluiga just selleks, et vastused saaksid muutuda; vahemällu salvestamine on määratud selle elueaga, mitte igavesti. Vastuse kinnitamine heidab kõrvale mehhanismi, mis teeb nime aadressist paremaks, samal ajal kui nime kasutamise töökulu jääb.

Kinnitamisega käib sageli kaasas teine halb harjumus: identiteedikontrollide lõdvendamine, sest ühendus ebaõnnestub nüüd teisiti. Serveri identiteedi kontroll ei ole algkäivituse probleemi osa ja selle nõrgendamine vahetab DNS-i ebamugavuse pealtkuulamise riski vastu.

Kavandid, mis taaskäivituse üle elavad

Vastupidav lahendus on ilmetu. Kasutage klienti, mis rakendab kaitstud socketid korrektselt ja lahendab oma lõpp-punkti alusvõrgus, ja andke sellele lõpp-punkti nimi, mis lahendub avalikult või lahendaja kaudu, mis on enne tunnelit kättesaadav. Jätke blokeering sisse; selle täielik väljalülitamine, et DNS töötaks, eemaldab omaduse, mille jaoks paigutus olemas on.

Kus lõpp-punkt peab jääma privaatseks, pakkuge selgesõnalist algkäivitusteed, mida platvorm saab kasutada, näiteks lahendaja, mis on kättesaadav ilma tunnelita, või operaatori hooldatav haldusühendus, ja hoidke see erand kitsana ning poliitika, mitte kasutaja lüliti käes. Android VpnService dokumentatsioon on viide sellele, mida platvorm kaitse ja elutsükli kohta garanteerib, ja VpnService.Builder viide kinnitab, et DNS-väli võtab numbrilisi aadresse.

Seejärel kontrollige kolmes etapis, järjekorras, värskel ühendusel pärast taaskäivitust: lõpp-punkti nimi lahendub, tunnel luuakse ja partner autenditakse, ning privaatne nimi lahendub tunneli lahendaja kaudu. Kui esimene etapp ebaõnnestub, ei saa miski hilisem töötada.

• Lõpp-punkti lahendamine toimub rakenduses, väljaspool tunnelit, kaitstud socketil.
• Ehitaja DNS-väli on mõeldud tunneli sees olevatele rakendustele, mitte kliendi enda lõpp-punktile.
• Ainult tunneli kaudu kättesaadav lahendaja on tupik, mitte aeglane algus.
• Testige lõpp-punkti, autentimist ja privaatset otsingut pärast taaskäivitust eraldi.