Permetre DNS només a través del vostre resolutor VPN: un recorregut
Seguiu una consulta de nom des del navegador fins a la resposta. Vegeu on es tria el resolutor, on el tallafoc l’imposa i què no cobreix mai una regla del port 53.
Seguiu una consulta de nom des del moment en què l’escriviu. El navegador pregunta al sistema operatiu, el sistema operatiu pregunta al resolutor que tria la seva política, i la consulta surt del dispositiu per una interfície i un transport qualsevol. El vostre disseny de VPN diu que la resposta ha de venir d’un resolutor concret per un camí concret. La bretxa entre aquestes dues afirmacions és el que configureu i després feu complir.
Pas 1: anomeneu el resolutor i el camí
Anoteu tres coses abans de tocar cap tallafoc: l’adreça del resolutor, el protocol i el port que espereu, i la interfície per la qual ha de sortir la consulta. Sense aquesta llista, una regla és una conjectura sobre el trànsit i no l’execució d’una decisió. Una VPN pot transportar dades d’aplicacions mentre el DNS segueix un arranjament a part, i això no és cap error per si mateix. És el que passa quan ningú no ha dit al client una altra cosa.
Anomenar el camí explícitament és la diferència entre un disseny i un accident. També us dona una cosa per provar més endavant, perquè cada observació es pot comparar amb una expectativa escrita. Guardeu aquesta llista al tiquet de canvi i no al cap d’algú.
Pas 2: poseu la política on viu de debò
La tria del resolutor pertany al client: la configuració de xarxa del sistema operatiu, els paràmetres propis del client VPN o una política de navegador gestionada. Poseu-la primer allà, amb el mecanisme que admet la plataforma, perquè un tallafoc no pot obligar un client a triar un resolutor que mai no li han esmentat. En un client amb túnel dividit, digueu explícitament quins dominis van al resolutor intern. En un parc gestionat, la política del navegador sovint és l’única palanca per a DoH, perquè el navegador pot triar el seu propi resolutor xifrat amb independència del paràmetre del sistema.
Si us ho salteu i aneu directament al tallafoc, obtindreu una regla que permet el resolutor correcte i un client que no l’usa mai. La regla sembla correcta i els registres del resolutor queden buits, una parella desconcertant de depurar. Configureu primer la tria i després feu-la complir.
Pas 3: feu complir el camí de manera estreta
Ara afegiu el permís de xarxa per al camí permès: l’adreça del resolutor, el protocol i el port, i la interfície per la qual ha de sortir. Manteniu la regla limitada a aquest resolutor en lloc de permetre tot el DNS de sortida. Els tres camins de sota són els que pot prendre un client modern, i només el primer queda cobert per una regla del port 53.
| Path | Port | Who controls it |
|---|---|---|
| Classic DNS | UDP and TCP 53 | System resolver settings |
| DNS over TLS | TCP 853 | Resolver or stub configuration |
| DNS over HTTPS | TCP 443 | Browser or application policy |
Bloquejar DoH i DoT és legítim; suposar que una regla del port 53 ja els ha bloquejat no ho és. Un navegador amb DoH resol noms per un camí que la vostra regla no ha descrit mai, i una aplicació que porta el seu propi resolutor fa el mateix. Anoteu cada camí que voleu permetre i cada un que voleu refusar. Una regla que no anomena un camí no ha decidit res sobre ell.
Pas 4: seguiu els noms privats i públics
El DNS dividit envia deliberadament només espais de noms privats a un resolutor intern mentre els noms públics van a un altre lloc, així que més d’un resolutor al disseny no és cap fuita. La fuita és una consulta que havia d’anar al vostre resolutor i arriba a un altre lloc, o un camí previst inaccessible que fa que el client retrocedeixi en silenci. Aquests dos casos són el que cal buscar. Seguiu un nom intern i un nom públic sota la política prevista i anoteu quin resolutor ha respost a cada un.
Un lloc de prova que informa del vostre resolutor és un indici, no una prova, perquè només veu les consultes que li han arribat. Captureu la consulta al costat del client quan calgui saber quin camí ha pres de fet, i compareu les dues observacions. Quan no coincideixen, heu trobat un retrocés que ningú no ha documentat.
Si l’adreça del resolutor és correcta però inaccessible, el problema és d’encaminament o de filtratge i no de política. Seguiu la consulta fins a aquesta adreça i confirmeu que la resposta torna per la interfície esperada abans de canviar cap paràmetre del resolutor.
Pas 5: manteniu una via de tornada
Abans de tancar l’accés DNS a la passarel·la, confirmeu un mètode de recuperació que no depengui de la resolució de noms. Un resolutor trencat fa més difícil d’arribar a qualsevol eina de reparació, incloses les que faríeu servir per desfer el canvi. Manteniu una consola local o una via fora de banda oberta fins que la nova política estigui provada. Traieu-la només quan la política hagi sobreviscut a una reconnexió.
Després d’una reconnexió o d’una actualització de la política del navegador, torneu a inspeccionar l’estat efectiu, perquè tots dos poden canviar el resolutor sense canviar la vostra regla. El requisit és un destinatari conegut i un camí protegit per a les consultes, no una etiqueta de resolutor tranquil·litzadora en una captura de pantalla. L’especificació RFC 8484 de DNS over HTTPS és la referència per al camí xifrat que la vostra regla de port no veu.