Squid v3 transparent

Salut :smt006

Je suis en train de mettre en place un proxy que je voudrais rendre transparent, sous debian5 avec squid3. pour l’instant j’utilise qu’une seule machine avec virtualbox qui simule d’une part le serveur debian avec squid/iptable et d’autre part un client sous xp.

mon problème est le suivant: j’arrive à rendre squid3 transparent si j’ai qu’une carte réseau sous debian mais dès que je met une deuxième carte réseau, je peux utiliser squid seulement en configurant le navigateur de la machine cliente!

concrètement une fois mes expériences réussies, ça devrait donner:

  • 1 modem/routeur/serveur dhcp avec ip 192.168.1.254/24 -> le dernier point d’accès à internet
  • debian/squid/iptable avec deux cartes réseau:
    • eth0 192.168.1.2/24 avec comme passerelle 192.168.1.254 (obtenu par le dhcp pour le moment)
    • eth1 192.168.167.1/24 sans passerelle configuré manuellement
  • les machines clientes seront sur le réseau 192.168.167.0/24 avec comme passerelle 192.168.167.1.

virtuellement, si tout est ouvert dans iptable, le client ping le modem/routeur et peuvent accéder à internet en passant par le proxy (port 3128) si je configure le navigateur du client à passer par le proxy. je peux avoir la confirmation dans le fichier log du proxy qu’il y passe bien. dans ce cas, je n’ai pas configuré d’adresse dns dans les configurations réseau du client.

mais avec squid transparent non! sauf si j’enlève une carte réseau (donc squid et le client se retrouvent sur le même réseau) et si je met comme passerelle sur le client l’ip de squid et comme adresse dns l’ip du modem/routeur.

dans iptable j’ai aussi ajouté la règle suivante:
iptables -t nat -A PREROUTING -p TCP -i eth1 --dport 80 -j REDIRECT --to-port 3128

le serveur debian est en mode routeur grâce à:
echo 1 > /proc/sys/net/ipv4/ip_forward

et j’ai aussi modifié le fichier /etc/sysctl.conf pour avoir l’activation automatique du mode routeur au démarrage via cette ligne: net.ipv4.ip_forward = 1

par ailleurs, j’ai essayé de nombreuses règles iptables en nat prerouting, postrouting et output, ainsi qu’un paquet de fichier de configuration de squid où il y a par exemple (j’en ai mis qu’un à la fois):
http_port 3128 transparent ou http_port 127.0.0.1:3128 transparent ou http_port 192.168.167.1:3128 transparent ou 192.168.1.2:3128 transparent

je crois savoir que squid3 pose problème en mode transparent… à moins que ce soit le fait qu’il y ait deux cartes réseau?

pourtant dans le terminal, la commande route me donne bien:

Destination Passerelle Genmask Indic Metric Ref Use Iface
192.168.167.0 * 255.255.255.0 U 0 0 0 eth1
192.168.1.0 * 255.255.255.0 U 0 0 0 eth0
default 192.168.1.254 0.0.0.0 UG 0 0 0 eth0

svp, avez vous une solution à mon problème? merci! :smt006

Re :smt006

voici le schéma actuel de mon réseau:

j’essaie différentes possibilités comme associer Iptables et squid sur une même machine par exemple voir mettre squid sur le lan etc. mais je pense finalement adopter le schéma ci-dessus.

mon but est d’obliger les machines du lan à passer obligatoirement par le proxy (squid3 transparent) lorsqu’elles accèdent à internet, sans configurer leur navigateur. le proxy marche bien si les navigateurs sont “au courant” de son existence (le fichier log de squid m’indique la preuve). vous voyez ce qui me manque par rapport à mon premier message? comment dois-je configurer les connexions réseau des machines du lan? je dois mettre une adresse dns ou non? dans le cas d’un proxy “normal - non transparent”, je n’ai pas besoin de leur mettre une adresse dns.

svp j’ai vraiment besoin d’aide, je suis en stage et je compte bien être embauché par la boite si c’est concluant :smiley:

merci :smt006

:smt006

