Pourquoi la réponse DNS échoue sur un pare-feu de bordure VPN sans état

Le tunnel est établi, les clients atteignent l'hôte VPN, et l'hôte ne résout rien. Ses propres requêtes sortantes quittent proprement l'interface, donc la panne est sur le chemin du retour : au niveau d'une bordure amont qui filtre le trafic entrant sans garder la moindre mémoire de ce que l'hôte vient d'envoyer. Autoriser le port du tunnel ne décrit pas du tout cet échange. La réponse à une requête DNS est un flux distinct, et si la bordure est sans état, rien ne l'a autorisée à revenir.

Les deux échanges ne sont pas le même échange

Écrivez les tuples et l'erreur devient évidente. Le port de destination de la requête devient le port source de la réponse, soit l'inverse de ce que la plupart des gens imaginent quand ils ajoutent une règle entrante pour le port 53 :

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

Une règle entrante qui exige le port de destination 53 décrit le trafic adressé à un écouteur DNS exécuté sur l'hôte, ce qui est un service entièrement différent. Ces adresses sont des exemples de documentation, et le port source est choisi par le client pour chaque requête, ce n'est donc pas une valeur que l'on peut copier dans une règle en espérant qu'elle continue de fonctionner.

Bordure sans état contre pare-feu d'hôte avec état

Un filtre de bordure sans état évalue chaque paquet entrant par rapport à sa liste de règles, sans aucune table de connexions derrière lui. Une requête sortante partie avec succès ne crée aucune autorisation pour sa réponse entrante, car l'équipement n'a aucune trace qu'une requête ait jamais eu lieu. Un pare-feu d'hôte avec état fait l'inverse : son suivi des connexions reconnaît le trafic de retour d'un échange autorisé et le laisse passer sans règle dédiée à la réponse. Les deux frontières existent sur un chemin typique, et toutes deux doivent autoriser le paquet visé.

La comparaison compte parce que les deux équipements échouent différemment. Un pare-feu avec état qui refuse la réponse journalise un rejet ; une bordure sans état la refuse en silence, ce qui explique que l'hôte expire simplement.

Construisez l'autorisation autour du protocole, pas d'un numéro de port

Limitez la règle aux adresses réelles du résolveur, à l'hôte de destination et à la politique de port de réception prise en charge par le produit. Gardez aussi à l'esprit le chemin TCP de DNS, car une grande réponse ou un repli sur troncature déplace l'échange vers TCP et une règle limitée à UDP ne le couvrira pas. Si la bordure prend en charge l'inspection avec état pour un flux défini, préférez-la à une règle de réponse écrite à la main, car le chemin avec état suit automatiquement les ports choisis par le client.

Confirmez ensuite quel produit du chemin filtre réellement le trafic. Une portée de bordure IPv4 documentée n'établit pas de politique IPv6, et le trafic interne du fournisseur peut ne jamais traverser ce même filtre.

Pourquoi autoriser n'importe quel port source 53 n'est pas une correction

Une règle qui accepte tout ce qui prétend avoir le port source 53 est une règle qui accepte ce qu'un émetteur écrit dans un champ d'en-tête. Le numéro de port n'authentifie pas l'émetteur et ne prouve pas que la charge utile est une réponse valide, donc la règle élargit l'exposition de l'hôte sans rendre la résolution plus fiable. Conservez les restrictions de source et les contrôles de réponse du client lui-même, y compris la randomisation du port source, plutôt que de les désactiver pour simplifier une liste d'accès.

Si le résolveur est un service que vous contrôlez, le restreindre à ses adresses suffit. S'il s'agit d'un résolveur public, limitez-vous aux adresses que vous avez approuvées et notez-les dans le commentaire de la règle.

Vérifiez à la bonne frontière, dans le bon sens

Capturez sur l'hôte et à la bordure pour la même requête, et comparez les tuples plutôt que les compteurs de paquets. Une requête visible des deux côtés sans réponse visible côté hôte désigne le filtre entrant ; une requête visible uniquement côté hôte désigne le routage ou le résolveur lui-même. Répétez avec une requête TCP si vous n'avez d'autorisation que pour UDP, car c'est précisément la lacune que le premier test ne peut pas voir.

Corriger cela achève un échange DNS dont l'hôte a réellement besoin. Cela ne transforme pas l'hôte en résolveur public, n'autorise pas les flux VPN transférés et ne prouve pas que DNS était la cause d'un problème de tunnel sans rapport.