Problème routage iptables

Recif · Février 21, 2016, 2:08pm

Bonjour,

Le serveur a changé d’IP et j’ai besoin de router le traffic sur cette nouvelle ip… Je ne sais absolument pas comment faire… Quelqu’un pourrait il me donner un coup de main? Le serveur a trois IPs, la principale étant nullroutée, je souhaite utiliser une des deux autres. Les sites web sont bien accessible, mais le traffic smtp est dans les choux :

Jan 27 21:52:23 xxxxx named[15705]: error (network unreachable) resolving 'mx1.hotmail.com/A/IN': 2001:7fd::1#53 Jan 27 21:52:24 xxxxx named[15705]: error (network unreachable) resolving 'wanado.fr/MX/IN': 2001:7fe::53#53 Jan 27 21:52:24 xxxxx named[15705]: error (network unreachable) resolving 'wanado.fr/MX/IN': 2001:7fd::1#53 Jan 27 21:52:24 xxxxx named[15705]: error (network unreachable) resolving '125.234.15.218.in-addr.arpa/PTR/IN': 2001:500:3::42#53

En ce moment l’ip principale est 1.1.1.223
L’ip à changer est 1.1.1.242

Config réseau actuelle:

[code]# Generated by iptables-save v1.4.8 on Fri Jan 25 15:42:18 2013
*nat
REROUTING ACCEPT [117819952:37612778332]
OSTROUTING ACCEPT [37975877:2452962977]
:OUTPUT ACCEPT [37975857:2452961893]
COMMIT

Completed on Fri Jan 25 15:42:18 2013

Generated by iptables-save v1.4.8 on Fri Jan 25 15:42:18 2013

*filter
:INPUT ACCEPT [23636]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [39582]

venet0 OpenVZ 127.0.0.1 255.255.255.255
Oui
venet0:0 OpenVZ (Virtualmin) 1.1.1.223 255.255.255.255
Oui
venet0:1 OpenVZ (Virtuel) 1.1.1.241 255.255.255.255
Oui
venet0:2 OpenVZ (Virtualmin) 1.1.1.242 255.255.255.255
Oui
venet0:3 OpenVZ (Virtuel) 1.1.1.243 255.255.255.255
Oui[/code]

Comment faire? Quelle est la commande à passer?
Merci

PascalHambourg · Février 21, 2016, 2:08pm

Je n’ai rien compris. Tu parles d’iptables et de routage, mais iptables fait du filtrage pas du routage. Tu dis que les communications SMTP ne fonctionnent plus mais tu donnes des logs de named (BIND). Le jeu de règles est vide et tout est à ACCEPT, donc iptables ne bloque rien sur la machine sur laquelle tu as exécuté iptables-save (laquelle ?).
Tu dis que le serveur a trois adresses mais tu en listes quatre (je ne compte pas 127.0.0.1).
Qu’entends-tu par “l’adresse principale est nullroutée” ? Si elle n’est pas utilisable, il faut la supprimer, non ?

Recif · Février 21, 2016, 2:08pm

Bonjour,

Ok, désolé je ne suis pas un utilisateur très averti…

En effet, erreur de ma part il y en a 4…
Suite à une attaque ddos l’hébergeur a nullrouté l’adresse principale (223) et m’a attribué plusieurs IPs. Il y en a une que j’ai choisi pour mettre en ligne les sites web : la 242. Les sites sont bien visibles, on y accède bien, mais aucun mails envoyés par le serveur ne partent. Lorsque je regarde dans le syslog:

Jan 28 14:38:12 xxxx named[31977]: error (network unreachable) resolving '116.179.13.109.in-addr.arpa/PTR/IN': 2001:500:13::c7d4:35#53 Jan 28 14:38:12 xxxx named[31977]: error (network unreachable) resolving '74.20.90.92.in-addr.arpa/PTR/IN': 2001:660:3006:1::1:1#53 Jan 28 14:38:12 xxxx named[31977]: client 127.0.0.1#59646: error sending response: host unreachable Jan 28 14:38:13 xxxx named[31977]: error (network unreachable) resolving '163.201.43.90.in-addr.arpa/PTR/IN': 2001:500:13::c7d4:35#53 Jan 28 14:38:13 xxxx named[31977]: error (network unreachable) resolving '33.113.253.193.in-addr.arpa/PTR/IN': 2001:660:3006:1::1:1#53 Jan 28 14:38:13 xxxx named[31977]: error (network unreachable) resolving '33.113.253.193.in-addr.arpa/PTR/IN': 2001:500:13::c7d4:35#53 Jan 28 14:38:16 xxxx named[31977]: error (network unreachable) resolving '148.249.50.159.in-addr.arpa/PTR/IN': 2001:43f8:110::10#53 Jan 28 14:38:17 xxxx named[31977]: error (network unreachable) resolving '91.13.209.86.in-addr.arpa/PTR/IN': 2001:660:3006:1::1:1#53 Jan 28 14:38:17 xxxx named[31977]: error (network unreachable) resolving '215.153.20.90.in-addr.arpa/PTR/IN': 2001:660:3006:1::1:1#53 Jan 28 14:38:18 xxxx named[31977]: error (network unreachable) resolving '99.230.3.31.in-addr.arpa/PTR/IN': 2001:500:13::c7d4:35#53 Jan 28 14:38:19 xxxx named[31977]: error (network unreachable) resolving '5.237.242.94.in-addr.arpa/PTR/IN': 2001:660:3006:1::1:1#53 Jan 28 14:38:19 xxxx named[31977]: error (network unreachable) resolving 'nbdns.zjnetcom.com/AAAA/IN': 2001:503:ba3e::2:30#53 Jan 28 14:38:19 xxxx named[31977]: error (network unreachable) resolving 'nbdns.zjnetcom.com/AAAA/IN': 2001:7fe::53#53 Jan 28 14:38:19 xxxx dovecot: pop3-login: Login: user=<xxxxxx.yyyyyyyyyy>, method=PLAIN, rip=83.194.109.80, lip=94.247.177.242 Jan 28 14:38:19 xxxx dovecot: POP3(xxxxxx.yyyyyyyyyy): Disconnected: Logged out top=0/0, retr=0/0, del=0/8, size=61154 Jan 28 14:38:20 xxxx named[31977]: error (network unreachable) resolving '7.1.200.94.in-addr.arpa/PTR/IN': 2001:660:3006:1::1:1#53 Jan 28 14:38:20 xxxx named[31977]: error (network unreachable) resolving '7.1.200.94.in-addr.arpa/PTR/IN': 2001:500:13::c7d4:35#53

Lorsque je regarde dans le daemon.log:

Jan 28 14:39:12 xxxx named[31977]: error (network unreachable) resolving '32.34.208.109.in-addr.arpa/PTR/IN': 2001:500:13::c7d4:35#53 Jan 28 14:39:14 xxxx named[31977]: error (network unreachable) resolving 'sns-pb.isc.org/AAAA/IN': 2001:500:e::1#53 Jan 28 14:39:14 xxxx named[31977]: error (network unreachable) resolving 'freens2-g20.free.fr/AAAA/IN': 2001:503:c27::2:30#53 Jan 28 14:39:15 xxxx named[31977]: error (network unreachable) resolving 'www.abix.fr/A/IN': 2001:678:c::1#53 Jan 28 14:39:16 xxxx named[31977]: error (network unreachable) resolving 'a.support-intelligence.net/AAAA/IN': 2001:500:1::803f:235#53 Jan 28 14:39:16 xxxx named[31977]: error (network unreachable) resolving 'b.support-intelligence.net/AAAA/IN': 2001:500:2f::f#53 Jan 28 14:39:16 xxxx named[31977]: error (network unreachable) resolving 'ns2.spamhaus.rethemdns.net/A/IN': 2001:503:231d::2:30#53 Jan 28 14:39:16 xxxx named[31977]: error (network unreachable) resolving 'ns2.spamhaus.rethemdns.net/AAAA/IN': 2001:503:a83e::2:30#53 Jan 28 14:39:16 xxxx named[31977]: error (network unreachable) resolving 'ns4.spamhaus.rethemdns.net/AAAA/IN': 2001:503:231d::2:30#53 Jan 28 14:39:16 xxxx named[31977]: error (network unreachable) resolving 'xxxx.ispfr.net/MX/IN': 2001:503:231d::2:30#53 Jan 28 14:39:16 xxxx named[31977]: error (network unreachable) resolving 'dns.ispfr.net/A/IN': 2001:503:a83e::2:30#53 Jan 28 14:39:16 xxxx named[31977]: error (network unreachable) resolving 'dns.ispfr.net/A/IN': 2001:503:231d::2:30#53 Jan 28 14:39:16 xxxx named[31977]: error (network unreachable) resolving '83.206.221.78.in-addr.arpa/PTR/IN': 2001:660:3006:1::1:1#53 Jan 28 14:39:16 xxxx named[31977]: error (network unreachable) resolving '83.206.221.78.in-addr.arpa/PTR/IN': 2001:500:13::c7d4:35#53