j’ai fait d’autres tests sans avoir configuré d’adresses dns sur une machine cliente du lan ->

  • test1 : ouverture des chaines input et output de la table filter, fermeture de la chaine forward de la même table filter, effaçage des règles de prérouting de la table nat (tout est en open dans la table nat).

=> depuis une machine cliente, je ne peux pas aller sur un site internet même en tapant l’adresse ip du site en question au lieu de son nom

  • test2: idem test1 sauf ajout d’une règle prerouting (celle indiquée dans mon premier message):
    iptables -t nat -A PREROUTING -p TCP -i eth1 --dport 80 -j REDIRECT --to-port 3128

=> depuis une machine cliente, je peux maintenant aller sur un site internet en tapant l’adresse ip du site en question; mais en tapant son nom, nada!

  • test3: idem test2 sauf que j’ai simplifié à l’extrême la règle prerouting qui est devenu:
    iptables -t nat -A PREROUTING -p TCP -j REDIRECT --to-port 3128

=> aucun changement par rapport au test2.

j’ai aussi un peu changé en faisant du dnat vers l’ip côté lan d’iptable mais rien de différent ne se passe concrètement par la suite

avec wireshark sous une machine cliente, dans le cas d’un proxy non transparent, je vois que le port 137 est souvent utilisé; alors que je m’attendais au port 53 plutôt (je ne suis pas dans un domaine). avec un proxy transparent, rien de se passe, le paquet ne va même pas à l’entrée d’iptables! alors là je ne comprend plus rien parce que mon gateway est justement l’entrée d’iptables!

et je ne sais pas comment installer wireshark sous debian ou bien existe t-il un utilitaire équivalent embarqué à débian?

merci de votre aide :smt006

:smt006

Suite ->

test4: idem test3 mais forward du port 53 sur iptables dans les deux sens

=> là tout marche bien! mais je suis obligé d’indiquer forcément une adresse dns sur les machines clientes du lan; par contre le fichier log du squid m’indique bien les sites visités donc ça confirme bien son rôle qui est en état de marche.

est-ce vraiment une bonne solution? je ne m’attendais vraiment pas à être obligé de faire ça puisque les machines clientes du lan vont bien sur internet dans le cas où il s’agit que d’un proxy non-transparent et qu’aucune adresse dns n’est indiquée dans leur configuration réseau

un avis sur mon problème? merci pour tout :smt006

Juste un mot pour que tu n’aies pas l’impression que ton sujet n’intéresse personne ici. Il m’intéresse, mais je n’aurai pas de temps à y consacrer avant demain (vendredi) soir je pense. Si d’autres peuvent répondre avant ne m’attendez surtout pas hein, il n’y a pas d’exclusivité !

:smt006

c’est gentil merci :smiley:

le schéma d’hier est un schéma simplifé, l’actuel schéma (avant mon arrivée donc) est le suivant:

ça ne concerne pas les employés de mon entreprise mais leurs clients ou visiteurs qui peuvent être répartis sur plusieurs zones. toutes les machines sont dans le même réseau 192.168.1.0/24 et les clients/visiteurs reçoivent une adresse via le dhcp du modem.

voici le même schéma mais avec iptables et squid:

est-ce que les clients/visiteurs peuvent continuer à recevoir les adresses via le dhcp du modem dans cette condition? ou bien la machine iptables devra faire aussi serveur dhcp? et aussi iptables/squid sont bien placés là?

merci pour votre aide :smt006

Non quoi ? Qu’est-ce qui se passe ?
Je n’ai pas compris comment les différentes interfaces réseau étaient interconnectées dans les cas à une et deux interfaces.

Mais d’après ton avant-dernier message, tu as trouvé la solution tout seul. En effet les postes doivent faire la résolution DNS lorsque le proxy est transparent. Avec un proxy explicite, le client se connecte au proxy (dont il connaît l’adresse IP) et lui envoie la requête HTTP contenant le nom du site, c’est donc le proxy qui fait la résolution DNS du nom du site en adresse IP et se connecte à celle-ci. Le client n’a pas besoin de connaître l’adresse IP du site. Avec un proxy transparent, le client cherche à se connecter directement au serveur web du site, il doit donc connaître son adresse IP et pour cela faire une résolution DNS avec son nom. D’où le résultat du test2.

