Per què falla la resposta DNS en un tallafocs perifèric de VPN sense estat

El túnel està actiu, els clients arriben a l'amfitrió VPN i l'amfitrió no pot resoldre res. Les seves pròpies consultes sortints surten netes per la interfície, així que la fallada és en el camí de tornada: en una perifèria superior que filtra el trànsit entrant sense cap memòria del que l'amfitrió acaba d'enviar. Permetre el port del túnel no descriu gens aquest intercanvi. La resposta a una consulta DNS és un flux separat, i si la perifèria no té estat, res no l'ha autoritzada a tornar.

Els dos intercanvis no són el mateix intercanvi

Escriviu les tuples i l'error es fa evident. El port de destinació de la petició es converteix en el port d'origen de la resposta, que és el contrari del que la majoria imagina quan afegeix una regla entrant per al port 53:

query:  203.0.113.10:53018 -> 198.51.100.53:53
reply:  198.51.100.53:53 -> 203.0.113.10:53018

Una regla entrant que exigeix el port de destinació 53 descriu trànsit adreçat a un oient DNS que s'executa a l'amfitrió, que és un servei completament diferent. Aquestes adreces són exemples de documentació, i el port d'origen el tria el client per a cada consulta, així que no és un valor que pugueu copiar en una regla i esperar que continuï funcionant.

Perifèria sense estat versus tallafocs d'amfitrió amb estat

Un filtre perifèric sense estat avalua cada paquet entrant contra la seva llista de regles sense cap taula de connexions al darrere. Una consulta sortint que ha marxat correctament no crea cap permís per a la seva resposta entrant, perquè el dispositiu no té cap registre que una consulta hagi existit mai. Un tallafocs d'amfitrió amb estat és el contrari: el seu seguiment de connexions reconeix el trànsit de retorn d'un intercanvi permès i el deixa passar sense una regla per a la resposta. Totes dues fronteres existeixen en un camí típic, i totes dues han de permetre el paquet previst.

La comparació importa perquè els dos dispositius fallen de manera diferent. Un tallafocs amb estat que denega la resposta registra una descàrrega; una perifèria sense estat la denega en silenci, i per això l'amfitrió simplement es queda sense temps.

Construïu el permís al voltant del protocol, no d'un número de port

Limiteu la regla a les adreces reals del resolutor, a l'amfitrió de destinació i a la política de port de recepció que admet el producte. Tingueu també present el camí TCP del DNS, perquè una resposta gran o un retrocés per truncament trasllada l'intercanvi a TCP i una regla només per a UDP no el cobrirà. Si la perifèria admet inspecció amb estat per a un flux definit, preferiu-la a una regla de resposta escrita a mà, perquè el camí amb estat segueix automàticament els ports que tria el client.

Després confirmeu quin producte del camí filtra realment el trànsit. Un abast perifèric IPv4 documentat no estableix una política IPv6, i el trànsit intern del proveïdor pot no travessar mai el mateix filtre.

Per què permetre qualsevol port d'origen 53 no és cap solució

Una regla que accepta qualsevol cosa que afirmi tenir el port d'origen 53 és una regla que accepta el que un emissor escrigui en un camp de capçalera. El número de port no autentica l'emissor ni demostra que la càrrega sigui una resposta vàlida, així que la regla amplia l'exposició de l'amfitrió sense fer la resolució més fiable. Manteniu les restriccions d'origen i les comprovacions de resposta del propi client, inclosa l'aleatorització del port d'origen, en lloc de desactivar-les per simplificar una llista d'accés.

Si el resolutor és un servei que controleu, restringir-lo a les seves adreces és suficient. Si és un resolutor públic, limiteu-vos a les adreces que hàgiu aprovat i anoteu-les al comentari de la regla.

Verifiqueu a la frontera correcta, en la direcció correcta

Captureu a l'amfitrió i a la perifèria la mateixa consulta, i compareu les tuples en lloc dels comptes de paquets. Una consulta visible als dos costats sense cap resposta visible al costat de l'amfitrió assenyala el filtre entrant; una consulta visible només al costat de l'amfitrió assenyala l'encaminament o el mateix resolutor. Repetiu-ho amb una consulta TCP si només teniu permís per a UDP, perquè aquesta és la llacuna que la primera prova no pot veure.

Corregir això completa un intercanvi DNS que l'amfitrió necessita de debò. No converteix l'amfitrió en un resolutor públic, no autoritza fluxos VPN reenviats ni demostra que el DNS fos la causa d'algun problema de túnel no relacionat.