L’hébergeur me dit que:

Ca te parait plus clair comme ça?..

PascalHambourg · Février 21, 2016, 2:08pm

Je me demande ce qu’a voulu dire l’hébergeur au sujet des règles de routage et d’iptables…
Je ne sais pas non plus comment se manifeste le nullroutage, mais je suppose que ton BIND continue d’envoyer les requêtes avec l’adresse source nullroutée, ce qui provoque les erreurs “network unreachable”.

Tu as plusieurs options.

Supprimer l’adresse nullroutée comme je l’ai déjà écrit. En direct :

Je ne sais pas comment le rendre persistant après un reboot de la machine virtuelle.

Configurer named (BIND), le MTA (agent de transfert SMTP) et toutes les autres applications susceptibles de faire des connexions sortantes pour qu’ils utilisent explicitement 1.1.1.242 comme adresse IP source. Certainement fastidieux.
Remplacer l’adresse source des connexions sortantes avec une règle iptables (ce n’est pas du routage mais du NAT source) sur la machine virtuelle ou la machine hôte :

Mais c’est du NAT donc c’est très laid, d’autant qu’il y a des alternatives. Mais comme ça semble facile, je suis sûr que c’est ce que tu vas choisir…
Les règles iptables ne sont pas persistantes après un reboot, donc il faudra la recréer à chaque démarrage avec un script ou un fichier de configuration, je ne sais pas ce qui est prévu mais il y a forcément quelque chose qui active iptables puisque les deux tables nat et filter sont actives.

Recif · Février 21, 2016, 2:08pm

Ok, par contre avant que je supprime la venet0: les autres ips, dont par exemple la 242 est sur venet0:2, cette interface ne dépend pas de venet0? Si je supprime venet0 elle ne va pas non plus être inaccessible?

Recif · Février 21, 2016, 2:08pm

Ah ah! J’ai juste appliqué la seconde règle (la première -ip route- ne semblait pas être présente) et maintenant j’ai ça en log:

Jan 28 16:56:26 xxxx postfix/smtp[19468]: 88D4610EA8251: to=<b.maerten@ipsi.fr>, relay=ipsi1.ipsi.fr[93.95.234.18]:25, delay=173757, delays=173379/368/10/0.17, dsn=2.0.0, status=sent (250 2.0.0 Ok: queued as 28D7A17C0010)
Jan 28 16:56:27 xxxx named[32225]: lame server resolving '119.234.15.199.in-addr.arpa' (in '234.15.199.in-addr.arpa'?): 199.15.232.2#53
Jan 28 16:56:27 xxxx named[32225]: lame server resolving '119.234.15.199.in-addr.arpa' (in '234.15.199.in-addr.arpa'?): 199.15.232.3#53
Jan 28 16:56:27 xxxx postfix/smtp[19466]: connect to hotmai.fr[216.8.179.25]:25: Connection timed out
Jan 28 16:56:27 xxxx postfix/smtp[19466]: 0251D10EA8257: to=<the-freeride-is-my-life@hotmai.fr>, relay=none, delay=173628, delays=173248/349/31/0, dsn=4.4.1, status=deferred (connect to hotmai.fr[216.8.179.25]:25: Connection timed out)
Jan 28 16:56:27 xxxx postfix/error[19283]: B20E110EA8356: to=<spiescrimeteam@hotmai.fr>, relay=none, delay=164113, delays=163735/378/0/0, dsn=4.4.1, status=deferred (delivery temporarily suspended: connect to hotmai.fr[216.8.179.25]:25: Connection timed out)
Jan 28 16:56:27 xxxx postfix/error[19703]: 430BA10EA8254: to=<spiescrimeteam@hotmai.fr>, relay=none, delay=173651, delays=173273/378/0/0, dsn=4.4.1, status=deferred (delivery temporarily suspended: connect to hotmai.fr[216.8.179.25]:25: Connection timed out)
Jan 28 16:56:27 xxxx postfix/error[19335]: 6747010EA8357: to=<rastagirl18@hotmai.fr>, relay=none, delay=164098, delays=163720/379/0/0, dsn=4.4.1, status=deferred (delivery temporarily suspended: connect to hotmai.fr[216.8.179.25]:25: Connection timed out)
Jan 28 16:56:27 xxxx postfix/error[19674]: 61BAE10EA824E: to=<spiescrimeteam@hotmai.fr>, relay=none, delay=173789, delays=173411/379/0/0.06, dsn=4.4.1, status=deferred (delivery temporarily suspended: connect to hotmai.fr[216.8.179.25]:25: Connection timed out)
Jan 28 16:56:27 xxxx postfix/smtp[19471]: 811ED10EA8CDF: to=<info@ecom.fr>, relay=remote.ecom.fr[193.251.1.84]:25, delay=19155, delays=18775/365/11/3.7, dsn=2.6.0, status=sent (250 2.6.0 <c04a236c198b5ca02fc72f02d4e4dac7@www.manger-moins-cher.com> [InternalId=3894] Queued mail for delivery)
Jan 28 16:56:27 xxxx postfix/qmgr[18826]: 811ED10EA8CDF: removed