Tu as plusieurs solutions pour les DNS interrogés par les clients : le proxy DNS du modem-routeur, ou un proxy/cache DNS sur la machine iptables (dnsmasq, bind9…). Avec la deuxième solution il n’est pas nécessaire d’accepter les paquets DNS dans la chaîne FORWARD si c’est ce qui te gêne.

[quote=“bosco”]e ne sais pas comment installer wireshark sous debian ou bien existe t-il un utilitaire équivalent embarqué à débian?
[/quote]
wireshark existe en paquet Debian. Il y a aussi une variante en mode console, tshark, ou un équivalent bien connu, tcpdump.

Nota : le port 137 est utilisé par Netbios, aucun rapport.

Non puisque le modem-routeur et les postes clients sont dans deux réseaux distincts, 192.168.1.0/24 et 192.168.167.0/24.

Oui, et il doit attribuer des adresses dans le sous-réseau 192.168.167.0/24 avec 192.168.167.1 comme passerelle et ce que tu auras décidé comme DNS.

En fait je ne vois pas bien l’intérêt de déporter squid sur une machine séparée. En plus cette solution ne fonctionne pas en mode transparent avec un client qui envoie des requêtes HTTP/1.0 (d’accord ça doit commencer à être rare) ne contenant pas le nom d’hôte du site. Dans ce cas squid ne peut retrouver l’adresse IP du site que lorsqu’il est sur la machine qui intercepte le trafic HTTP.

Note : on ne peut pas faire de proxy transparent en HTTPS.

:smt006

[quote=“PascalHambourg”]
Non quoi ? Qu’est-ce qui se passe ?
Je n’ai pas compris comment les différentes interfaces réseau étaient interconnectées dans les cas à une et deux interfaces.[/quote]
non les clients ne se connectaient pas à internet. mais depuis j’ai résolu le problème, que squid soit sur la même machine qu’iptables ou non.

[quote=“PascalHambourg”]
Mais d’après ton avant-dernier message, tu as trouvé la solution tout seul. En effet les postes doivent faire la résolution DNS lorsque le proxy est transparent. Avec un proxy explicite, le client se connecte au proxy (dont il connaît l’adresse IP) et lui envoie la requête HTTP contenant le nom du site, c’est donc le proxy qui fait la résolution DNS du nom du site en adresse IP et se connecte à celle-ci. Le client n’a pas besoin de connaître l’adresse IP du site. Avec un proxy transparent, le client cherche à se connecter directement au serveur web du site, il doit donc connaître son adresse IP et pour cela faire une résolution DNS avec son nom. D’où le résultat du test2.[/quote]

pourtant, j’ai connu un cas où des machines clientes (d’une autre boite) pouvaient se balader sur internet alors qu’aucune adresse dns n’était indiquée dans les configurations réseaux, je me suis toujours demandé comment est-ce possible? le proxy n’était sans doute pas transparent j’imagine, je ne m’en rappelle plus.

l’inconvénient c’est que le responsable informatique souhaite garder le “open dns” qui gère apparemment une black-liste. les adresses dns que je configure dans les connexions réseau proviennent de ce “open dns”, des adresses extérieures au réseau, provenant d’internet donc.

[quote=“PascalHambourg”]
Non puisque le modem-routeur et les postes clients sont dans deux réseaux distincts, 192.168.1.0/24 et 192.168.167.0/24.[/quote]

idem que ci-dessus, l’informaticien ne souhaite pas trop changer ça, déjà qu’il voulait que je lui trouve une solution proxy sous windows… bref n’y a t-il pas une fonction de relay dhcp permettant aux routeurs de “forwarder” en quelque sorte les requêtes dhcp?

EDIT: bon j’ai correctement installé et configuré un serveur dhcp sur la machine iptables mais avec toutes les tables ouvertes pour l’instant.

[quote=“PascalHambourg”]
Oui, et il doit attribuer des adresses dans le sous-réseau 192.168.167.0/24 avec 192.168.167.1 comme passerelle et ce que tu auras décidé comme DNS.[/quote]

