Fersiferet jo VPN DNS, of allinnich de folgjende hop?

It ynskeakeljen fan fersifere DNS op 'e VPN-tsjinner wurdt faak beskreaun as it sluten fan in lek, en dy beskriuwing ferberget hokker ferbining feroare is. De hop fan kliïnt nei oplosser en de hop fan oplosser nei de upstream binne aparte ferbiningen mei aparte eigners. It fersiferjen fan ien lit de oare krekt sa't dy wie.

Skriuw op wa't de oanfraach yn elke stap krijt foardat jo in konfiguraasjebestân oanreitsje.

Twa opstellings sjogge der itselde út op in ynstellingsside

Yn 'e earste opstelling draait it apparaat sels DNS over TLS, en de tunnel draacht dy ferbining gewoan nei in oplosser dy't jo keazen hawwe. De TLS-sesje einiget by de oplosser, wat betsjut dat de oplosser de oanfraach sjocht en de VPN-útgong fersifere tekst sjocht dy't er net lêze kin. Yn 'e twadde opstelling stjoert it apparaat gewoane DNS troch de tunnel nei in trochstjoerder op 'e VPN-host, en dy trochstjoerder iepenet syn eigen fersifere ferbining nei in upstream-oplosser. Beide sjogge der as "fersifere DNS mei in VPN" út yn in funksjelist, en se pleatse de lêsbere oanfraach yn ferskillende gebouwen.

It ferskil is mjitber ynstee fan filosofysk. Sjoch nei de TLS-sesje op 'e kliïnt of op 'e tsjinner, en jo witte hokker opstelling jo eins hawwe.

Yn kaart bringe fan de oplosserkeatling foardat jo dy feroarje

Tel de oplossers op it paad en neam de rol fan elk. In trochstjoerende komponint jout in fersyk oan in oare oplosser, wylst in rekursive oplosser it wurk docht om in antwurd te finen en miskien direkt mei autoritative tsjinners praat. Dy rollen wurde krekt dêrom apart definiearre, en de oplosserdefinysjes yn RFC 9076 binne it lêzen wurdich foardat jo oannimme dat der ien inkelde upstream-bestimming bestiet. In host dy't syn eigen rekursive oplosser draait, hat gjin inkelde "upstream" om te fersiferjen, wat it hiele plan ûnjildich makket.

Freegje dan hokker komponint de kliïnt konfigurearre is om te brûken. In DNS-adres dat troch it VPN-profyl drukt wurdt, fertelt jo wêr't oanfragen hinne geane, net hokker proses se beantwurdet.

Merk ek it gedrach by falen op. As de fersifere upstream ûnberikber wurdt, falt de trochstjoerder dan sletten, falt er werom op iepen tekst, of falt er werom op in oare oplosser? Dat beslút heart yn it ferslach, want it feroaret de privacygarânsje op it momint dat de tunnel it minst sûn is.

Kontrolearje hokker hop fersifere is

Begjin op 'e kliïnt en befêstigje oft dy in TLS-sesje nei poarte 853 hat. In oanfraach dy't korrekt troch poarte 53 oplost, bewiist neat oer fersifering.

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

Gean dan nei de VPN-host en sykje de útgeande fersifere ferbining dy't de trochstjoerder iepene hat. De sockettabel fertelt jo oft der in upstream-TLS-sesje bestiet, en hokker proses dy besit:

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

As de kliïnt in TLS-sesje sjen lit en de tsjinner gjin, dan binne jo yn 'e earste opstelling en kin de tsjinner oanfragen dy't er op IP-nivo trochstjoert net lêze. As de tsjinner de TLS-sesje sjen lit en de kliïnt gewoan ferkear op poarte 53 binnen de tunnel, dan binne jo yn 'e twadde opstelling: de folgjende hop is beskerme, en de trochstjoerder lêst noch altyd elke namme dy't it apparaat freget. Dat twadde resultaat is gjin mislearring, mar it ein-tot-ein-fersifering neame is ferkeard.

Skriuw de eigner en it gedrach by falen op

Eigenskip bealt wat jo belove meie. De eigner fan it apparaat kontrolearret in fersifere ferbining oan 'e kliïntkant, wylst de VPN-administrator de folgjende ferbining kontrolearret dy't syn trochstjoerder makket. Wa't gjin fan beide betsjinnet, kin allinnich it paad beskriuwe.

Kontrolearje foardat jo eat ynskeakelje de ynterne nammejouwing. It stjoeren fan organisaasjenammen nei in iepenbiere oplosser is gjin lykweardich ûntwerp, en in split-horizon-sône dy't allinnich binnen it netwurk bestiet, sil hielendal net upstream oplosse. Test nei de feroaring ien ynterne en ien iepenbiere namme, en bewarje it resultaat by de konfiguraasjeferoaring. As it fersifere paad de resolúsje foar ynterne hosts brekt, is de oplossing in oplosserregel mei beheind berik, net in bredere tunnel.

Einigje mei ien sin per hop: hokker komponint de oanfraach krige, oft dy hop fersifere wie, en wa't de namme lêze kin. As de sin foar de VPN-host noch altyd seit dat er oanfragen lêze kin, soe de dokumintaasje dat sizze moatte, want in diagram dat oars beweart, sil fertroud wurde troch immen dy't de opdrachten nea útvoerd hat.