Problème iptables pour aller sur internet seulement lan

Tags: #<Tag:0x00007f3b854aa4a8> #<Tag:0x00007f3b854aa250> #<Tag:0x00007f3b854a9f58>

Bonjour :wave:,

J’ai besoin de votre aide parce que je suis coincé avec mes règles iptables sur mon serveur debian, tout fonctionne bien, sauf pour la navigation sur Internet via n’importe quel explorateur, je ne suis pas en mesure de trouver ce qui ne va pas malgré mes nombreuses recherches sur internet . Voici un schéma de mon infrastructure: LAN DMZ WAN Infra ( voir image)wjvwz

Tous les ordinateurs de mon VLAN peuvent pinger 8.8.8.8 + google.fr, utiliser ntp, dns dhcp mais ils ne sont pas en mesure de naviguer sur une page Internet sur mozilla ou ice. Quand je mets iptables en Input, forward, et output sur ACCEPTER et vide les règles précédentes, les ordinateurs peuvent à nouveau naviguer sur Internet. Je commence à avoir les cheveux blanc à forcer d’essayer de trouver la solution j’ai besoin d’un regard extérieur, je ne sais pas ce qui ne va pas. J’ai essayé plusieurs changements sur mon iptable mais ne fonctionne pas. Une idée ? Merci infiniment

utput on ACCEPT and flush previous rules the computers can browse internet again. I’m getting with hairs withe, don’t know whats wrong. Have tried several changes on my iptable but not working. ANY idea ?

Infinite thanks in advance,

#!/bin/bash
iptables-restore < /etc/iptables.test.rules

#Add route + posterouting
sudo route add default gw 192.168.0.1
sudo iptables -t nat -A POSTROUTING -o enp0s9 -j ACCEPT

#Previous rules reset
iptables -t filter -F 
iptables -t filter -X

#Block all except OUTPUT
iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT ACCEPT

#Allow local + connection already established
iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A OUTPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -t filter -A INPUT -i lo -j ACCEPT
iptables -t filter -A OUTPUT -o lo -j ACCEPT

#Allow ping
iptables -t filter -A INPUT -p icmp -j ACCEPT
iptables -t filter -A OUTPUT -p icmp -j ACCEPT
iptables -t filter -A FORWARD -p icmp -j ACCEPT

#DNS 
iptables -t filter -A OUTPUT -p tcp --dport 53 -j ACCEPT
iptables -t filter -A OUTPUT -p udp --dport 53 -j ACCEPT
iptables -t filter -A INPUT -p tcp --dport 53 -j ACCEPT
iptables -t filter -A INPUT -p udp --dport 53 -j ACCEPT

#HTTP and HTTPS
iptables -t filter -A OUTPUT -p tcp --dport 80 -j ACCEPT
iptables -t filter -A OUTPUT -p tcp --dport 443 -j ACCEPT
iptables -t filter -A INPUT -p tcp --dport 80 -j ACCEPT
iptables -t filter -A INPUT -p tcp --dport 443 -j ACCEPT

#DHCP
iptables -A INPUT -i enp0s3 -p tcp --sport 68 --dport 67 -j ACCEPT
iptables -A INPUT -i enp0s3 -p udp --sport 68 --dport 67 -j ACCEPT

Déjà ça élimine un éventuel problème de routage. (Ceci dit, à titre personnel, je ne me serais pas embêté à subdiviser un /24 privé en 6, ce n’est pas comme si on manquait d’adresses privées même dans la plus petite des trois plages 192.168.0.0/16)

Concernant le script,

  • je suppose qu’il est exécuté sur la machine debian9.4-1 ?

  • normalement ce n’est pas là qu’on configure une route par défaut.

  • quel est l’intérêt du iptables-restore si c’est pour tout réinitialiser par derrière ?

  • j’ai extrait toutes les commandes relatives à la chaîne FORWARD qui traite les paquets traversant la machine :

    iptables -P FORWARD DROP
    iptables -A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
    iptables -t filter -A FORWARD -p icmp -j ACCEPT
    

Tu ne trouves pas qu’il manque quelque chose pour autoriser le début des connexions sortantes (NEW) autres qu’ICMP ?

Plus globalement, il est censé servir à quoi, ce jeu de règles ?