c’est bien ce que je pensais et que j’ai même suggéré au responsable informatique.

[quote=“PascalHambourg”]
En fait je ne vois pas bien l’intérêt de déporter squid sur une machine séparée. En plus cette solution ne fonctionne pas en mode transparent avec un client qui envoie des requêtes HTTP/1.0 (d’accord ça doit commencer à être rare) ne contenant pas le nom d’hôte du site. Dans ce cas squid ne peut retrouver l’adresse IP du site que lorsqu’il est sur la machine qui intercepte le trafic HTTP.[/quote]

je ne connais pas trop les requêtes HTTP/1.0, mais je vais me documenter à ce sujet merci.

plus tard, pourrais-je poster mes scrips iptables pour avoir vos avis dessus?

je te remercie pour ton aide :smiley:

:smt006

Ce n’est pas un problème. Tu peux monter un proxy/cache DNS qui interroge les DNS d’OpenDNS. C’est faisable facilement autant avec BIND qu’avec dnsmasq par exemple.

Oui, cf. les paquets dhcp3-relay ou dhcp-helper. Mais le problème n’est pas DHCP mais le fait qu’il y a deux réseaux physiquement séparés de part et d’autre de la machine iptables, donc deux sous-réseaux IP distincts. Si tu veux que les postes clients soient dans le même sous-réseau IP que le modem-routeur, cela n’est possible que si cette machine fonctionne en pont ethernet (comme un switch) et non plus en routeur IP.

Un apport de HTTP/1.1 par rapport à HTTP/1.0 est l’en-tête “Host” qui permet de spécifier le nom d’hôte du site objet de la requête. En effet dans une requête directe la “méthode” (GET, POST…) ne contient que le chemin de la ressource par rapport à la racine du site et non l’URL complet (contrairement à une requête à un proxy explicite). Par exemple, pour l’URL http://example.com/chemin/page.html, le début de la requête HTTP est :

GET /chemin/page.html HTTP/1.1
Host: example.com

L’en-tête “Host” a été créé pour permettre d’héberger et différencier plusieurs sites sur le même serveur à la même adresse IP. Mais il peut aussi être exploité par un proxy transparent pour retrouver le nom du site web et par là son adresse IP si la connexion a été redirigée vers le proxy en modifiant l’adresse IP destination avec REDIRECT ou DNAT.

On comprend qu’un navigateur HTTP/1.0 pur qui n’envoie pas l’en-tête “Host” ne peut pas accéder aux sites multiples d’un même serveur, il ne peut accéder qu’au site “par défaut”. Avec la généralisation des hébergements mutualisés, c’est devenu très rare. D’ailleurs certains navigateurs HTTP/1.0 utilisent quand même l’en-tête “Host”.

Tu peux publier ton script iptables ici s’il n’est pas trop long. Sinon, le mettre en lien.

:smt006

merci pour tes précisions :smiley: mon projet avance plutôt bien mais il me reste quelques interrogations:

  1. pourquoi les machines clientes arrivent à récupérer une adresse ip du serveur dhcp (qui est sur la même machine qui gère le proxy et iptables) même lorsque toutes les chaines de la table filter d’iptables sont sur drop? pourtant les ports 67 et 68 sont bien bloqués!

EDIT: Apparemment c’est normal, je trouvais ça étrange sur le coup mais bon, je ne cherche pas à le bloquer (à quoi bon de le mettre sinon)!

  1. à l’arrêt ou au redémarrage de la machine linux qui gère finalement iptables/squid/dhcp/samba, elle bloque pendant quelques minutes sur “debian login: acpid: exiting”? est-ce lié aux différents services lancés? mes services supplémentaires lancés automatiquement au démarrage sont les règles d’iptables, le proxy squid, le serveur dhcp ainsi que samba (qui ne concernera que la sauvegarde automatique de fichiers log de squid accessible uniquement par l’administrateur).

  2. est-il possible que squid utilise un nouveau fichier log chaque jour à la même heure, disons vers minuit? sinon je pense faire un script qui permet d’effacer le fichier log pour en créer un nouveau qui sera vierge.