Recif · Février 21, 2016, 2:08pm

Ah! Ca y est, je reçois les mails depuis les sites du serveur!!
Je vais faire encore des tests, mais ça m’a pas l’air trop mal barrée cette affaire! En tout cas un grand merci pour ton aide!!

PascalHambourg · Février 21, 2016, 2:08pm

Me suis planté dans la commande, c’est ip addr et non ip route… Je corrige dans le message concerné.

Il n’est pas question de supprimer l’interface venet0 mais de supprimer une de ses adresses IP.

Note : la notation venet0:2 n’est pas une interface, c’est juste un artifice que la commande ifconfig utilise pour ajouter une adresse IP supplémentaire à l’interface venet0 (un alias). La commande ip n’a pas besoin de cet artifice obsolète pour gérer plusieurs adresses sur une même interface.

Recif · Février 21, 2016, 2:08pm

Ok. J’ai appliqué la commande et j’ai eu ce message:

Warning: Executing wildcard deletion to stay compatible with old scripts. Explicitly specify the prefix length (1.1.1.223/32) to avoid this warning. This special behaviour is likely to disappear in further releases, fix your scripts!

Donc juste un warning…

PascalHambourg · Février 21, 2016, 2:08pm

Oui, juste un avertissement qu’on peut éviter en suivant sa recommandation.
Mais attention : si tu ne fais rien d’autre, l’adresse reviendra au prochain redémarrage de la machine virtuelle.

Recif · Février 21, 2016, 2:08pm

J’ai mis un fichier dans /etc/network/if-pre-up.d

qui contient:

ip addr del 1.1.1.223 dev venet0 iptables -t nat -A POSTROUTING -s 1.1.1.223 -j SNAT --to 1.1.1.242

C’est bon?

PascalHambourg · Février 21, 2016, 2:08pm

ip addr del dans pre-up, je crains que ce soit trop tôt. Plutôt dans up ou post-up.
Mais pourquoi ne pas plutôt supprimer l’adresse là où elle est configurée ?
D’autre part une seule des deux actions est nécessaire, pas les deux à la fois.
Certes si tu supprimes 1.1.1.223, alors c’est la suivante 1.1.1.241 qui risque de devenir l’adresse par défaut et non 1.1.1.242 comme tu le souhaites, mais est-ce gênant ? Et puis tu peux modifier l’ordre des adresses pour que la première soit celle que tu souhaites.

Ah, j’avais oublié une autre méthode : modifier l’adresse source dans la route par défaut, avec “ip route replace default src 1.1.1.242 via xxx dev xxx” (recopier les valeurs affichées par “ip route ls default” à la place des xxx).

Recif · Février 21, 2016, 2:08pm

Ah oui? Du coup j’ai fais les deux… Mais si la 1.1.1.223 n’existe plus, en effet, l’autre ne sert à rien.
Pour enlever à la source je vais où? Dans configuration reseau sous webmin j’ai “interfaces” et elles sont listées. J’enlève la dedans?

PascalHambourg · Février 21, 2016, 2:08pm

Je n’en sais rien, possible. A moins que ce soit fixé par l’hyperviseur openvz.

