Kas teie VPN krüpteerib DNS-i või ainult järgmise hüppe?

Krüpteeritud DNS-i lubamist VPN-serveris kirjeldatakse sageli lekke sulgemisena ning see kirjeldus varjab, milline ühendus muutus. Hüpe kliendist lahendajani ja hüpe lahendajast ülemkihini on eraldi ühendused eraldi omanikega. Ühe krüpteerimine jätab teise täpselt selliseks, nagu see oli.

Kirjutage üles, kes päringu igas etapis vastu võtab, enne kui puudutate konfiguratsioonifaili.

Kaks paigutust näevad seadete lehel ühesugused välja

Esimeses paigutuses jooksutab seade ise DNS over TLS-i ja tunnel lihtsalt kannab selle ühenduse teie valitud lahendajani. TLS-sessioon lõpeb lahendaja juures, mis tähendab, et lahendaja näeb päringut ja VPN-i väljund näeb šifriteksti, mida ta lugeda ei saa. Teises paigutuses saadab seade tavalise DNS-i läbi tunneli VPN-hostis olevale edastajale ja see edastaja avab oma krüpteeritud ühenduse ülemkihi lahendajaga. Mõlemad näevad funktsioonide loendis välja nagu "VPN-iga krüpteeritud DNS", kuid paigutavad loetava päringu erinevatesse hoonetesse.

Erinevus on mõõdetav, mitte filosoofiline. Otsige TLS-sessiooni kliendis või serveris ja saate teada, milline paigutus teil tegelikult on.

Kaardistage lahendajate ahel enne, kui seda muudate

Loendage tee peal olevad lahendajad ja nimetage igaühe roll. Edastav komponent annab päringu edasi teisele lahendajale, samal ajal kui rekursiivne lahendaja teeb töö vastuse leidmiseks ja võib otse suhelda autoriteetsete serveritega. Need rollid on just sellepärast eraldi määratletud ja RFC 9076 lahendaja määratlused on lugemist väärt enne, kui eeldate, et on olemas üksainus ülemkihi sihtkoht. Host, mis jooksutab oma rekursiivset lahendajat, ei oma ühtset "ülemkihti", mida krüpteerida, mis muudab kogu plaani kehtetuks.

Seejärel küsige, millist komponenti on klient konfigureeritud kasutama. VPN-profiili poolt saadetud DNS-aadress ütleb, kuhu päringud lähevad, mitte milline protsess neile vastab.

Pange tähele ka rikke käitumist. Kui krüpteeritud ülemkiht muutub kättesaamatuks, kas edastaja nurjub suletult, langeb tagasi avatekstile või langeb tagasi teisele lahendajale? See otsus kuulub kirjesse, sest see muudab privaatsustagatist hetkel, mil tunnel on kõige vähem terve.

Kontrollige, milline hüpe on krüpteeritud

Alustage kliendist ja kinnitage, kas sellel on TLS-sessioon pordi 853 suunas. Päring, mis laheneb pordi 53 kaudu õigesti, ei tõesta krüpteerimise kohta midagi.

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

Seejärel minge VPN-hosti juurde ja otsige väljuvat krüpteeritud ühendust, mille edastaja avas. Socketite tabel ütleb, kas ülemkihi TLS-sessioon on olemas ja milline protsess seda omab:

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

Kui klient näitab TLS-sessiooni ja server mitte, olete esimeses paigutuses ning server ei saa lugeda päringuid, mida ta IP-kihis edasi saadab. Kui server näitab TLS-sessiooni ja klient tavalist pordi 53 liiklust tunneli sees, olete teises paigutuses: järgmine hüpe on kaitstud, kuid edastaja loeb endiselt iga nime, mida seade küsib. See teine tulemus ei ole rike, kuid selle nimetamine otsast-otsani krüpteerimiseks on vale.

Kirjutage üles omanik ja rikke käitumine

Omandisuhe otsustab, mida tohib lubada. Seadme omanik kontrollib kliendipoolset krüpteeritud ühendust, samal ajal kui VPN-administraator kontrollib järgmist ühendust, mille tema edastaja loob. Kes ei halda kumbagi, saab ainult teed kirjeldada.

Enne millegi lubamist kontrollige sisemist nimekasutust. Organisatsiooni nimede saatmine avalikku lahendajasse ei ole samaväärne lahendus ja split-horizon-tsoon, mis eksisteerib ainult võrgu sees, ei lahene ülemkihis üldse. Pärast muudatust testige üht sisemist ja üht avalikku nime ning hoidke tulemust koos konfiguratsioonimuudatusega. Kui krüpteeritud tee rikub sisemiste hostide lahendamise, on parandus piiratud ulatusega lahendajareegel, mitte laiem tunnel.

Lõpetage, kirjutades iga hüppe kohta ühe lause: milline komponent päringu vastu võttis, kas see hüpe oli krüpteeritud ja kes saab nime lugeda. Kui VPN-hosti lause ütleb endiselt, et see saab päringuid lugeda, peaks dokumentatsioon seda ütlema, sest diagrammi, mis väidab vastupidist, usub keegi, kes neid käske kunagi ei käivitanud.