EDIT: Question 3 résolue

  1. j’ai pu créer un script qui permet de copier le fichier “/var/log/squid/access.log” vers un autre fichier “/sauvegarde/log/log_date_du jour” créé automatiquement. mais comment faire lancer ce script automatiquement et quotidiennement disons vers minuit?

EDIT: Question 4 résolue

  1. quel(s) port(s) utilise le gestionnaire des mises à jour? car j’ai pu mettre debian à jour alors que seuls les ports 80/443/53 et icmp de la table filter ainsi que le prerouting 80 vers 3128 étaient autorisés.

EDIT: Question 5 résolue. je n’avais pas pensé au fichier /etc/apt/sources.list :unamused:

je vais continuer à chercher en attendant vos réponses, merci :smiley:

allez :smt006

Si tu souhaites que tes postes clients puissent faire une resolution de nom simplement, tu peux également mettre en place une passerelle simple, dans ton cas : iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE (à ta charge de sécuriser et filtrer cela).
coté client dhcp Il te suffit dans les options DHCP de ton serveur d’attribuer une “gateway” pointant sur ton serveur en l’occurence 192.168.167.1/24, avec la redirection que tu as mis en place tes clients passerons par le proxy de manière transparente (sauf pour https bien sur)et effectuerons la resolution de nom au travers de la passerelle.
Pour ma part cette solution fonctionne parfaitement sur une configuration similaire à la tienne.
La solution du cache dns (évoqué plus haut) est plus élégante et c’est celle que j’emploie le plus souvent (meilleurs perf).

:smt006

Le schéma final adopté est le suivant:

La machine Debian est donc le proxy transparent, elle gère aussi la partie sécurité avec iptables et c’est elle qui fournit les adresses ip via le serveur dhcp que j’ai installé dessus. Concernant la partie dns, j’ai conservé l’idée de départ, à savoir un forward du port 53.

Bilan: même après un redémarrage du serveur Debian, tout fonctionne comme sur des roulettes! du moins la partie surf sur internet. car on en ce moment nous n’avons pas de visiteurs et j’ai prévu d’autres règles iptables que je n’ai pas pu tester pour l’instant.

mon post concerne donc iptables, j’aimerais vous poster mes règles. j’ai procédé de la sorte: des scripts par port quasiment sauf pour internet et d’autres scripts généraux qui appellent les premiers, ça permet de modifier les scripts par port et le tout sera pris en compte.

SCRIPT INTERNET:

#!/bin/bash

Déclarations

lan=192.168.2.0/24
ip_local_modem=192.168.1.150
ip_local_lan=192.168.2.1
point_acces_wifi=192.168.2.11

affiche les commandes exécutées dans le script

set -x

être capable de paramétrer le point d’accès wifi 192.168.2.11 seulement depuis la machine locale (192.168.2.1) via http

iptables -A INPUT -s $point_acces_wifi -d $ip_local_lan -p tcp --sport 80 -j ACCEPT
iptables -A OUTPUT -s $ip_local_lan -d $point_acces_wifi -p tcp --dport 80 -j ACCEPT

accepter en entrée et en sortie le port 80 (www) sauf ce qui vient du lan

iptables -A INPUT -s ! $lan -d $ip_local_modem -p tcp --sport 80 -j ACCEPT
iptables -A OUTPUT -s $ip_local_modem -p tcp --dport 80 -j ACCEPT

accepter en entrée et en sortie le port 443 (https) sauf ce qui vient du lan

iptables -A INPUT -s ! $lan -d $ip_local_modem -p tcp --sport 443 -j ACCEPT
iptables -A OUTPUT -s $ip_local_modem -p tcp --dport 443 -j ACCEPT

accepter en entrée et en sortie le port 53 (dns) sauf ce qui vient du lan

iptables -A INPUT -s ! $lan -d $ip_local_modem -p udp --sport 53 -j ACCEPT
iptables -A OUTPUT -s $ip_local_modem -p udp --dport 53 -j ACCEPT

