Les règles iptables par nom d'hôte sont des instantanés DNS
Comprenez pourquoi une exception iptables par nom d'hôte peut cesser de correspondre à un site après un changement DNS, et où la politique de domaine d'un proxy direct diffère.
Un nom d'hôte dans une commande iptables est résolu avant l'envoi de la règle. La règle du noyau correspond aux adresses obtenues ; elle ne répète pas DNS pour chaque paquet et n'inspecte pas les noms d'hôte HTTP.
Quand une exception cesse de fonctionner, comparez la règle numérique et les compteurs à l'adresse que le client a réellement utilisée. Les changements DNS, des réponses différentes du résolveur et des hôtes de ressources supplémentaires peuvent laisser cette adresse hors de l'ancienne règle. Le risque inverse est une adresse partagée avec des services sans rapport : une exception IP peut aussi les inclure.
Vérifiez l'ordre séparément. Un contournement placé après une action d'interception déjà correspondante peut arriver trop tard, mais le déplacer plus tôt ne maintient pas son ensemble d'adresses.
| Exception requise | Politique nécessaire |
|---|---|
| Ne pas intercepter les connexions vers ces destinations réseau | Règles de routage de paquets avec une stratégie adaptée de maintenance des adresses |
| Autoriser ce client à demander ces noms via Squid | Des ACL de domaine de destination au niveau de la requête, plus des restrictions de client et de port |
Une autorisation Squid garde la requête à l'intérieur du proxy. Un contournement du pare-feu la retire du chemin d'autorisation de Squid. Choisissez délibérément entre les deux. Avec CONNECT ordinaire, même une décision de proxy consciente du nom d'hôte n'expose pas le chemin chiffré du site : elle ne peut donc pas devenir à elle seule une exception de chemin de page.