De ce eșuează răspunsul DNS pe un firewall de margine VPN fără stare

Tunelul este activ, clienții ajung la hostul VPN, iar hostul nu poate rezolva nimic. Propriile interogări de ieșire părăsesc interfața curat, așadar defecțiunea este pe drumul de întoarcere: la o margine superioară care filtrează traficul de intrare fără să rețină ce a trimis hostul acum. Permiterea portului tunelului nu descrie deloc acel schimb. Răspunsul la o interogare DNS este un flux separat, iar dacă marginea este fără stare, nimic nu i-a dat permisiunea să revină.

Cele două schimburi nu sunt același schimb

Notați tuplurile și eroarea devine evidentă. Portul destinație al cererii devine portul sursă al răspunsului, ceea ce este opusul a ceea ce își imaginează majoritatea când adaugă o regulă de intrare pentru portul 53:

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

O regulă de intrare care cere portul destinație 53 descrie trafic adresat unui ascultător DNS care rulează pe host, iar acesta este un serviciu complet diferit. Acele adrese sunt exemple de documentație, iar portul sursă este ales de client pentru fiecare interogare, deci nu este o valoare pe care să o copiați într-o regulă și să vă așteptați să continue să funcționeze.

Margine fără stare versus firewall de host cu stare

Un filtru de margine fără stare evaluează fiecare pachet de intrare față de lista sa de reguli fără niciun tabel de conexiuni în spate. O interogare de ieșire care a plecat cu succes nu creează nicio permisiune pentru răspunsul ei de intrare, pentru că echipamentul nu are nicio evidență că vreo interogare a avut loc vreodată. Un firewall de host cu stare este opusul: urmărirea conexiunilor recunoaște traficul de retur al unui schimb permis și îl lasă să treacă fără o regulă pentru răspuns. Ambele limite există pe o cale tipică, și ambele trebuie să permită pachetul dorit.

Comparația contează pentru că cele două echipamente eșuează diferit. Un firewall cu stare care refuză răspunsul înregistrează o aruncare; o margine fără stare îl refuză în tăcere, motiv pentru care hostul pur și simplu ajunge la expirarea timpului.

Construiți permisiunea în jurul protocolului, nu al unui număr de port

Limitați regula la adresele reale ale resolverului, la hostul de destinație și la politica de port de recepție pe care o acceptă produsul. Aveți în vedere și calea TCP a DNS, pentru că un răspuns mare sau o retragere din cauza trunchierii mută schimbul pe TCP, iar o regulă doar pentru UDP nu îl va acoperi. Dacă marginea acceptă inspecție cu stare pentru un flux definit, preferați-o unei reguli de răspuns scrisă de mână, pentru că calea cu stare urmărește automat porturile alese de client.

Apoi confirmați care produs din cale filtrează efectiv traficul. Un domeniu de margine IPv4 documentat nu stabilește o politică IPv6, iar traficul intern al furnizorului poate să nu treacă niciodată prin același filtru.

De ce permiterea oricărui port sursă 53 nu este o soluție

O regulă care acceptă tot ce pretinde că are portul sursă 53 este o regulă care acceptă ce scrie un expeditor într-un câmp de antet. Numărul portului nu autentifică expeditorul și nu dovedește că încărcătura este un răspuns valid, așa că regula lărgește expunerea hostului fără a face rezolvarea mai fiabilă. Păstrați restricțiile de sursă și verificările de răspuns ale clientului însuși, inclusiv randomizarea portului sursă, în loc să le dezactivați pentru a simplifica o listă de acces.

Dacă resolverul este un serviciu pe care îl controlați, restricționarea la adresele lui este suficientă. Dacă este un resolver public, limitați la adresele pe care le-ați aprobat și notați-le în comentariul regulii.

Verificați la limita corectă, în direcția corectă

Capturați pe host și la margine aceeași interogare și comparați tuplurile, nu numărul de pachete. O interogare vizibilă pe ambele părți fără răspuns vizibil pe partea hostului indică filtrul de intrare; o interogare vizibilă doar pe partea hostului indică rutarea sau resolverul însuși. Repetați cu o interogare TCP dacă aveți permisiune doar pentru UDP, pentru că aceasta este lacuna pe care primul test nu o poate vedea.

Remedierea acestei situații finalizează un schimb DNS de care hostul are cu adevărat nevoie. Nu transformă hostul într-un resolver public, nu autorizează fluxuri VPN redirecționate și nu dovedește că DNS a fost cauza vreunei probleme de tunel fără legătură.