SCRIPT PROXY:

#!/bin/bash

lan=192.168.2.0/24
ip_local_modem=192.168.1.150
ip_local_lan=192.168.2.1

affiche les commandes exécutées dans le script

set -x

accepter en entrée et en sortie le port 3128 (proxy) que en provenance du lan

iptables -A INPUT -i eth1 -s $lan -d $ip_local_lan -p tcp --dport 3128 -j ACCEPT
iptables -A OUTPUT -s $ip_local_lan -p tcp --sport 3128 -j ACCEPT

forwarder le port 53 (dns)

iptables -A FORWARD -i eth1 -o eth0 -s $lan -p udp --sport 53 -j ACCEPT
iptables -A FORWARD -i eth0 -o eth1 -d $lan -p udp --sport 53 -j ACCEPT
iptables -A FORWARD -i eth1 -o eth0 -s $lan -p udp --dport 53 -j ACCEPT
iptables -A FORWARD -i eth0 -o eth1 -d $lan -p udp --dport 53 -j ACCEPT

forwarder le port 443 (https)

iptables -A FORWARD -i eth1 -o eth0 -s $lan -p tcp --sport 443 -j ACCEPT
iptables -A FORWARD -i eth0 -o eth1 -d $lan -p tcp --sport 443 -j ACCEPT
iptables -A FORWARD -i eth1 -o eth0 -s $lan -p tcp --dport 443 -j ACCEPT
iptables -A FORWARD -i eth0 -o eth1 -d $lan -p tcp --dport 443 -j ACCEPT

rediriger tout ce qui vient du lan à destination du port 80 vers le port 3128

iptables -t nat -A PREROUTING -i eth1 -s $lan -p tcp --dport 80 -j REDIRECT --to-port 3128

cacher les adresses ip du lan, faire croire que c’est l’adresse 192.168.1.150 du routeur

iptables -t nat -A POSTROUTING -s $lan -o eth0 -j MASQUERADE

SCRIPT LO:

#!/bin/bash

affiche les commandes exécutées dans le script

set -x

Autoriser les paquets pour lo

iptables -A INPUT -i lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT

SCRIPT PING:

#!/bin/bash

boucle_locale=127.0.0.1
ip_local_modem=192.168.1.150
ip_local_lan=192.168.2.1
exterieur=192.168.1.0/24
lan=192.168.2.0/24

NOTE: si on veut juste pouvoir pinger la machine locale, la règle suivante suffit.

iptables -A INPUT -i lo -j ACCEPT

iptables -A OUTPUT -o lo -j ACCEPT

Cette règle permet d’accepter tous les paquets sur l’interface lo.

affiche les commandes exécutées dans le script

set -x

pouvoir envoyer un echo-request et un echo-reply

iptables -A OUTPUT -p ICMP --icmp-type echo-request -j ACCEPT
iptables -A OUTPUT -p ICMP --icmp-type echo-reply -j ACCEPT

accepter les echo-request provenant uniquement du réseau 192.168.1.0/24 (y compris de soi-même)

iptables -A INPUT -s $exterieur -p ICMP --icmp-type echo-request -j ACCEPT

accepter les echo-reply provenant uniquement du réseau 192.168.1.0/24 (y compris de soi-même)

iptables -A INPUT -s $exterieur -p ICMP --icmp-type echo-reply -j ACCEPT

accepter les echo-request provenant uniquement du lan (y compris de soi-même)

iptables -A INPUT -s $lan -p ICMP --icmp-type echo-request -j ACCEPT

accepter les echo-reply provenant uniquement du lan (y compris de soi-même)

iptables -A INPUT -s $lan -p ICMP --icmp-type echo-reply -j ACCEPT

pouvoir se pinger sur la boucle locale

iptables -A INPUT -s $boucle_locale -p ICMP --icmp-type echo-request -j ACCEPT
iptables -A INPUT -s $boucle_locale -p ICMP --icmp-type echo-reply -j ACCEPT

que le lan puisse puisse envoyer un echo-request vers le reseau 192.168.1.0/24