Recif · Février 21, 2016, 2:08pm

Je t’avoue que je n’ose pas trop supprimer une interface réseau dans mon panneau d’admin…

Recif · Février 21, 2016, 2:08pm

Bon ben j’ai crié victoire trop tôt… Je viens de faire un essai (enregistrement sur un forum) et je ne reçois pas le mail d’activation. De plus j’ai ça dans les logs:

Jan 28 18:40:38 xxxx postfix/smtp[11400]: A756E10EA81DD: to=<zettaki@laposte.net>, relay=none, delay=1520, delays=1488/0.11/31/0, dsn=4.4.1, status=deferred (connect to smtp4.laposte.net[193.251.214.113]:25: Connection timed out) Jan 28 18:40:38 xxxx postfix/smtp[11414]: 7CBA010EA8167: to=<hu.redon@laposte.net>, relay=none, delay=1521, delays=1490/0.13/31/0, dsn=4.4.1, status=deferred (connect to smtp4.laposte.net[193.251.214.113]:25: Connection timed out) Jan 28 18:40:38 xxxx postfix/smtp[11390]: 2918C10EA8140: to=<hu.redon@laposte.net>, relay=none, delay=1521, delays=1490/0.1/31/0, dsn=4.4.1, status=deferred (connect to smtp4.laposte.net[193.251.214.113]:25: Connection timed out) Jan 28 18:40:38 xxxx postfix/smtp[11397]: F12EE10EA8127: to=<alan29fr@voila.fr>, relay=none, delay=2333, delays=2302/0.11/31/0, dsn=4.4.1, status=deferred (connect to smtp-in.voila.fr[193.252.22.164]:25: Connection timed out) Jan 28 18:40:38 xxxx postfix/smtp[11412]: 3B43310EA8198: to=<momo@hotemail.fr>, relay=none, delay=1520, delays=1489/0.12/31/0, dsn=4.4.1, status=deferred (connect to redirect.ovh.net[213.186.33.5]:25: Connection timed out) Jan 28 18:40:42 xxxx postfix/smtp[11490]: connect to mx-eu.mail.am0.yahoodns.net[77.238.177.9]:25: Connection timed out

PascalHambourg · Février 21, 2016, 2:08pm

Tu as changé quelque chose depuis tout à l’heure ?
Qu’affichent les commandes suivantes ?

ip addr ls dev venet0 ip route ip route get 193.251.214.113 iptables-save

Recif · Février 21, 2016, 2:08pm

En fait je pense que c’est parce que j’ai supprimé la venet0:0 avec la ligne de commande rectifiée que tu m’as donné… Je l’ai remise avec la commande ip addr add 94.247.177.223 dev venet0 et je reçois à nouveau les mails…

commande 1:

2: venet0: <BROADCAST,POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN link/void inet 127.0.0.1/32 scope host venet0 inet 1.1.1.223/32 scope global venet0 inet 1.1.1.241/32 scope global venet0:1 inet 1.1.1.242/32 brd 1.1.1.242 scope global venet0:2 inet 1.1.1.243/32 scope global venet0:3

commande 2

127.0.0.0/8 dev lo scope link default dev venet0 scope link

commande 3

193.251.214.113 dev venet0 src 1.1.1.223 cache mtu 1500 advmss 1460 hoplimit 64

et enfin:

# Generated by iptables-save v1.4.8 on Mon Jan 28 19:17:51 2013
*nat
:PREROUTING ACCEPT [44850:2272685]
:POSTROUTING ACCEPT [2087:214296]
:OUTPUT ACCEPT [62088:3922325]
-A POSTROUTING -s 1.1.1.223/32 -j SNAT --to-source 1.1.1.242 
-A POSTROUTING -s 1.1.1.223/32 -j SNAT --to-source 1.1.1.242 
-A POSTROUTING -s 1.1.1.223/32 -j SNAT --to-source 1.1.1.242 
-A POSTROUTING -s 1.1.1.223/32 -j SNAT --to-source 1.1.1.242 
-A POSTROUTING -s 1.1.1.223/32 -j SNAT --to-source 1.1.1.242 
-A POSTROUTING -s 1.1.1.223/32 -j SNAT --to-source 1.1.1.242 
-A POSTROUTING -s 1.1.1.223/32 -j SNAT --to-source 1.1.1.242 
COMMIT
# Completed on Mon Jan 28 19:17:51 2013
# Generated by iptables-save v1.4.8 on Mon Jan 28 19:17:51 2013
*filter
:INPUT ACCEPT [5613990:8371777998]
:FORWARD ACCEPT [327179]
:OUTPUT ACCEPT [7336934:12418319635]
-A INPUT -i venet0:2 -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -i venet0:2 -p udp -m udp --sport 53 -j ACCEPT
-A INPUT -i venet0:2 -p tcp -m tcp --dport 25 -m state --state NEW,ESTABLISHED -j ACCEPT
-A INPUT -d 1.1.1.242/32 -p tcp -m tcp --sport 25 --dport 1024:65535 -m state --state ESTABLISHED -j ACCEPT
-A FORWARD -i vnet0:2 -j ACCEPT
-A FORWARD -o vnet0:2 -j ACCEPT
-A FORWARD -i venet0:0 -o venet0:2 -j ACCEPT
-A FORWARD -i venet0:0 -o venet0:2 -j ACCEPT
-A OUTPUT -o venet0:2 -p udp -m udp --dport 53 -j ACCEPT
-A OUTPUT -o venet0:2 -p tcp -m tcp --sport 25 -m state --state ESTABLISHED -j ACCEPT
-A OUTPUT -s 1.1.1.242/32 -p tcp -m tcp --sport 1024:65535 --dport 25 -m state --state NEW,ESTABLISHED -j ACCEPT
COMMIT
# Completed on Mon Jan 28 19:16:25 2013
# Generated by iptables-save v1.4.8 on Mon Jan 28 19:16:25 2013
*mangle
:PREROUTING ACCEPT [1159492669:912258097283]
:INPUT ACCEPT [1159164805:912204013817]
:FORWARD ACCEPT [327828]
:OUTPUT ACCEPT [1046027400:1107734898025]
:POSTROUTING ACCEPT [1046354819:1107788939306]
COMMIT
# Completed on Mon Jan 28 19:16:25 2013

Recif · Février 21, 2016, 2:08pm

et quand je fais:

/etc/init.d/networking restart
Running /etc/init.d/networking restart is deprecated because it may not enable again some interfaces … (warning).
Reconfiguring network interfaces…SIOCSIFADDR: File exists
SIOCSIFFLAGS: Cannot assign requested address
SIOCSIFNETMASK: Cannot assign requested address
SIOCSIFBRDADDR: Cannot assign requested address
SIOCSIFFLAGS: Cannot assign requested address
SIOCSIFFLAGS: Cannot assign requested address
Failed to bring up venet0:0.
done.

PascalHambourg · Février 21, 2016, 2:08pm

J’aurais plutôt voulu les résultats de ces commandes quand ça ne marchait plus, pour essayer de comprendre ce qui se passe.

Tout ce que je peux imaginer, c’est qu’en supprimant l’adresse 1.1.1.223, une autre adresse source a été choisie parmi celles attribuées à l’interface venet0 et ses alias. La commande “ip route get” aurait permis de savoir laquelle. La règle SNAT ne s’appliquant pas à cette adresse, je ne peux que supposer qu’elle n’était pas routée vers ta machine. Tu es sûr que les deux autres adresses, 1.1.1.241 et 1.1.1.242 sont utilisables par ta machine ?

Le jeu de règles iptables a bien grossi par rapport à ton premier message, et pas seulement à cause des multiples règles SNAT - une seule suffisait ! Comment cela se fait-il ?

A propos des règles iptables, elles sont sans effet à deux titres :

comme déjà dit, les notations venet0:X ne sont pas de vraies interfaces, aussi elles ne peuvent pas être utilisées dans des règles iptables ; cela ne provoque pas d’erreur mais les règles qui y font référence ne s’appliqueront jamais à aucun paquet puisque ces interfaces n’existent pas ;
toutes les règles de filtrage ont comme cible ACCEPT et les politiques par défaut des chaînes de filtrage sont aussi à ACCEPT, donc tous les paquets sont acceptés de toute façon.

Les messages d’erreur de networking restart s’explique probablement par le fait que tu as ajouté 1.1.1.223 à venet0 mais sans utiliser l’alias venet0:0. Quand le script tente de l’ajouter une seconde fois, ça provoque une erreur.

En tout cas ça donne une indication : apparemment, les adresses sont configurées dans /etc/network/interfaces. Que contient ce fichier ?