Salaako VPN-palvelusi DNS:n vai vain seuraavan hypyn?

Salatun DNS:n ottaminen käyttöön VPN-palvelimella kuvataan usein vuodon sulkemiseksi, ja tämä kuvaus peittää sen, mikä yhteys muuttui. Hyppy asiakkaasta ratkaisijaan ja hyppy ratkaisijasta ylempään tasoon ovat erillisiä yhteyksiä, joilla on erilliset omistajat. Toisen salaaminen jättää toisen täsmälleen sellaiseksi kuin se oli.

Kirjoita muistiin, kuka vastaanottaa kyselyn kussakin vaiheessa, ennen kuin kosket asetustiedostoon.

Kaksi järjestelyä näyttävät samalta asetussivulla

Ensimmäisessä järjestelyssä laite ajaa itse DNS over TLS:ää ja tunneli vain kuljettaa tämän yhteyden valitsemaasi ratkaisijaan. TLS-istunto päättyy ratkaisijaan, eli ratkaisija näkee kyselyn ja VPN:n ulostulo näkee salatekstiä, jota se ei voi lukea. Toisessa järjestelyssä laite lähettää tavallista DNS:ää tunnelin läpi VPN-isännän välittäjälle, ja tämä välittäjä avaa oman salatun yhteytensä ylempään ratkaisijaan. Molemmat näyttävät ominaisuusluettelossa "salatulta DNS:ltä VPN:n kanssa", ja ne sijoittavat luettavan kyselyn eri rakennuksiin.

Ero on mitattavissa eikä filosofinen. Etsi TLS-istunto asiakkaasta tai palvelimesta, niin tiedät, kumpi järjestely sinulla todella on.

Kartoita ratkaisijaketju ennen kuin muutat sitä

Laske polun ratkaisijat ja nimeä kunkin rooli. Välittävä komponentti luovuttaa pyynnön toiselle ratkaisijalle, kun taas rekursiivinen ratkaisija tekee työn vastauksen löytämiseksi ja voi puhua suoraan autoritatiivisten palvelimien kanssa. Nämä roolit on määritelty erikseen juuri tästä syystä, ja RFC 9076:n ratkaisijamääritelmät kannattaa lukea ennen kuin oletat, että on olemassa yksi ainoa ylemmän tason kohde. Isäntä, joka ajaa omaa rekursiivista ratkaisijaansa, ei omista yhtä ainoaa "ylempää tasoa" salattavaksi, mikä tekee koko suunnitelmasta mitättömän.

Kysy sitten, minkä komponentin käyttöön asiakas on määritetty. VPN-profiilin työntämä DNS-osoite kertoo, minne kyselyt menevät, ei sitä, mikä prosessi niihin vastaa.

Huomioi myös vikatilanne. Jos salatusta ylemmästä tasosta tulee saavuttamaton, epäonnistuuko välittäjä suljetusti, putoaako se selkokieleen vai toiseen ratkaisijaan? Tämä päätös kuuluu kirjaan, koska se muuttaa yksityisyystakuuta hetkellä, jolloin tunneli on vähiten terve.

Varmista, mikä hyppy on salattu

Aloita asiakkaasta ja varmista, onko sillä TLS-istunto porttiin 853. Kysely, joka ratkeaa oikein portin 53 kautta, ei todista salauksesta mitään.

resolvectl status | grep -E "DNS Servers|DNS over TLS"
kdig +tls +tls-ca +tls-hostname=dns.example.net @198.51.100.53 example.com A

Siirry sitten VPN-isäntään ja etsi lähtevä salattu yhteys, jonka välittäjä avasi. Pistoketaulu kertoo, onko ylemmän tason TLS-istuntoa olemassa ja mikä prosessi sen omistaa:

ss -tunp '( dport = :853 )'
dig @127.0.0.1 example.com A +short

Jos asiakas näyttää TLS-istunnon ja palvelin ei mitään, olet ensimmäisessä järjestelyssä eikä palvelin voi lukea kyselyitä, jotka se välittää IP-kerroksessa. Jos palvelin näyttää TLS-istunnon ja asiakas tavallista portin 53 liikennettä tunnelin sisällä, olet toisessa järjestelyssä: seuraava hyppy on suojattu, mutta välittäjä lukee edelleen jokaisen nimen, jota laite pyytää. Tämä toinen tulos ei ole vika, mutta sen kutsuminen päästä päähän -salaukseksi on väärin.

Kirjaa omistaja ja vikatilanne

Omistajuus päättää, mitä voit luvata. Laitteen omistaja hallitsee asiakaspään salattua yhteyttä, kun taas VPN-ylläpitäjä hallitsee seuraavaa yhteyttä, jonka sen välittäjä luo. Se, joka ei hallitse kumpaakaan, voi vain kuvailla polun.

Ennen kuin otat mitään käyttöön, tarkista sisäinen nimeäminen. Organisaation nimien lähettäminen julkiselle ratkaisijalle ei ole vastaava suunnittelu, eikä split-horizon-vyöhyke, joka on olemassa vain verkon sisällä, ratkea ylemmässä tasossa lainkaan. Testaa muutoksen jälkeen yksi sisäinen ja yksi julkinen nimi ja säilytä tulos asetusmuutoksen kanssa. Jos salattu polku rikkoo sisäisten isäntien ratkaisun, korjaus on rajattu ratkaisijasääntö eikä leveämpi tunneli.

Lopeta kirjoittamalla yksi lause kutakin hyppyä kohden: mikä komponentti vastaanotti kyselyn, oliko hyppy salattu ja kuka voi lukea nimen. Kun VPN-isäntää koskeva lause yhä sanoo, että se voi lukea kyselyitä, dokumentaation pitäisi sanoa niin, koska kaaviota, joka väittää muuta, uskoo joku, joka ei koskaan ajanut komentoja.