iptables -A FORWARD -i eth1 -o eth0 -s $lan -d $exterieur -p ICMP --icmp-type echo-request -j ACCEPT

que le lan puisse puisse recevoir un echo-reply depuis le reseau 192.168.1.0/24

iptables -A FORWARD -i eth0 -o eth1 -s $exterieur -d $lan -p ICMP --icmp-type echo-reply -j ACCEPT

que le reseau 192.168.1.0/24 puisse puisse envoyer un echo-request vers le lan

iptables -A FORWARD -i eth0 -o eth1 -s $exterieur -d $lan -p ICMP --icmp-type echo-request -j ACCEPT

que le reseau 192.168.1.0/24 puisse recevoir un echo-reply depuis le lan

iptables -A FORWARD -i eth0 -o eth1 -s $exterieur -d $lan -p ICMP --icmp-type echo-reply -j ACCEPT

SCRIPT SAMBA:

#!/bin/bash

exterieur=192.168.1.0/24

affiche les commandes exécutées dans le script

set -x

accepter en entrée et en sortie le port 445 (samba pour W2K/XP/2003) que pour le réseau 192.168.1.0/24

iptables -A INPUT -s $exterieur -p tcp --dport 445 -j ACCEPT
iptables -A OUTPUT -d $exterieur -p tcp --sport 445 -j ACCEPT

Et j’ai donc prévu des scripts pour les visiteurs, les voici:

SCRIPT FTP:

#!/bin/bash

lan=192.168.2.0/24
ip_local_modem=192.168.1.150
ip_local_lan=192.168.2.1

affiche les commandes exécutées dans le script

set -x

forwarder le port 21 (ftp)

iptables -A FORWARD -i eth1 -o eth0 -s $lan -p tcp --sport 21 -j ACCEPT
iptables -A FORWARD -i eth0 -o eth1 -d $lan -p tcp --sport 21 -j ACCEPT
iptables -A FORWARD -i eth1 -o eth0 -s $lan -p tcp --dport 21 -j ACCEPT
iptables -A FORWARD -i eth0 -o eth1 -d $lan -p tcp --dport 21 -j ACCEPT

SCRIPT POP3:

#!/bin/bash

lan=192.168.2.0/24
ip_local_modem=192.168.1.150
ip_local_lan=192.168.2.1

affiche les commandes exécutées dans le script

set -x

forwarder le port 110 (pop3) en tcp

iptables -A FORWARD -i eth1 -o eth0 -s $lan -p tcp --sport 110 -j ACCEPT
iptables -A FORWARD -i eth0 -o eth1 -d $lan -p tcp --sport 110 -j ACCEPT
iptables -A FORWARD -i eth1 -o eth0 -s $lan -p tcp --dport 110 -j ACCEPT
iptables -A FORWARD -i eth0 -o eth1 -d $lan -p tcp --dport 110 -j ACCEPT

forwarder le port 110 (pop3) en udp

iptables -A FORWARD -i eth1 -o eth0 -s $lan -p udp --sport 110 -j ACCEPT
iptables -A FORWARD -i eth0 -o eth1 -d $lan -p udp --sport 110 -j ACCEPT
iptables -A FORWARD -i eth1 -o eth0 -s $lan -p udp --dport 110 -j ACCEPT
iptables -A FORWARD -i eth0 -o eth1 -d $lan -p udp --dport 110 -j ACCEPT

SCRIPT POP3s:

#!/bin/bash

lan=192.168.2.0/24
ip_local_modem=192.168.1.150
ip_local_lan=192.168.2.1

affiche les commandes exécutées dans le script

set -x

forwarder le port 995 (pop3s) en tcp

iptables -A FORWARD -i eth1 -o eth0 -s $lan -p tcp --sport 995 -j ACCEPT
iptables -A FORWARD -i eth0 -o eth1 -d $lan -p tcp --sport 995 -j ACCEPT
iptables -A FORWARD -i eth1 -o eth0 -s $lan -p tcp --dport 995 -j ACCEPT
iptables -A FORWARD -i eth0 -o eth1 -d $lan -p tcp --dport 995 -j ACCEPT

