IPTables arrrghhh

Support Debian
#1

Bien le bonjour à tous!

Bien, j’essaye de faire en sorte que mon firewall soit en mesure de faire la chose suivante:

Clients MS:
Adresses privée 192.168.0.x/24
Passerelle 192.168.0.1
DNS 89.2.0.1 ou autre public.

Maintenant, si j’essaye de faire une résolution DNS NAME–> IP ça ne fonctionne pas.
Par contre, la manip IP --> Name fonctionne.

Ce que j’essaye donc de faire, c’est que mon firewall soit en mesure de relayer les demandes de mes clients vers les DNS Internet (89.2.0.1) puis que la résolution une fois effectué soit retournée au client MS.

Le truc c’est que je n’arrive pas a me depatouiller d’IPTables, je ne vois pas quoi faire.

Voici ce que j’ai essayé (et qui ne fonctionne pas):

iptables -t nat -A PREROUTING -i eth0 -p udp --dport 53 -j DNAT --to 89.2.0.1 []--> Ne fonctionne pas.
iptables -t nat -A PREROUTING -i eth0 -p udp --dport 53 -j DNAT --to 192.168.0.1 []--> Ne fonctionne pas.

Si quelqu’un pouvait me filer un coup de main, ce ne serais pas de refus.

PS: Est ce que je doit écrire une route de retour? Ou IPTables a déjà crée une table de correspondance?

#2

Utilise SNAT :

Ainsi il changera l’adresse source de la requête DNS avant de l’envoyer. La correspondance pour le retour sera faite automatiquement.

Il faut aussi autoriser le forwarding, si ce n’est pas déjà fait :

iptables -A FORWARD -o <interface_ext> -i <interface_int> -s 192.168.0.0/24 -m state ! --state INVALID -j ACCEPT
iptables -A FORWARD -o <interface_int> -i <interface_ext> -d 192.168.0.0/24 -m state --state RELATED,ESTABLISHED -j ACCEPT
echo 1 > /proc/sys/net/ipv4/ip_forward

DNAT change la destination. Ça sert plutôt dans le sens inverse : si tu veux héberger un service sur une des machines.

#3

Le firewall, c’est celui de la passerelle ?

[quote=“Dr I”]Maintenant, si j’essaye de faire une résolution DNS NAME–> IP ça ne fonctionne pas.
Par contre, la manip IP --> Name fonctionne.[/quote]
Original. Il faudrait comprendre pourquoi. Quel sont les serveurs DNS interrogés pour ces résolutions ? Qu’est-ce qui se passe exactement, comment as-tu testé, avec nslookup ou autrement ?

On en revient à la question : quels sont les serveurs DNS interrogés originellement par les postes ? Le firewall ne peut faire quelque chose que si les requêtes lui parviennent.

#4

Bon, je vous apporte des nouvelles fraîches.

Alors, pour ce qui est des clients, après leurs avoir donnés un DNS interne fraîchement monté pour l’occasion, ils arrivent à résoudre les adresses correctement (ou plutôt, BIND le fait pour eux).

Pour ce qui est de IPTables, je vais tester ça ce week-end, je vous fait un retour dés que j’ai testé.

@Pascal:

En fait les DNS interrogés étaient les DNS INTERNET 89.2.0.1 etc.
Pour ce qui est de IP --> HOSTNAME c’est normal, en fait, le firewall (ou plutôt le SQUID) recevais les demandes IPCIBLE:80 et donc faisait la résolution lui même.

Par contre lorsque le client fait une demande à partir du HOSTNAME il interroge d’abord ses DNS pour résoudre le HOSTNAME et au final envoyer au SQUID la requête (IPCIBLE:80).

En gros, le FIREWALL (IPTables) n’était pas correctement configuré pour ce substituer aux clients et donc ne peux pas faire la résolution escompté.

#5

Donc rediriger les requêtes DNS vers 89.2.0.1 n’aurait eu aucun effet puisque c’était déjà leur destination initiale. Quant à les rediriger vers 192.168.0.1, encore faut-il que cette machine héberge un serveur DNS récursif opérationnel.

Non, il n’y a pas de résolution DNS dans ce cas, parce qu’il n’y en pas besoin puisque l’hôte de destination est déjà spécifié par son adresse IP. Et donc pas de problème de résolution DNS. D’où l’importance de ma question “comment as-tu testé”.

Non, ça ne marche pas comme ça.

Avec un proxy explicite (configuré dans le navigateur), le navigateur envoie HOSTNAME:80 au proxy, et c’est ce dernier qui fait la résolution DNS en adresse IP.

Avec un proxy transparent (non configuré dans le navigateur), le navigateur fait la résolution DNS de HOSTNAME en adresse IP, se connecte à celle-ci sur le port 80 et transmet un en-tête “Host: HOSTNAME”. Le proxy intercepte la connexion et selon les cas soit fait la résolution DNS du nom d’hôte spécifié dans l’en-tête Host, soit regarde l’adresse IP de destination originelle de la connexion interceptée pour s’y connecter à son tour.