# Audit iptables **URL:** \ **Category:** Support Debian\ **Tags:** iptables\ **Created:** [Avril 25, 2020, 10:40 UTC](https://www.debian-fr.org/t/audit-iptables/81915 "2020-04-25T22:40:04Z")\ **Posts on this page:** 20\ **Page:** 2
**Author:** ![pyridoxine](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/p/e79b87/32.png) [@pyridoxine](https://www.debian-fr.org/u/pyridoxine)\ **Post date:** [Avril 27, 2020, 1:14 UTC](https://www.debian-fr.org/t/audit-iptables/81915/21 "2020-04-27T13:14:05Z")
> [@PascalHambourg](#): > > Non, -F ne modifie pas la politique par défaut. Mea coulpa, je raconte n’importe quoi 😂 Effectivement ! Dans un troisième cas alors : ```plaintext #!/bin/sh echo "Flushing iptables rules..." sleep 1 iptables -F iptables -X iptables -t nat -F iptables -t nat -X iptables -t mangle -F iptables -t mangle -X iptables -P INPUT DROP iptables -P FORWARD DROP iptables -P OUTPUT ACCEPT #Laisser les connexions établies ouvertes. iptables -A INPUT -m state --state ESTABLISHED -j ACCEPT #Autoriser le loopback iptables -A INPUT -i lo -j ACCEPT #Port SSH iptables -A INPUT -p tcp --destination-port 32 -j ACCEPT iptables -t nat -A PREROUTING -d ipfailover1 -j DNAT --to-destination 10.8.0.3 iptables -t nat -A POSTROUTING -s 10.8.0.3 ! -o tun0 -j SNAT --to-source ipfailover1 iptables -t nat -A PREROUTING -d ipfailover2 -j DNAT --to-destination 10.8.0.5 iptables -t nat -A POSTROUTING -s 10.8.0.5 ! -o tun0 -j SNAT --to-source ipfailover2 iptables -t nat -A POSTROUTING -s 10.8.0.0/24 ! -o tun0 -j SNAT --to-source ipvps #Permettre de laisser passer le traffic de ens3 vers tun0 iptables -A FORWARD -i ens3 -o tun0 -j ACCEPT #Permettre de laisser passer le traffic de tun0 vers ens3 iptables -A FORWARD -i tun0 -o ens3 -j ACCEPT #Pour permettre aux clients du vpn d'établir une connexion au serveur. iptables -A INPUT -i ens3 -p udp --dport 1194 -j ACCEPT #laisser le traffic entrer sur l'interface tun0 sans restriction. iptables -A INPUT -i tun0 -j ACCEPT #serveur web publique iptables -A INPUT -p tcp --destination-port 81 -j ACCEPT #Transmission-daemon iptables -A INPUT -p tcp --dport 51413 -j ACCEPT iptables -A INPUT -p udp --dport 51413 -j ACCEPT ``` ou : ```plaintext #!/bin/sh echo "Flushing iptables rules..." sleep 1 iptables -F iptables -X iptables -t nat -F iptables -t nat -X iptables -t mangle -F iptables -t mangle -X iptables -P INPUT DROP iptables -P FORWARD DROP iptables -P OUTPUT ACCEPT #Laisser les connexions établies ouvertes. iptables -A INPUT -m state --state ESTABLISHED -j ACCEPT #Autoriser le loopback iptables -A INPUT -i lo -j ACCEPT #Port SSH iptables -A INPUT -p tcp --destination-port 32 -j ACCEPT iptables -t nat -A PREROUTING -d ipfailover1 -j DNAT --to-destination 10.8.0.3 iptables -t nat -A POSTROUTING -s 10.8.0.3 ! -o tun0 -j SNAT --to-source ipfailover1 iptables -t nat -A PREROUTING -d ipfailover2 -j DNAT --to-destination 10.8.0.5 iptables -t nat -A POSTROUTING -s 10.8.0.5 ! -o tun0 -j SNAT --to-source ipfailover2 iptables -t nat -A POSTROUTING -s 10.8.0.0/24 ! -o tun0 -j SNAT --to-source ipvps #Permettre de laisser passer le traffic de ens3 vers tun0 iptables -A FORWARD -i ens3 -o tun0 -j ACCEPT #Permettre de laisser passer le traffic de tun0 vers ens3 iptables -A FORWARD -i tun0 -o ens3 -j ACCEPT #Pour permettre aux clients du vpn d'établir une connexion au serveur. iptables -A INPUT -i ens3 -p udp --dport 1194 -j ACCEPT #Permettre la résolution de noms de domaines pour pihole iptables -A INPUT -i tun0 -p tcp --destination-port 53 -j ACCEPT iptables -A INPUT -i tun0 -p udp --destination-port 53 -j ACCEPT #Accès serveur web privé iptables -A INPUT -i tun0 -p tcp --destination-port 80 -j ACCEPT #Serveur web publique iptables -A INPUT -p tcp --destination-port 81 -j ACCEPT #Transmission-daemon #Panel iptables -A INPUT -i tun0 -p tcp --destination-port 9091 -j ACCEPT iptables -A INPUT -p tcp --dport 51413 -j ACCEPT iptables -A INPUT -p udp --dport 51413 -j ACCEPT ``` ---
**Author:** ![PascalHambourg](https://www.debian-fr.org/user_avatar/www.debian-fr.org/pascalhambourg/32/5837_2.png) [@PascalHambourg](https://www.debian-fr.org/u/PascalHambourg)\ **Post date:** [Avril 27, 2020, 1:30 UTC](https://www.debian-fr.org/t/audit-iptables/81915/22 "2020-04-27T13:30:40Z")
Il y a une erreur dans les règles POSTROUTING. ---
**Author:** ![pyridoxine](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/p/e79b87/32.png) [@pyridoxine](https://www.debian-fr.org/u/pyridoxine)\ **Post date:** [Avril 27, 2020, 1:36 UTC](https://www.debian-fr.org/t/audit-iptables/81915/23 "2020-04-27T13:36:15Z")
> [@pyridoxine](#): > > ```plaintext > iptables -t nat -A PREROUTING -d ipfailover1 -j DNAT --to-destination 10.8.0.3 > iptables -t nat -A POSTROUTING -s 10.8.0.3 **!** -o tun0 -j SNAT --to-source ipfailover1 > > iptables -t nat -A PREROUTING -d ipfailover2 -j DNAT --to-destination 10.8.0.5 > iptables -t nat -A POSTROUTING -s 10.8.0.5 **!** -o tun0 -j SNAT --to-source ipfailover2 > > iptables -t nat -A POSTROUTING -s 10.8.0.0/24 **!** -o tun0 -j SNAT --to-source ipvps > > ``` → ```plaintext iptables -t nat -A PREROUTING -d ipfailover1 -j DNAT --to-destination 10.8.0.3 iptables -t nat -A POSTROUTING -s 10.8.0.3 -o tun0 -j SNAT --to-source ipfailover1 iptables -t nat -A PREROUTING -d ipfailover2 -j DNAT --to-destination 10.8.0.5 iptables -t nat -A POSTROUTING -s 10.8.0.5 -o tun0 -j SNAT --to-source ipfailover2 iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o tun0 -j SNAT --to-source ipvps ``` Je pense que c’est ça. ---
**Author:** ![PascalHambourg](https://www.debian-fr.org/user_avatar/www.debian-fr.org/pascalhambourg/32/5837_2.png) [@PascalHambourg](https://www.debian-fr.org/u/PascalHambourg)\ **Post date:** [Avril 27, 2020, 1:46 UTC](https://www.debian-fr.org/t/audit-iptables/81915/24 "2020-04-27T13:46:11Z")
En effet. ---
**Author:** ![pyridoxine](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/p/e79b87/32.png) [@pyridoxine](https://www.debian-fr.org/u/pyridoxine)\ **Post date:** [Avril 27, 2020, 2:08 UTC](https://www.debian-fr.org/t/audit-iptables/81915/25 "2020-04-27T14:08:23Z")
Du coup, plus d’incohérences à tes yeux ? 🧐 Si c’est le cas, je te remercie, dès que je peux, je vais tester les configurations ! ---
**Author:** ![PascalHambourg](https://www.debian-fr.org/user_avatar/www.debian-fr.org/pascalhambourg/32/5837_2.png) [@PascalHambourg](https://www.debian-fr.org/u/PascalHambourg)\ **Post date:** [Avril 27, 2020, 2:11 UTC](https://www.debian-fr.org/t/audit-iptables/81915/26 "2020-04-27T14:11:23Z")
Oui, il faut tester. En cas de problème, ajouter des règles LOG pour voir ce qui est bloqué. ---
**Author:** ![pyridoxine](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/p/e79b87/32.png) [@pyridoxine](https://www.debian-fr.org/u/pyridoxine)\ **Post date:** [Avril 27, 2020, 3:14 UTC](https://www.debian-fr.org/t/audit-iptables/81915/27 "2020-04-27T15:14:10Z")
je ne risque pas de me bloquer en appliquant le script ? car j’ai un doute concernant l’emplacement de : ```nohighlight iptables -A INPUT -m state --state ESTABLISHED -j ACCEPT ``` je la verrai avant : ```nohighlight iptables -P INPUT DROP iptables -P FORWARD DROP iptables -P OUTPUT ACCEPT ``` ---
**Author:** ![PascalHambourg](https://www.debian-fr.org/user_avatar/www.debian-fr.org/pascalhambourg/32/5837_2.png) [@PascalHambourg](https://www.debian-fr.org/u/PascalHambourg)\ **Post date:** [Avril 27, 2020, 3:28 UTC](https://www.debian-fr.org/t/audit-iptables/81915/28 "2020-04-27T15:28:54Z")
Ça ne devrait pas faire une grosse différence. Si un paquet TCP est bloqué transitoirement, il sera retransmis un peu plus tard. Par contre il faut bien l’exécuter en tant que script, et pas ligne par ligne dans le shell. De toute façon tu as bien une console de dépannage pour reprendre la main si nécessaire ? ---
**Author:** ![pyridoxine](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/p/e79b87/32.png) [@pyridoxine](https://www.debian-fr.org/u/pyridoxine)\ **Post date:** [Avril 27, 2020, 3:45 UTC](https://www.debian-fr.org/t/audit-iptables/81915/29 "2020-04-27T15:45:27Z")
> [@PascalHambourg](#): > > De toute façon tu as bien une console de dépannage pour reprendre la main si nécessaire ? oui sans problème ! Petite question : ```plaintext #Permettre de laisser passer le traffic de ens3 vers tun0 iptables -A FORWARD -i ens3 -o tun0 -j ACCEPT #Permettre de laisser passer le traffic de tun0 vers ens3 iptables -A FORWARD -i tun0 -o ens3 -j ACCEPT ``` Pourquoi ne pas le faire également pour ens3:1 et ens3:2 qui sont les interfaces pour les ipfailover ? ---
**Author:** ![PascalHambourg](https://www.debian-fr.org/user_avatar/www.debian-fr.org/pascalhambourg/32/5837_2.png) [@PascalHambourg](https://www.debian-fr.org/u/PascalHambourg)\ **Post date:** [Avril 27, 2020, 4:01 UTC](https://www.debian-fr.org/t/audit-iptables/81915/30 "2020-04-27T16:01:50Z")
Surtout pas : ens3:1 et ens3:2 ne sont pas de vraies interfaces, ce sont des « alias IP », des étiquettes qui servaient à ajouter des adresses IPv4 supplémentaire à l’interface ens3. Les règles iptables ne les voient pas, elles ne voient que la véritable interface ens3. Je n’avais pas pris la peine de le signaler après avoir parcouru le tutoriel, mais cette technique est obsolète, maintenant on peut directement affecter plusieurs adresses à une même interface. ---
**Author:** ![pyridoxine](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/p/e79b87/32.png) [@pyridoxine](https://www.debian-fr.org/u/pyridoxine)\ **Post date:** [Avril 27, 2020, 4:06 UTC](https://www.debian-fr.org/t/audit-iptables/81915/31 "2020-04-27T16:06:09Z")
Aurais-tu un tuto permettant de faire quelque chose au goût du jour ? ---
**Author:** ![PascalHambourg](https://www.debian-fr.org/user_avatar/www.debian-fr.org/pascalhambourg/32/5837_2.png) [@PascalHambourg](https://www.debian-fr.org/u/PascalHambourg)\ **Post date:** [Avril 27, 2020, 4:38 UTC](https://www.debian-fr.org/t/audit-iptables/81915/32 "2020-04-27T16:38:10Z")
Je ne suis pas très « tuto ». Si les interfaces réseau sont configurées dans /etc/network/interfaces, il suffit d’ajouter une strophe « iface » pour chaque adresse. ``` iface ens3 inet static address x.x.x.x/32 ``` D’autre part, je me demande dans quelle mesure il est nécessaire d’ajouter les adresses « failover » à l’interface. La seule raison, ce serait si les routeurs connectés au réseau du serveur envoient des requêtes ARP pour résoudre les adresses. Je ne sais pas comment les adresses « failover » sont gérées par l’hébergeur de ton serveur, ni si le routage d’un adresse « failover » est direct (requête ARP pour l’adresse failover) ou indirect (requête ARP pour l’adresse principale du serveur). Tu peux faire une capture du trafic ARP sur ens3 tout en générant du trafic sur une adresse failover pour voir. ``` tcpdump -nti ens3 arp ``` Dans le second cas, pas besoin de les ajouter. ---
**Author:** ![pyridoxine](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/p/e79b87/32.png) [@pyridoxine](https://www.debian-fr.org/u/pyridoxine)\ **Post date:** [Avril 27, 2020, 5:22 UTC](https://www.debian-fr.org/t/audit-iptables/81915/33 "2020-04-27T17:22:23Z")
je reviendrai sur ce sujet un peu plus tard ! Personnellement, j’ai commandé 2 ips failover sur mon vps (chez ovh). Ensuite, pour les faires fonctionner j’ai ajouter les lignes correspondantes dans mon fichier /etc/network/interfaces : ```auto # This file describes the network interfaces available on your system # and how to activate them. For more information, see interfaces(5). source /etc/network/interfaces.d/* # The loopback network interface auto lo iface lo inet loopback # The primary network interface allow-hotplug ens4 iface ens4 inet dhcp auto ens3:1 iface ens3:1 inet static address ipfailover1 netmask 255.255.255.255 auto ens3:2 iface ens3:2 inet static address ipfailover2 netmask 255.255.255.255 ``` là, j’ai essayé cette configuration : ```auto #!/bin/sh echo "Flushing iptables rules..." sleep 1 iptables -F iptables -X iptables -t nat -F iptables -t nat -X iptables -t mangle -F iptables -t mangle -X iptables -A INPUT -m state --state ESTABLISHED -j ACCEPT iptables -P INPUT DROP iptables -P FORWARD DROP iptables -P OUTPUT ACCEPT #Laisser les connexions établies ouvertes iptables -A INPUT -m state --state ESTABLISHED -j ACCEPT #Autoriser le loopback iptables -A INPUT -i lo -j ACCEPT #Port SSH iptables -A INPUT -p tcp --destination-port 32 -j ACCEPT iptables -t nat -A PREROUTING -d ipfo1 -j DNAT --to-destination 10.8.0.3 iptables -t nat -A POSTROUTING -s 10.8.0.3 -o tun0 -j SNAT --to-source fo1 iptables -t nat -A PREROUTING -d ipfo2 -j DNAT --to-destination 10.8.0.5 iptables -t nat -A POSTROUTING -s 10.8.0.5 -o tun0 -j SNAT --to-source ipfo2 iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o tun0 -j SNAT --to-source ipvps #Permettre de laisser passer le traffic de ens3 vers tun0 iptables -A FORWARD -i ens3 -o tun0 -j ACCEPT #Permettre de laisser passer le traffic de tun0 vers ens3 iptables -A FORWARD -i tun0 -o ens3 -j ACCEPT #Pour permettre aux clients du vpn d'établir une connexion au serveur. iptables -A INPUT -i ens3 -p udp --dport 1194 -j ACCEPT #laisser le traffic entrer sur l'interface tun0 sans restriction. iptables -A INPUT -i tun0 -j ACCEPT #serveur web publique iptables -A INPUT -p tcp --destination-port 81 -j ACCEPT #Transmission-daemon iptables -A INPUT -p tcp --dport 51413 -j ACCEPT iptables -A INPUT -p udp --dport 51413 -j ACCEPT ``` Malheureusement, mes clients openvpn n’ont pas internet 😕 ---
**Author:** ![PascalHambourg](https://www.debian-fr.org/user_avatar/www.debian-fr.org/pascalhambourg/32/5837_2.png) [@PascalHambourg](https://www.debian-fr.org/u/PascalHambourg)\ **Post date:** [Avril 27, 2020, 8:35 UTC](https://www.debian-fr.org/t/audit-iptables/81915/34 "2020-04-27T20:35:30Z")
L’interface de sortie des règles SNAT n’est pas bonne, ça m’avait échappé. ---
**Author:** ![pyridoxine](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/p/e79b87/32.png) [@pyridoxine](https://www.debian-fr.org/u/pyridoxine)\ **Post date:** [Avril 27, 2020, 8:45 UTC](https://www.debian-fr.org/t/audit-iptables/81915/35 "2020-04-27T20:45:38Z")
Je viens de rectifier tun0 \> ens3 ; et ça fonctionne ! Peux-tu m’en dire un peu plus concernant les ips failovers, si on pouvait faire autrement / plus simplement ? Egalement, c’est surement une question bête, mais lorsque je test si un port est ouvert ou fermé, est-qu’il faut un programme qui écoute, tourne, derrière un ce port pour qu’il soit considéré comme open ou bien, il s’affichera comme fermé ? ---
**Author:** ![PascalHambourg](https://www.debian-fr.org/user_avatar/www.debian-fr.org/pascalhambourg/32/5837_2.png) [@PascalHambourg](https://www.debian-fr.org/u/PascalHambourg)\ **Post date:** [Avril 27, 2020, 9:41 UTC](https://www.debian-fr.org/t/audit-iptables/81915/36 "2020-04-27T21:41:03Z")
> [@pyridoxine](#): > > Peux-tu m’en dire un peu plus concernant les ips failovers, si on pouvait faire autrement / plus simplement ? D’abord il faut vérifier s’il y a des requêtes ARP pour les adresses IP failover. Si oui, alors tu peux remplacer les strophes ens3:X dans /etc/network/interfaces par ce que j’ai proposé. Si non, tu peux carrément les supprimer. > [@pyridoxine](#): > > lorsque je test si un port est ouvert ou fermé, est-qu’il faut un programme qui écoute, tourne, derrière un ce port pour qu’il soit considéré comme open ou bien, il s’affichera comme fermé ? Lorsqu’aucun processus n’écoute sur un port, le port est dit fermé et renvoie immédiatement une information disant qu’il est fermé. Tes règles DROP bloquent silencieusement les demandes de connexion, donc le port est dit filtré et non fermé et ne renvoie aucune information sur son état. Le programme client part en time-out. Pour simuler un port fermé avec iptables, il faut utiliser la cible REJECT au lieu de DROP. ---
**Author:** ![pyridoxine](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/p/e79b87/32.png) [@pyridoxine](https://www.debian-fr.org/u/pyridoxine)\ **Post date:** [Avril 27, 2020, 9:57 UTC](https://www.debian-fr.org/t/audit-iptables/81915/37 "2020-04-27T21:57:49Z")
Merci pour l’explication ! > [@PascalHambourg](#): > > D’abord il faut vérifier s’il y a des requêtes ARP pour les adresses IP failover. J’ai ceci (12.13.502.14 étant l’ip du vps) : ```texte tcpdump -nti ens3 arp tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on ens3, link-type EN10MB (Ethernet), capture size 262144 bytes ARP, Request who-has ipfailover1 tell 12.13.500.1, length 28 ARP, Reply ipfailover1 is-at fa:16:3e:9f:58:eb, length 28 ARP, Request who-has 12.13.502.14 tell 12.13.500.1, length 28 ARP, Reply 12.13.502.14 is-at fa:16:3e:9f:58:eb, length 28 ARP, Request who-has ipfailover2 tell 12.13.500.1, length 28 ARP, Reply ipfailover2 is-at fa:16:3e:9f:58:eb, length 28 ARP, Request who-has 12.13.502.14 tell 12.13.500.1, length 28 ARP, Reply 12.13.502.14 is-at fa:16:3e:9f:58:eb, length 28 ARP, Request who-has ipfailover1 tell 12.13.500.1, length 28 ARP, Reply ipfailover1 is-at fa:16:3e:9f:58:eb, length 28 ARP, Request who-has ipfailover2 tell 12.13.500.1, length 28 ARP, Reply ipfailover2 is-at fa:16:3e:9f:58:eb, length 28 ARP, Request who-has 12.13.502.14 tell 12.13.500.1, length 28 ARP, Reply 12.13.502.14 is-at fa:16:3e:9f:58:eb, length 28 ARP, Request who-has ipfailover1 tell 12.13.500.1, length 28 ARP, Reply ipfailover1 is-at fa:16:3e:9f:58:eb, length 28 ARP, Request who-has ipfailover2 tell 12.13.500.1, length 28 ARP, Reply ipfailover2 is-at fa:16:3e:9f:58:eb, length 28 ARP, Request who-has 12.13.502.14 tell 12.13.500.1, length 28 ARP, Reply 12.13.502.14 is-at fa:16:3e:9f:58:eb, length 28 ARP, Request who-has ipfailover1 tell 12.13.500.1, length 28 ARP, Reply ipfailover1 is-at fa:16:3e:9f:58:eb, length 28 ^C 22 packets captured 26 packets received by filter 0 packets dropped by kernel ``` Par contre, je viens de m’apercevoir que cette règle ou non : ```texte iptables -A INPUT -i tun0 -j ACCEPT ``` Les clients vpn ont accès librement au web, c’est normal ? ---
**Author:** ![PascalHambourg](https://www.debian-fr.org/user_avatar/www.debian-fr.org/pascalhambourg/32/5837_2.png) [@PascalHambourg](https://www.debian-fr.org/u/PascalHambourg)\ **Post date:** [Avril 27, 2020, 10:41 UTC](https://www.debian-fr.org/t/audit-iptables/81915/38 "2020-04-27T22:41:12Z")
Il y a bien des requêtes ARP pour les adresses failover, donc il faut garder ces adresses sur l’interface ethernet, ou bien faire du proxy ARP pour elles mais ce n’est pas plus simple, et ce serait utile seulement pour pouvoir les affecter directement à des clients VPN sans faire du NAT. > [@pyridoxine](#): > > Les clients vpn ont accès librement au web, c’est normal ? Tu veux dire à internet ou aux services web du serveur ? Pour l’accès à internet c’est normal, le trafic passe par la chaîne FORWARD et non INPUT (sauf les requêtes DNS si les clients utilisent le serveur comme serveur DNS). Pour avoir accès aux services web du serveur, il faut soit cette règle soit des règles pour les différents ports. ---
**Author:** ![pyridoxine](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/p/e79b87/32.png) [@pyridoxine](https://www.debian-fr.org/u/pyridoxine)\ **Post date:** [Avril 27, 2020, 11:04 UTC](https://www.debian-fr.org/t/audit-iptables/81915/39 "2020-04-27T23:04:40Z")
> [@PascalHambourg](#): > > Il y a bien des requêtes ARP pour les adresses failover, donc il faut garder ces adresses sur l’interface ethernet, ou bien faire du proxy ARP pour elles mais ce n’est pas plus simple, et ce serait utile seulement pour pouvoir les affecter directement à des clients VPN sans faire du NAT. un avantage à affecter directement les ips aux clients sans faire du NAT ? > [@PascalHambourg](#): > > Tu veux dire à internet ou aux services web du serveur ? Ils ont accès à internet et aux services web du serveur. > [@PascalHambourg](#): > > Pour l’accès à internet c’est normal, le trafic passe par la chaîne FORWARD et non INPUT (sauf les requêtes DNS si les clients utilisent le serveur comme serveur DNS). Ah je comprends mieux ! Par contre, oui, accès à internet, mais pas au serveur web sur les port 80 et 81 ni même à mon panel de transmission ! Par contre, la résolution DNS fonctionnait quand même ! Mais lorsque dans le fichier de configuration d’openvpn je mettais comme adresse DNS 10.8.0.1, pour que Pi hole puisse faire office de « filtre DNS » effectivement là ça ne fonctionnait plus. Je t’ai peut être perdu sur cette phrase, car bon on sort du cadre… Si l’idée me vient de vouloir faire l’inverse. Que les clients vpn puisse accéder au serveur mais uniquement pour utiliser les services « localement » sans pouvoir utiliser le vpn pour aller sur internet. Je commente l’une de ces commandes : ```plaintext iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o ens3 -j SNAT --to-source ipvps iptables -A FORWARD -i ens3 -o tun0 -j ACCEPT iptables -A FORWARD -i tun0 -o ens3 -j ACCEPT ``` ? J’ai testé ça fonctionne, mais c’est peut être du bricolage dont je suis adepte 😂 Egalement, je n’arrive pas à comprendre comment est-ce que tun0 peut communiquer librement avec internet, sachant que l’interface ens3 est bloqué en input, il n’y a que le port 32, 81, 1194, 9091, 51413 d’ouvert… Je ne sais pas pourquoi, dans ma tête ce n’est pas normal que ça fonctionne. tun0 d’un point de vue extérieur n’est pas visible ? Il y a uniquement ens3 en liaison avec l’extérieur ? Ce que je veux dire, c’est que si on souhaite accéder à tun0 depuis l’extérieur, on passe forcément pas ens3 ? ---
**Author:** ![PascalHambourg](https://www.debian-fr.org/user_avatar/www.debian-fr.org/pascalhambourg/32/5837_2.png) [@PascalHambourg](https://www.debian-fr.org/u/PascalHambourg)\ **Post date:** [Avril 30, 2020, 7:17 UTC](https://www.debian-fr.org/t/audit-iptables/81915/40 "2020-04-30T07:17:22Z")
> [@pyridoxine](#): > > un avantage à affecter directement les ips aux clients sans faire du NAT ? Fournir une véritable connectivité IP de bout en bout en évitant les inconvénients du NAT. Le NAT ne fonctionne pas avec certains flux, notamment ceux qui ne se comportent pas comme des « connexions » (quadruplet adresse+port source et destination), ou qui transmettent des informations de couche réseau dans les couches supérieures (exemple : FTP, SIP). > [@pyridoxine](#): > > Que les clients vpn puisse accéder au serveur mais uniquement pour utiliser les services « localement » sans pouvoir utiliser le vpn pour aller sur internet. > Je commente l’une de ces commandes : Le plus propre est de désactiver les deux règles ACCEPT dans FORWARD. Le NAT ne devrait pas être utilisé pour faire du filtrage, ce n’est pas fiable. > [@pyridoxine](#): > > Egalement, je n’arrive pas à comprendre comment est-ce que tun0 peut communiquer librement avec internet, sachant que l’interface ens3 est bloqué en input Les paquets transmis d’une interface à l’autre ne transitent pas par la chaîne INPUT, seulement par la chaîne FORWARD. La chaîne INPUT ne traite que les paquets destinés à la machine elle-même. [Page précédente](https://www.debian-fr.org/t/audit-iptables/81915.md?page=1) [Page suivante](https://www.debian-fr.org/t/audit-iptables/81915.md?page=3)