Vai jūsu VPN šifrē DNS, vai tikai nākamo lēcienu?

Šifrēta DNS ieslēgšana VPN serverī bieži tiek aprakstīta kā noplūdes aizvēršana, un šis apraksts slēpj, kurš savienojums mainījās. Lēciens no klienta līdz resolverim un lēciens no resolvera līdz augšupējam līmenim ir atsevišķi savienojumi ar atsevišķiem īpašniekiem. Šifrējot vienu no tiem, otrs paliek tieši tāds, kāds bija.

Pierakstiet, kas saņem vaicājumu katrā posmā, pirms aiztiekat konfigurācijas failu.

Divi izkārtojumi iestatījumu lapā izskatās vienādi

Pirmajā izkārtojumā ierīce pati izpilda DNS over TLS, un tunelis vienkārši pārnes šo savienojumu uz jūsu izvēlēto resolveru. TLS sesija beidzas resolverī, kas nozīmē, ka resolvers redz vaicājumu, bet VPN izeja redz šifrētu tekstu, ko tā nevar nolasīt. Otrajā izkārtojumā ierīce sūta parasto DNS caur tuneli uz pāradresētāju VPN hostā, un šis pāradresētājs atver savu šifrēto savienojumu ar augšupēju resolveru. Funkciju sarakstā abi izskatās kā "šifrēts DNS ar VPN", tomēr lasāmo vaicājumu tie novieto dažādās ēkās.

Atšķirība ir izmērāma, nevis filozofiska. Meklējiet TLS sesiju klientā vai serverī, un jūs uzzināsiet, kurš izkārtojums jums patiešām ir.

Pirms maiņas iezīmējiet resolveru ķēdi

Saskaitiet resolverus ceļā un nosauciet katra lomu. Pāradresācijas komponents nodod pieprasījumu citam resolveram, savukārt rekursīvais resolvers veic atbildes atrašanas darbu un var tieši sazināties ar autoritatīvajiem serveriem. Šīs lomas ir atsevišķi definētas tieši šī iemesla dēļ, un RFC 9076 resolveru definīcijas ir vērts izlasīt, pirms pieņemat, ka pastāv viens vienīgs augšupējs galamērķis. Hostam, kas uztur savu rekursīvo resolveru, nav viena "augšupēja", ko šifrēt, un tas padara visu plānu nederīgu.

Pēc tam pajautājiet, kuru komponentu klients ir konfigurēts izmantot. VPN profila piedāvātā DNS adrese parāda, kur vaicājumi dodas, nevis kurš process uz tiem atbild.

Ņemiet vērā arī uzvedību kļūmes gadījumā. Ja šifrētais augšupējais līmenis kļūst nesasniedzams, vai pāradresētājs nokrīt slēgti, atgriežas pie atklāta teksta vai pārslēdzas uz citu resolveru? Šim lēmumam jābūt ierakstā, jo tas maina privātuma garantiju tieši tajā brīdī, kad tunelis ir vismazāk veselīgs.

Pārbaudiet, kurš lēciens ir šifrēts

Sāciet ar klientu un apstipriniet, vai tam ir TLS sesija uz 853. portu. Vaicājums, kas pareizi atrisinās caur 53. portu, neko nepierāda par šifrēšanu.

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

Pēc tam pārejiet uz VPN hostu un meklējiet izejošo šifrēto savienojumu, ko atvēra pāradresētājs. Ligzdu tabula parāda, vai pastāv augšupēja TLS sesija un kurš process to pārvalda:

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

Ja klients rāda TLS sesiju, bet serveris nē, jūs esat pirmajā izkārtojumā, un serveris nevar nolasīt vaicājumus, ko pārsūta IP slānī. Ja serveris rāda TLS sesiju, bet klients tunelī rāda parastu 53. porta datplūsmu, jūs esat otrajā izkārtojumā: tālākais lēciens ir aizsargāts, un pāradresētājs joprojām nolasa katru vārdu, ko ierīce pieprasa. Otrais rezultāts nav kļūme, taču to saukt par šifrēšanu no gala līdz galam ir nepareizi.

Pierakstiet īpašnieku un uzvedību kļūmes gadījumā

Īpašumtiesības nosaka, ko drīkstat solīt. Ierīces īpašnieks kontrolē klienta puses šifrēto savienojumu, bet VPN administrators kontrolē tālāko savienojumu, ko izveido viņa pāradresētājs. Ikviens, kas nepārvalda nevienu no tiem, var tikai aprakstīt ceļu.

Pirms kaut ko ieslēdzat, pārbaudiet iekšējos nosaukumus. Organizācijas nosaukumu sūtīšana uz publisku resolveru nav līdzvērtīgs risinājums, un split-horizon zona, kas pastāv tikai tīkla iekšienē, augšupējā līmenī nemaz netiks atrisināta. Pēc izmaiņām pārbaudiet vienu iekšēju un vienu publisku nosaukumu un saglabājiet rezultātu kopā ar konfigurācijas izmaiņām. Ja šifrētais ceļš sabojā iekšējo hostu atrisināšanu, labojums ir ierobežotas darbības resolvera kārtula, nevis plašāks tunelis.

Nobeigumā uzrakstiet vienu teikumu katram lēcienam: kurš komponents saņēma vaicājumu, vai šis lēciens bija šifrēts un kas var nolasīt nosaukumu. Ja teikums par VPN hostu joprojām saka, ka tas var nolasīt vaicājumus, dokumentācijai tas jāsaka, jo diagrammai, kas apgalvo pretējo, uzticēsies kāds, kurš nekad nav izpildījis komandas.