Merci d’avoir pris le temps de regarder ma problématique. Pour répondre à tes questions,

je suppose qu’il est exécuté sur la machine debian9.4-1 ?

Oui exactement

quel est l’intérêt du iptables-restore si c’est pour tout réinitialiser par derrière ?

j’ai encore un peu de mal avec iptables je débute, ce que j’avais compris c’était que si jamais quelqu’un ajoute des règles pour faire des tests, cela supprimer ces règles au démarrage et restaure celles du script.

j’ai extrait toutes les commandes relatives à la chaîne FORWARD qui traite les paquets traversant la machine :

iptables -P FORWARD DROP
iptables -A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -t filter -A FORWARD -p icmp -j ACCEPT

Tu ne trouves pas qu’il manque quelque chose pour autoriser le début des connexions sortantes (NEW) autres qu’ICMP ?

J’ai déjà autorisé le HTTP/HTTPS je ne sais pas quel autre protocole autoriser, j’avais essayé le 8080 mais sans mieux.

Ces règles vont servir à bloquer toutes les entrés non voulus mais laisser la possibilité au Lan d’aller n’importe ou sur internet sans restriction.

voici ma table de routage sur le serveur debian

image

Au démarrage les règles sont toujours vides. Il faut quelque chose pour les recréer.
La commande iptables-restore du script ne restaure pas les règles du script mais les règles enregistrées dans le fichier /etc/iptables.test.rules. Pas besoin d’utiliser à la fois iptables-restore et des commandes iptables. Il faut choisir l’un ou l’autre, sinon c’est confus. En lisant le script on ne voit pas ce que contient /etc/iptables.test.rules. Drôle de nom d’ailleurs pour un fichier censé être utilisé de façon permanente.

Le script n’autorise les paquets à destination des ports HTTP et HTTPS que dans les chaînes INPUT et OUTPUT. La chaîne INPUT ne traite que les paquets reçus à destination de la machine. La chaîne OUTPUT ne traite que les paquets émis par la machine. Ça n’a aucun effet sur les paquets reçus à destination d’une autre machine et retransmis, qui ne traversent que la chaîne FORWARD.

Dans ce cas il faut une règle pour autoriser tous les paquets dans la chaîne FORWARD qui sortent par enp0s9.

1 J'aime

Salut,

A titre personnel, je n’ai jamais (mais alors jamais) aimé toucher à iptables.
J’utilise depuis de nombreuses années une surcouche à iptables qui s’appelle shorewall.

shorewall te permet de mettre dans un fichiers policy tes règles génériques (ex: net loc REJECT )
et dans un fichiers rules tes regles plus fines (ex : DNAT net:8.8.8.8 loc:192.168.0.13:22 tcp 22)

dans un fichiers params du peu meme définir des variables (ex : MUMBLE=« 192.168.0.13 » puis GOOGLE=8.8.8.8) que tu rappellera dans ton fichier rules (ex: DNAT net:$GOOGLE loc:$MUMBLE:22 tcp 22)

ca donne un ensemble beaucoup plus lisible que des regles iptables…
il suffit de comprendre le fonctionnement de shorewall :
1 - il lit les fichiers de conf (zones, interfaces, params, shorewall.conf)
2 - il lit le fichier policy
3 - il lit le fichier rules

autres avantages :

  • la commande shorewall check vérifie l’intégrité de la conf
  • la commade shorewall safe-restart attend que tu valides la conf. si jamais tu perds la main sur ton shorewall (parce que tu t’es planté) et que tu ne peux pas valider tes modifs, il annule les modifications pour revenir sur ta conf fonctionnelle.

Bref… c’est pas vraiment une réponse à ta question… plutot un moyen pour contourné iptables qui me semble vraiment illisible :stuck_out_tongue:

1 J'aime

Autre chose, qui n’est pas explicitement lié à iptables et ton serveur debian. il n’est pas vraiment conseillé d’exposer un serveur Exchange directement sur internet.
Il serait préférable de laisser le serveur Exchange dans ton réseau et d’utiliser un relai en DMZ.
les serveur Exchange n’ont jamais été sérieusement sécurisés.

et sinon, je suis d’accord avec aerhin, utilise shorewall, c’est plus simple à configuré et plus lisible aussi.