Yksityinen DNS vastaan VPN: mitä kukin kerros todella kattaa
Seuraa yhtä pyyntöä yksityisen DNS:n näytöltä tunneliin: mitä kukin kerros näkee, missä kaksi eroavat ja miksi sisäiset nimet ovat se kohta, jossa se hajoaa.
Puhelimessasi on yksityinen DNS asetettu tarjoajan isäntänimeen ja VPN-sovellus käynnissä samanaikaisesti. On kohtuullista olettaa, että jompikumpi vastaa nyt nimikyselyistä. Kumpikaan ei vastaa, siinä merkityksessä kuin tuo lause antaa ymmärtää, ja nopein tapa nähdä miksi on seurata yhtä pyyntöä siitä hetkestä, kun napautat linkkiä.
Nämä kaksi ominaisuutta sijaitsevat saman matkan eri kohdissa. Yksityinen DNS salaa kysymyksen, jonka esität resolverille. VPN muuttaa reitin, jonka vastauksen yhteys ottaa.
Käy siis läpi järjestyksessä laitteella, jossa molemmat ovat käytössä, ja pane merkille, mitä kukin kerros voi vielä nähdä.
Vaihe yksi: kysely lähtee sovelluksesta
Napautat linkkiä. Ennen kuin mikään yhdistää, sovellus tarvitsee osoitteen tuolle isäntänimelle. Androidissa asiaankuuluva näyttö on Asetukset, Verkko ja internet, Yksityinen DNS. Jos valitset Yksityisen DNS:n tarjoajan isäntänimen, laite siirtyy tiukkaan tilaan: se tekee DNS:ää TLS:n yli tuohon isäntänimeen portissa 853, ja jos salattu vaihto epäonnistuu, kysely epäonnistuu sen sijaan, että se hiljaa palaisi selkokieliseen tekstiin portissa 53.
Tämä on merkittävä ero Automaattiseen, joka käyttää opportunistista salausta ja käyttää mielellään salaamatonta resolveria, kun verkko häiritsee. Jos tavoitteesi on, ettei kyselyitä koskaan tehdä selkokielisenä, tiukka tila ja tarjoajan isäntänimi on se asetus, joka vastaa sitä.
Tässä on ensimmäinen asia, jonka läpikäynti paljastaa: kysely on suojattu paikallisverkkoa vastaan, ja resolveri saa silti tietää nimen. Salaus kattaa hypyn. Tuon resolverin ylläpitäjä näkee kyselyn, koska sen tehtävä on vastata siihen.
Vaihe kaksi: yhteys ottaa eri reitin
Resolveri palauttaa osoitteen ja sovellus yhdistää siihen. Tähän vaiheeseen ei vaikuta se, miten kysely salattiin. Ilman tunnelia yhteys lähtee tavallisesta julkisesta osoitteestasi, ja kohde-IP ja TLS-kättely tekevät isäntänimen yleensä joka tapauksessa verkkoon näkyväksi, salatulla DNS:llä tai ilman.
Kytke VPN päälle, ja tämä on se vaihe, joka muuttuu. Asiakasohjelman reitityskäytäntöä vastaava liikenne kulkee tunnelin läpi, paikallisverkko näkee yhteyden VPN-päätepisteeseen, ja sivusto näkee yleensä lähtöosoitteen. Nimien selvitys voi myös kulkea tunnelin sisällä riippuen siitä, mitä asiakasohjelma välittää.
Tuo erottelu on koko vertailu yhdessä lauseessa. DNS-salaus vastaa siihen, kuka voi lukea kysymyksen. VPN vastaa siihen, minne keskustelu menee.
Vaihe kolme: tunnelin sisällä DNS:stä tulee käytäntökysymys
Nyt kaksi ominaisuutta vaikuttavat yhdessä, ja selain on tavallinen yllätysten lähde. Selain, jolla on oma suojatun DNS:n asetus, voi lähettää kyselyt valitsemalleen resolverille HTTPS:n yli sen sijaan, että se kysyisi käyttöjärjestelmältä. Androidin yksityisen DNS:n asetus ei ylety tuohon päätökseen.
Firefoxissa kytkin on kohdassa Asetukset, Tietosuoja ja turvallisuus, Ota suojattu DNS käyttöön. Chromessa se on kohdassa Asetukset, Tietosuoja ja turvallisuus, Käytä suojattua DNS:ää. Molemmat voidaan asettaa tiettyyn tarjoajaan tai jättää pois päältä, ja kun ne ovat päällä, tunnelin DNS-asetus ohitetaan näiden kyselyiden osalta, vaikka sivuliikenne käyttää yhä tunnelia.
Jos VPN välittää oman resolverinsa ja selain pitää kiinni omastaan, saat jaon: nimet selvitetään, sivut latautuvat, ja ne kyselyt, joiden piti kulkea tunnelin kautta, menivät suoraan ulos. Resolverin osoite, joka poikkeaa VPN-päätepisteestä, ei sinänsä ole todiste vuodosta, mutta kyselypolku, joka on ristiriidassa ilmoittamasi aikomuksen kanssa, kannattaa korjata.
Vaihe neljä: sisäiset nimet ovat se kohta, jossa se hajoaa
Yhdistä työ-VPN:ään ja avaa intranet-isäntä. Jos selaimen suojattu DNS on päällä ja osoittaa julkiseen resolveriin, sitä nimeä ei ole selaimelle. Tunneli on pystyssä, kaikki muu toimii, ja yksi isäntänimi epäonnistuu virheellä, joka näyttää siltä kuin sivusto olisi alhaalla.
Sama vika näkyy päinvastoin Androidissa. Tiukka yksityinen DNS julkisen tarjoajan kanssa ei selvitä nimiä, jotka vain sisäinen resolveri tuntee, eikä tiukassa tilassa ole varareittiä. Puhelimen DNS:n jakaminen julkisen salatun resolverin ja yrityksen resolverin kesken ei ole asetus; se on reitityskäytäntöä koskeva kysymys, johon on vastattava sen, joka VPN:ää ylläpitää.
Tarkista tämä ennen kuin syytät tunnelia: kysy sisäinen nimi ja sitten sama nimi selaimen suojattu DNS pois kytkettynä. Jos se selviää, ongelma oli resolverin valinta, ei yhteys.
Mitä läpikäynti käskee sinua muuttamaan
Neljä näyttöä kantaa lähes kaiken. Katso ne tässä järjestyksessä ja kirjoita ylös, mitä kukin sanoo, sillä vastaus on yleensä näkyvissä yhdistelmässä:
- Androidin asetukset, Verkko ja internet, Yksityinen DNS: Automaattinen tai tarjoajan isäntänimi, ja mikä isäntänimi.
- Selaimen suojatun DNS:n asetus: pois päältä tai kiinnitetty tiettyyn resolveriin.
- VPN-asiakasohjelman DNS-käytäntö: välittääkö se resolverin, ja sulkeeko jaettu tunneli pois jotain, joka tarvitsee yhä nimiä?
- Sisäisen isäntänimen testi tunnelin ollessa pystyssä, ajettu kahdesti, kerran selaimen DNS päällä ja kerran pois.
Sovita sitten korjaus vaatimukseen, ei päinvastoin. Jos vaatimus on, että kyselyt lähtevät salattuina ja menevät valitsemaasi resolveriin, aseta tiukka yksityinen DNS ja saa selain olemaan samaa mieltä. Jos vaatimus on, että liikenne lähtee muualle, määritä tunneli ja lakkaa odottamasta, että DNS-asetus siirtäisi osoitteesi.
Ja pidä rajat näkyvissä. Kumpikaan ominaisuus ei tee vihamielisestä kohteesta turvallista, eikä kumpikaan poista identiteettiä, jolla olet kirjautunut sisään. Salaus muuttaa sitä, kuka voi lukea kysymyksen; tunneli muuttaa sitä, minne yhteys menee; mikään siitä ei anonymisoi tiliä.