VPN:n DNS vastaan selaimen DoH: mitä vuototesti ei voi kertoa sinulle

Vuototestin sivu sanoo, että DNS on kunnossa, selaimen merkki sanoo turvallinen, eikä sisäinen wiki silti lataudu. Kaikki kolme voivat olla totta yhtä aikaa, koska ratkaisijan osoite ei ole sama asia kuin käytäntö, joka valitsi sen, tai polku, jonka kysely kulki. Se, mitä ihmiset kutsuvat DNS-vuodoksi, on oikeastaan yksi kysymys: mikä ratkaisija vastaanotti nimen, ja oliko valinta tahallinen? Sen selvittäminen vaatii kolme tarkistusta, ja vain viimeinen sisältää asetuksen muuttamisen.

Myytti yksi: merkki nimeää ratkaisijasi

Vuototesti ratkaisee koenimen ja raportoi osoitteen, joka vastasi. Se ei raportoi käytäntöä, joka valitsi kyseisen ratkaisijan, ja kun kysely on kääritty DNS:ään HTTPS:n yli, polulla oleva välilaite ei näe nimeä lainkaan. Kaksi hyvin erilaista konetta tuottaa saman rauhoittavan merkin: toisessa VPN työnsi 10.8.0.1-osoitteen ja selain käyttää sitä, ja toisessa selain jätti järjestelmän luettelon huomiotta ja lähetti nimen tunnelin kautta omalle salatulle palveluntarjoajalleen.

Ero on merkityksellinen hetkellä, jolloin yksityinen nimi epäonnistuu. Ensimmäisessä asetelmassa VPN:n ratkaisija vastaa yrityksen vyöhykkeestä; toisessa selain ei koskaan kysynyt siltä, joten lyhyt isäntänimi ei ratkea ja vika näyttää rikkinäiseltä VPN:ltä. Tarkistus ei ole uusi vuototesti, vaan haku nimelle, jonka tuntee vain yksi ratkaisija.

Myytti kaksi: selain poistuu tunnelista

DNS valitsee osoitteen, reititys kuljettaa yhteyden, ja ne ovat kaksi eri kerrosta. Julkiselle DoH-palveluntarjoajalle lähetetty kysely on edelleen TCP portti 443 reititettävään osoitteeseen. Jos reititystaulusi lähettää oletusreitin tunneliin, myös se kysely kulkee tunnelin kautta. Ratkaisijan brändi ei päätä polkua.

Se, mitä selaimen DoH muuttaa, on nimien vastaanottaja. Se on todellinen yksityisyyspäätös ja todellinen käytäntöpäätös, mutta ei reitityksen ohitus. Jos vaatimuksesi on, että nimet pysyvät VPN-operaattorilla, salattu kysely jollekin muulle epäonnistuu siinä vaatimuksessa, vaikka käyttää yhä tunnelia varsinaiseen yhteyteen.

Myytti kolme: jokainen VPN kumoaa jokaisen selaimen

Selaimen suojatulla DNS:llä on tiloja, ei kytkintä: pois, oletuspalveluntarjoaja varavaihtoehdolla, mukautettu malli tai käyttöjärjestelmän tai organisaation pakottama käytäntö. Juuri varavaihtoehto tuottaa satunnaisia raportteja. Kun salattu päätepiste ei ole tavoitettavissa, selain voi palata järjestelmän ratkaisijaan, joten sama kannettava ratkaisee yksityisen nimen maanantaina oikein ja tiistaina ei.

Samalla useimmat VPN-asiakasohjelmat asettavat järjestelmän ratkaisijan, kun yhteys nousee, ja palauttavat edellisen, kun se katkeaa. Selain, joka pitää mukautettua salattua ratkaisijaa, ei havaitse sitä palautusta lainkaan. Siksi sama profiili käyttäytyy eri tavoin kahdella kannettavalla ja siksi resolv.conf näyttää oikealta, kun selain yhä kysyy joltakulta muulta.

resolvectl status                 # per-link DNS servers and split-DNS domains
scutil --dns | head -30           # macOS resolver order for each domain
nslookup intranet.corp 10.8.0.1   # ask the VPN resolver directly

Suorita ne yhteyden ollessa päällä, pane merkille, mitä domeeneja kukin ratkaisija vaatii, ja vertaa siihen, mitä selain raportoi omasta tilastaan. Mozillan DoH-dokumentaatio on kohtuullinen kuvaus siitä, miten selaimen oletus- ja varakäyttäytymisen on tarkoitus toimia.

Päätöksessä on kolme syötettä, ei yksi

Yksityiset nimet, luottamus operaattoriin ja tavoitettavuus ratkaisevat oikean järjestelyn. Nimet, jotka tuntee vain VPN:n ratkaisija, pakottavat jaetun DNS:n: yksityinen jälkiliite menee työnnettyyn ratkaisijaan, kaikki muu seuraa käytäntöä, jonka valitsit julkisille nimille. Luottamus operaattoriin ratkaisee, pitäisikö julkisten nimien mennä myös tuolle ratkaisijalle vai erilliselle palvelulle. Tavoitettavuus ratkaisee, onko valitsemasi salattu ratkaisija tässä verkossa lainkaan käytettävissä.

Mikään näistä riveistä ei ole yleinen suositus. VPN:n ylläpitämä ratkaisija keskittää havainnot kyseiselle operaattorille; erillinen palvelu lisää vielä yhden kysyttyjen nimien vastaanottajan. Kumpikaan järjestely ei todista mitään säilytyksestä, ellet lue käytäntöä.

Kirjoita päätös profiilikohtaisesti, koska nämä asetukset ajautuvat. Profiili, joka työnsi ratkaisijan viime kuussa, ei ehkä työnnä tänään mitään, ja selain pitää mielellään vanhan mukautetun päätepisteen, joka yhä vastaa. Muistiin kuuluvat ratkaisijan osoite, sen omistamat jälkiliitteet ja selaimen tila, ei palvelun brändi.

Testaa käytäntö, jonka luulet määrittäneesi

Testaa nimen, älä merkin perusteella. Ratkaise julkinen nimi ja yksityinen nimi järjestelmän ratkaisijan kautta ja toista sitten selaimessa sen omalla suojatun DNS:n asetuksella siinä tilassa, jota aiot käyttää. Jos yksityinen nimi epäonnistuu vain selaimessa, olet löytänyt vastaanottajan epäsuhdan koskettamatta yhtäkään VPN-asetusta.

Yhdistä sitten uudelleen ja tarkista palautus, koska siellä siirron viat asuvat: katkaise, varmista että edellinen ratkaisija palasi, yhdistä uudelleen, varmista että työnnetty palasi. Testaa lopuksi selainta hallitulla käytännöllä, jos sellainen on, koska se tila voi hylätä muutoksesi kokonaan ja pitää hiljaa edellisen ratkaisijan.

Aloita nimiavaruuden kysymyksestä, niin vältät suurimman osan tästä. Jos koneen on päästävä sisäisiin nimiin, selaimen salattu ratkaisija on päätös vain julkisesta puolikkaasta, ja yksityinen puolikas jää siihen, mitä VPN työnsi.