forwarder le port 995 (pop3s) en udp

iptables -A FORWARD -i eth1 -o eth0 -s $lan -p udp --sport 995 -j ACCEPT
iptables -A FORWARD -i eth0 -o eth1 -d $lan -p udp --sport 995 -j ACCEPT
iptables -A FORWARD -i eth1 -o eth0 -s $lan -p udp --dport 995 -j ACCEPT
iptables -A FORWARD -i eth0 -o eth1 -d $lan -p udp --dport 995 -j ACCEPT

SCRIPT SMTP:

#!/bin/bash

lan=192.168.2.0/24
ip_local_modem=192.168.1.150
ip_local_lan=192.168.2.1

affiche les commandes exécutées dans le script

set -x

forwarder le port 25 (smtp) en tcp

iptables -A FORWARD -i eth1 -o eth0 -s $lan -p tcp --sport 25 -j ACCEPT
iptables -A FORWARD -i eth0 -o eth1 -d $lan -p tcp --sport 25 -j ACCEPT
iptables -A FORWARD -i eth1 -o eth0 -s $lan -p tcp --dport 25 -j ACCEPT
iptables -A FORWARD -i eth0 -o eth1 -d $lan -p tcp --dport 25 -j ACCEPT

SCRIPT VPN:

#!/bin/bash

lan=192.168.2.0/24
ip_local_modem=192.168.1.150
ip_local_lan=192.168.2.1

affiche les commandes exécutées dans le script

set -x

forwarder le port 1701 (l2tp) en tcp

iptables -A FORWARD -i eth1 -o eth0 -s $lan -p tcp --sport 1701 -j ACCEPT
iptables -A FORWARD -i eth0 -o eth1 -d $lan -p tcp --sport 1701 -j ACCEPT
iptables -A FORWARD -i eth1 -o eth0 -s $lan -p tcp --dport 1701 -j ACCEPT
iptables -A FORWARD -i eth0 -o eth1 -d $lan -p tcp --dport 1701 -j ACCEPT

forwarder le port 1701 (l2tp) en udp

iptables -A FORWARD -i eth1 -o eth0 -s $lan -p udp --sport 1701 -j ACCEPT
iptables -A FORWARD -i eth0 -o eth1 -d $lan -p udp --sport 1701 -j ACCEPT
iptables -A FORWARD -i eth1 -o eth0 -s $lan -p udp --dport 1701 -j ACCEPT
iptables -A FORWARD -i eth0 -o eth1 -d $lan -p udp --dport 1701 -j ACCEPT

forwarder le port 1723 (pptp) en tcp

iptables -A FORWARD -i eth1 -o eth0 -s $lan -p tcp --sport 1723 -j ACCEPT
iptables -A FORWARD -i eth0 -o eth1 -d $lan -p tcp --sport 1723 -j ACCEPT
iptables -A FORWARD -i eth1 -o eth0 -s $lan -p tcp --dport 1723 -j ACCEPT
iptables -A FORWARD -i eth0 -o eth1 -d $lan -p tcp --dport 1723 -j ACCEPT

forwarder le port 1723 (pptp) en udp

iptables -A FORWARD -i eth1 -o eth0 -s $lan -p udp --sport 1723 -j ACCEPT
iptables -A FORWARD -i eth0 -o eth1 -d $lan -p udp --sport 1723 -j ACCEPT
iptables -A FORWARD -i eth1 -o eth0 -s $lan -p udp --dport 1723 -j ACCEPT
iptables -A FORWARD -i eth0 -o eth1 -d $lan -p udp --dport 1723 -j ACCEPT

j’ai aussi d’autres scripts que je ne juge pas utile de poster, ces derniers permettant de regrouper des scripts pour les employés ou pour les visiteurs, de tout fermer ou de tout ouvrir, ou bien encore d’enlever une règle précise par numéro de ligne.

J’espère que j’ai bien fait d’avoir posté mes scripts sur le post initialement prévu pour le squid transparent, sinon je réédite tout ça et je crée un nouveau sujet.

Merci de me laisser vos critiques sur mes scripts iptables :smiley:

:smt006