Versleutel jou VPN net DNS, of net die volgende hop?
Versleutelde DNS op 'n VPN-bediener beskerm 'n ander hop as DoT aan die kliëntkant. Spoor na wie elke navraag ontvang voordat jy enigiets aktiveer.
Om versleutelde DNS op die VPN-bediener te aktiveer, word dikwels beskryf as om 'n lek te sluit, en daardie beskrywing verberg watter verbinding verander het. Die hop van kliënt na oplosser en die hop van oplosser na die opstroom is afsonderlike verbindings met afsonderlike eienaars. Om een van hulle te versleutel, laat die ander presies soos dit was.
Skryf neer wie die navraag by elke stadium ontvang voordat jy aan 'n konfigurasielêer raak.
Twee reëlings lyk dieselfde op 'n instellingsblad
In die eerste reëling doen die toestel self DNS over TLS, en die tonnel dra bloot daardie verbinding na 'n oplosser wat jy gekies het. Die TLS-sessie eindig by die oplosser, wat beteken die oplosser sien die navraag en die VPN-uitgang sien syferteks wat hy nie kan lees nie. In die tweede reëling stuur die toestel gewone DNS deur die tonnel na 'n aanstuurder op die VPN-gasheer, en daardie aanstuurder open sy eie versleutelde verbinding na 'n oplosser op die opstroom. Albei lyk soos "versleutelde DNS met 'n VPN" in 'n kenmerke-lys, en hulle plaas die leesbare navraag in verskillende geboue.
Die verskil is meetbaar eerder as filosofies. Soek die TLS-sessie by die kliënt, of soek dit by die bediener, en jy leer watter reëling jy werklik het.
Karteer die oplosserketting voordat jy dit verander
Tel die oplossers op die pad en noem die rol van elkeen. 'n Aanstuurkomponent gee 'n versoek aan 'n ander oplosser oor, terwyl 'n rekursiewe oplosser die werk doen om 'n antwoord te vind en moontlik direk met gesaghebbende bedieners praat. Daardie rolle word juis afsonderlik gedefinieer, en die RFC 9076-oplosserdefinisies is die moeite werd om te lees voordat jy aanneem dat daar 'n enkele opstroombestemming bestaan. 'n Gasheer wat sy eie rekursiewe oplosser bedryf, het geen enkele "opstroom" om te versleutel nie, wat die hele plan verydel.
Vra dan watter komponent die kliënt gekonfigureer is om te gebruik. 'n DNS-adres wat deur die VPN-profiel gestuur word, sê vir jou waarheen navrae gaan, nie watter proses hulle beantwoord nie.
Let ook op die falinggedrag. As die versleutelde opstroom onbereikbaar word, misluk die aanstuurder dan geslote, val hy terug na gewone teks, of val hy terug na 'n ander oplosser? Daardie besluit hoort in die rekord, want dit verander die privaatheidswaarborg op die oomblik wanneer die tonnel die minste gesond is.
Verifieer watter hop versleutel is
Begin by die kliënt en bevestig of dit 'n TLS-sessie na poort 853 het. 'n Navraag wat korrek deur poort 53 oplos, bewys niks oor versleuteling nie.
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
Gaan dan na die VPN-gasheer en soek die uitgaande versleutelde verbinding wat die aanstuurder geopen het. Die socket-tabel sê vir jou of daar 'n TLS-sessie op die opstroom bestaan, en watter proses dit besit:
ss -tunp '( dport = :853 )'
dig @127.0.0.1 example.com A +short
As die kliënt 'n TLS-sessie wys en die bediener geen, is jy in die eerste reëling en kan die bediener nie navrae lees wat hy op die IP-vlak aanstuur nie. As die bediener die TLS-sessie wys en die kliënt gewone poort 53-verkeer binne die tonnel wys, is jy in die tweede reëling: die volgende hop is beskerm, en die aanstuurder lees steeds elke naam wat die toestel vra. Daardie tweede uitslag is nie 'n mislukking nie, maar om dit end-tot-end-versleuteling te noem, is verkeerd.
Teken die eienaar en die falinggedrag aan
Eienaarskap bepaal wat jy mag belowe. Die toesteleienaar beheer 'n versleutelde verbinding aan die kliëntkant, terwyl die VPN-administrateur die volgende verbinding beheer wat sy aanstuurder skep. Enigiemand wat nie een van die twee bedryf nie, kan net die pad beskryf.
Kontroleer interne naamgewing voordat jy enigiets aktiveer. Om organisasiename na 'n openbare oplosser te stuur, is nie 'n gelykwaardige ontwerp nie, en 'n split-horizon-sone wat net binne die netwerk bestaan, sal glad nie op die opstroom oplos nie. Toets een interne naam en een openbare naam ná die verandering, en hou die resultaat by die konfigurasieverandering. As die versleutelde pad die oplossing vir interne gashere breek, is die regstelling 'n oplosserreël met 'n beperkte omvang eerder as 'n wyer tonnel.
Sluit af deur een sin per hop te skryf: watter komponent die navraag ontvang het, of daardie hop versleutel was, en wie die naam kan lees. Wanneer die sin vir die VPN-gasheer steeds sê dat hy navrae kan lees, behoort die dokumentasie dit te sê, want 'n diagram wat anders beweer, sal vertrou word deur iemand wat nooit die opdragte uitgevoer het nie.