[resolu]Migration de iptables a nftables sur une passerelle

anonyme · 09-08-2019 18:29:11

le serveur

debian1     A 192.168.10.1

 

un client

kabylake1   A 192.168.10.53

      TXT         "un série de chifre"

si je fais un ping -c4 debian1 (en local )ce cochon me répond (encore heureux si il connaît pas son nom ........ )
un ping -c4 kabylake1 => service inconnu (du serveur)
le DNS (et le service de nom ) fonctionne pour tous les clients
va savoir ce que j'ai fait ...........
le tout c'est que je sache lors des tests du pare feu que cette commande ne fonctionne pas sans pare feu en local sur le serveur , après c'est pas trop grave
par contre c'est de ne pas l' expliquer (le pourquoi)

enicar · 09-08-2019 18:33:46

anonyme a écrit :

as sans pare feu en local sur le serveur , après c'est pas trop grave
par contre c'est de ne pas l' expliquer (le pourquoi)

Je ne peux pas t'aider sur ce sujet.

anonyme · 10-08-2019 12:16:40

pas le but , rien de bien important , le reste est nickel au niveau dns et dhcp
pour le moment une pose sur nftables , sinon je vais être dégoûté et abandonner ..........

enicar · 10-08-2019 14:42:41

Par contre j'ai des améliorations pour le pare-feu à proposer, je ferais cela en fin
de journée. Là je vais vaquer à d'autres activités.

enicar · 10-08-2019 14:44:43

anonyme a écrit :

e reste est nickel au niveau dns et dhcp
pour le moment une pose sur nftables , sinon je vais être dégoûté et abandonner

Tu peux poser des questions sur ce que tu ne comprends pas sur nftables.
J'essaierai d'y répondre, je ne connais pas l'outil à 100%.

enicar · 10-08-2019 19:45:31

Bon je pars du fichier /etc/nftables suivant :

#! /usrb/sbin/nft -f 

flush ruleset

table ip nat {

  chain PREROUTING {

    type nat hook prerouting priority -100; policy accept;

  }

  chain INPUT {

    type nat hook input priority 100; policy accept;

  }

  chain POSTROUTING {

    type nat hook postrouting priority 100; policy accept;

    oifname "enp6s0f0" masquerade

  }

  chain OUTPUT {

    type nat hook output priority -100; policy accept;

  }

}

table ip filter {

  chain INPUT {

    type filter hook input priority 0; policy drop;

    ip daddr 224.0.0.0/8 reject with icmp type admin-prohibited

    iif lo accept

    iifname "enp6s0f1" accept

    ct state invalid  limit rate 4/second burst 5 packets  log prefix "INVALID_INPUT " drop

    ct state established,related accept

    ip saddr 192.168.1.2 ip daddr 192.168.1.10 udp dport 123 accept

    icmp type { destination-unreachable,time-exceeded, parameter-problem } accept

    #log prefix "INPUT_DROP "

  }

  chain FORWARD {

    type filter hook forward priority 0; policy drop;

    iifname "enp6s0f1" accept

    ct state invalid  limit rate 4/second burst 5 packets  log prefix "INVALID_INPUT " drop

    ct state established,related accept

    log prefix "FORWARD_DROP "

  }

  chain OUTPUT {

    type filter hook output priority 0; policy accept;

  }

}

table ip6 filter {

  chain input {

    type filter hook input priority 0; policy drop;

    iif lo accept

  }

  chain forward {

    type filter hook forward priority 0; policy drop;

  }

  chain output {

    type filter hook output priority 0; policy drop;

    oif lo accept

  }

}

Par rapport à celui de ton post #102, la seule chose que
j'ai modifié c'est la chain output de la table ip6 filter.
J'ai mis la policy à drop, et autorisé tout le traffic sur lo.
J'ai aussi insérer la règle qui permet au switch de se mettre à
l'heure en utilisant le serveur ntp de la passerelle.
Je voudrais revenir sur cette règle, on peut faire bien mieux en
utilisant le suivi de connexion. Donc à la place de

ip saddr 192.168.1.2 ip daddr 192.168.1.10 udp dport 123 accept

 

Je propose

ct state new ip saddr 192.168.1.2 ip daddr 192.168.1.10 udp dport 123 accept

 

Ça permet d'autoriser spécifiquement une nouvelle connexion, le reste
sera fait par « ct state related,established accept » qui est avant.
Tant qu'à utiliser le suivi de connexions, autant l'utiliser vraiment
pour toutes les connexions, pas d'exception. De toute façon une fois en
marche le suivi de connexions enregistre tout le traffic tcp/ip,
ça serait dommage de ne pas se servir de cette information.

D'ailleurs on pourrait faire la même chose sur l'interface enp6s0f1, c'est
à dire du côté du réseau local, en acceptant des nouvelles connexions
(au sens du suivi de connexions) que sur les ports utilisés :
en tcp 22,25,53,80,631,8080 et en udp 53,67,123, 631.
Je ne ne sais pas trop comment c'est possible de faire du suivi de connexion
sur de l'udp, mais bon…
Je proposerais bien un truc
du genre :

#! /usrb/sbin/nft -f 

flush ruleset

table ip nat {

  chain PREROUTING {

    type nat hook prerouting priority -100; policy accept;

  }

  chain INPUT {

    type nat hook input priority 100; policy accept;

  }

  chain POSTROUTING {

    type nat hook postrouting priority 100; policy accept;

    oifname "enp6s0f0" masquerade

  }

  chain OUTPUT {

    type nat hook output priority -100; policy accept;

  }

}

table ip filter {

    chain local_in {

        ct state new tcp dport {ssh, smtp, domain, http, ipp, 8080} accept

        ct state new udp dport {domain, bootps, ntp, ipp} accept

        icmp type {echo-reply, echo-request} accept

    }

    chain INPUT {

        type filter hook input priority 0; policy drop;

        ip daddr 224.0.0.0/8 reject with icmp type admin-prohibited

        iif lo accept

        ct state invalid  limit rate 4/second burst 5 packets  log prefix "INVALID_INPUT " drop

        ct state established,related accept

        icmp type { destination-unreachable,time-exceeded, parameter-problem } accept

        iifname "enp6s0f1" jump local_in

        ct state new ip saddr 192.168.1.2 ip daddr 192.168.1.10 udp dport 123 accept

        #log prefix "INPUT_DROP "

    }

    chain FORWARD {

        type filter hook forward priority 0; policy drop;

        iifname "enp6s0f1" accept

        ct state invalid  limit rate 4/second burst 5 packets  log prefix "INVALID_INPUT " drop

        ct state established,related accept

        log prefix "FORWARD_DROP "

    }

    chain OUTPUT {

        type filter hook output priority 0; policy accept;

    }

}

table ip6 filter {

  chain input {

    type filter hook input priority 0; policy drop;

    iif lo accept

  }

  chain forward {

    type filter hook forward priority 0; policy drop;

  }

  chain output {

    type filter hook output priority 0; policy drop;

    oif lo accept

  }

}

Note : les espaces derrière les virgules dans « {ssh, smtp, domain}
ne sont pas là pour faire beau. Il sont nécessaires, sinon c'est une erreur
de syntaxe pour nft.

Tu peux adapter en fonction de tes besoins les ports à autoriser.
J'ai aussi autoriser les pings. Je pense que juste mettre echo-request
suffirait car il me semble que les echo-reply font partie des paquets related
dans le suivi de connexions.
Bon, j'espère n'avoir pas fait d'erreurs…

Dernière modification par enicar (10-08-2019 19:47:43)

anonyme · 11-08-2019 00:43:05

voila le fichier , il est pas chargé encore , et toujours en accept
ps; fichier effacé , non conforme

j'ai des questions sur cela

ct state new tcp dport {https, smtp, domain, http, ipp, 8080} accept

    ct state new udp dport {domain, bootps, ntp, ipp} accept

ssh (le serveur) est interdit sur la passerelle, si il est installé c'est a l'intérieur du sous-réseau (sur une machine qui fait office de serveur ) et uniquement en local.
remplacé ssh par https
domaine c'est le port 53 ?
bootps et ipp c'est quoi ? (quel port )
bind9 utilise un autre port que le 53 sur la boucle locale , donc normalement doit pas poser problème
le dhcp client et serveur je sais pas

tu dors jamais ? quoique moi aussi ........

pour l'ipv6 bloqué le forward uniquement (passerelle et client ) , faut que je réfléchisse a ce que je vais faire
il me reste a passer en "drop" et appliquer les règles
si j'ai pas fait d'erreurs et cette histoire de bootps et ipp

l'ordre des régles a une importance ? (ça correspond pas trop a ton exemple )

Dernière modification par anonyme (11-08-2019 11:32:38)

anonyme · 11-08-2019 00:58:03

voila appliqué , sauf ipv6 input et output en "accept"

systemctl status nftables.service

● nftables.service - nftables

   Loaded: loaded (/lib/systemd/system/nftables.service; enabled; vendor preset: enabled)

   Active: active (exited) since Sun 2019-08-11 01:56:08 CEST; 18s ago

     Docs: man:nft(8)

           http://wiki.nftables.org

  Process: 1778 ExecStart=/usr/sbin/nft -f /etc/nftables.conf (code=exited, status=0/SUCCESS)

 Main PID: 1778 (code=exited, status=0/SUCCESS)

août 11 01:56:07 debian1 systemd[1]: Starting nftables...

août 11 01:56:08 debian1 systemd[1]: Started nftables.

le switch se met a l'heure (192.168.1.2 )
je surveille les logs
pour "ipp" trouvé => https://fr.wikipedia.org/wiki/Internet_ … g_Protocol
pour bootps pas utile => https://fr.wikipedia.org/wiki/Bootstrap_Protocol
j'en ai fait en 2015 , mais sur la passerelle je peu le retirer.
j'ai démarré une machine le DHCPD et le DNS fonctionne

adding an RR at 'kabylake1  A 192.168.10.53

key approved

adding an RR at '53.10.168.192.in-addr.arpa' PTR kabylake1

a priori ça tourne
ps: je modifie le #132 comme la réalité

sur la passerelle pas de serveur d'impression , mais j'ai gardé ipp , supprimé bootps
je suis en train de réfléchir , tu a pas mit bootps pour les ports 67 et 68 ? (du dhcp )

Aug 11 02:11:55 debian1 dhcpd[925]: DHCPDISCOVER from 2c:4d:54:54:68:ea via enp6s0f1

Aug 11 02:11:56 debian1 dhcpd[925]: DHCPOFFER on 192.168.10.53 to 2c:4d:54:54:68:ea (kabylake1) via enp6s0f1

Aug 11 02:11:56 debian1 dhcpd[925]: DHCPREQUEST for 192.168.10.53 (192.168.10.1) from 2c:4d:54:54:68:ea (kabylake1) via enp6s$

Aug 11 02:11:56 debian1 dhcpd[925]: DHCPACK on 192.168.10.53 to 2c:4d:54:54:68:ea (kabylake1) via enp6s0f1

je lance une autre machine pour confirmer , mais a priori pas besoin.
c'est correct

Aug 11 03:08:44 debian1 dhcpd[925]: DHCPDISCOVER from 60:45:cb:9a:c9:93 via enp6s0f1

Aug 11 03:08:45 debian1 dhcpd[925]: DHCPOFFER on 192.168.10.37 to 60:45:cb:9a:c9:93 (debian21) via enp6s0f1

Aug 11 03:08:45 debian1 dhcpd[925]: DHCPREQUEST for 192.168.10.37 (192.168.10.1) from 60:45:cb:9a:c9:93 (debian21) via enp6s0$

Aug 11 03:08:45 debian1 dhcpd[925]: DHCPACK on 192.168.10.37 to 60:45:cb:9a:c9:93 (debian21) via enp6s0f1

par contre j'ai bien un souci avec apparmor , pourtant j'aurais bien aimé l'utiliser .

Tu peux adapter en fonction de tes besoins les ports à autoriser.
J'ai aussi autoriser les pings. Je pense que juste mettre echo-request
suffirait car il me semble que les echo-reply font partie des paquets related
dans le suivi de connexions.
Bon, j'espère n'avoir pas fait d'erreurs…

a priori tout est correct je laisse tourner , j'ai noté mes modifications personnelles et remarques
je vais tâter de la couette
le script du #132 c'est ce qui est appliqué actuellement

Dernière modification par anonyme (11-08-2019 02:23:04)

enicar · 11-08-2019 10:40:39

anonyme a écrit :

ssh (le serveur) est interdit sur la passerelle, si il est installé c'est a l'intérieur du sous-réseau (sur une machine qui fait office de serveur ) et uniquement en local.
remplacé ssh par https

J'avais dit dans mon message que tu pouvais adapter à tes besoins, donc tu
fais ce que tu veux.

enicar · 11-08-2019 10:41:38

anonyme a écrit :

l'ordre des régles a une importance ? (ça correspond pas trop a ton exemple )

Oui l'ordre des règles a une importance. Si j'ai changé, c'est que je trouve que
c'est mieux comme ça.

enicar · 11-08-2019 10:48:10

anonyme a écrit :

j'ai des questions sur cela

ct state new tcp dport {https, smtp, domain, http, ipp, 8080} accept
ct state new udp dport {domain, bootps, ntp, ipp} accept

J'ai utilisé les noms de services qui sont dans /etc/services. On a les
correspondances suivantes :

smtp : 25 le port d'écouter d'exim
domain : 53 le port d'écoute de bind
ipp : 631 le port d'écoute de cups
bootps : 67 le port d'écoute de dhcpd
ntp : 123 le port d'écoute du serveur ntp

Le reste tu connais.

enicar · 11-08-2019 10:49:53

anonyme a écrit :

pour bootps pas utile => https://fr.wikipedia.org/wiki/Bootstrap_Protocol

Comme c'est le port utiliser par dhcpd (67), tu en as besoin ! À moins que
tu aies mis un autre port dans la conf de dhcpd.

Dernière modification par enicar (11-08-2019 10:50:30)

enicar · 11-08-2019 10:53:11

Remarque que si tu mets la policy de la chaîne input en accept, les règles
ne servent à rien, sauf celles qui drop ou reject. Toutes les règles accept
n'ont plus aucune utilité.

anonyme · 11-08-2019 11:17:57

Bonjour
non je suis bien en drop sur le serveur
je regarde cette histoire d'ordre des règles et je modifie
pour bootps je peu le laisser mais au dessus tu vois que ça fonctionne

j'ai fait un cat et un copier/coller

flush ruleset

table ip nat {

  chain PREROUTING {

    type nat hook prerouting priority -100; policy accept;

  }

  chain INPUT {

    type nat hook input priority 100; policy accept;

  }

  chain POSTROUTING {

    type nat hook postrouting priority 100; policy accept;

    oifname "enp6s0f0" masquerade

  }

  chain OUTPUT {

    type nat hook output priority -100; policy accept;

  }

}

table ip filter {

chain local_in {

    ct state new tcp dport {https, smtp, domain, http, ipp, 8080} accept

    ct state new udp dport {domain, bootps, ntp, ipp} accept

    icmp type {echo-reply, echo-request} accept

  }

  chain INPUT {

    type filter hook input priority 0; policy drop;

    ip daddr 224.0.0.0/8 reject with icmp type admin-prohibited

    iif lo accept

                udp dport {137, 138} reject

    ct state invalid  limit rate 4/second burst 5 packets  log prefix "INVALID_INPUT " drop

    ct state new ip saddr 192.168.1.2 ip daddr 192.168.1.10 udp dport 123 accept

    ct state established,related accept

    icmp type { destination-unreachable,time-exceeded, parameter-problem } accept

    ct state new ip saddr 192.168.1.2 ip daddr 192.168.1.10 udp dport 123 accept

    iifname "enp6s0f1" jump local_in

    log prefix "INPUT_DROP "

  }

  chain FORWARD {

    type filter hook forward priority 0; policy drop;

    iifname "enp6s0f1" accept

    ct state invalid  limit rate 4/second burst 5 packets  log prefix "INVALID_INPUT " drop

    ct state established,related accept

    log prefix "FORWARD_DROP "

  }

  chain OUTPUT {

    type filter hook output priority 0; policy accept;

  }

}

table ip6 filter {

  chain input {

    type filter hook input priority 0; policy drop;

    iif lo accept

    }

  chain forward {

    type filter hook forward priority 0; policy drop;

    }

  chain output {

    type filter hook output priority 0; policy drop;

    oif lo accept

    }

  }

et relancer le service

Dernière modification par anonyme (11-08-2019 12:26:51)

enicar · 11-08-2019 11:19:24

En ce qui concerne ipv6, ce n'est pas correct de tout mettre en accept.
Ce n'est pas parce que tu ne l'utilises pas qu'un virus/trojan ne peux pas
l'utiliser. Le mieux c'est de tout bloquer en entrée, sortie et en forward et
de n'autoriser le trafic que sur l'interface lo (::1) aussi bien sur la passerelle
que sur les clients. Sinon à quoi bon faire un pare-feu ?

enicar · 11-08-2019 11:20:40

anonyme a écrit :

pour bootps je peu le laisser mais au dessus tu vois que ça fonctionne

La question c'est pourquoi ? Certainement parce que tout est en accept.
Tu ne peux pas tester des règles si tu mets tout en accept…

Le port 67 est utilisé par le serveur dhcpd, et le port 68 est celui utilisé par dhclient.

Dernière modification par enicar (11-08-2019 11:21:33)

anonyme · 11-08-2019 11:30:20

non je suis en drop depuis 3 heures du matin je vais efface ce #132
en #139 tu a ce qui est appliqué
et un :

systemctl restart nftables.service

 

Dernière modification par anonyme (11-08-2019 11:34:35)

enicar · 11-08-2019 11:38:48

anonyme a écrit :

non je suis en drop depuis 3 heures du matin je vais efface ce #132
en #139 tu a ce qui est appliqué

Bon et sur la passerelle que donne :

ss -nlup

 

Pour voir quels sont les programmes qui ont une socket udp ouverte en écoute.

anonyme · 11-08-2019 11:51:46

déjà sur la passerelle

Aug 11 12:47:46 debian1 kernel: [45510.000328] INPUT_DROP IN=enp6s0f0 OUT= MAC=ff:ff:ff:ff:ff:ff:a4:3e:51:5b:f9:1b:08:00 

SRC=192.168.1.1 DST=192.168.1.255 LEN=236 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=138 DPT=138 LEN=216 

Aug 11 12:47:46 debian1 kernel: [45510.000483] INPUT_DROP IN=enp6s0f0 OUT= MAC=ff:ff:ff:ff:ff:ff:a4:3e:51:5b:f9:1b:08:00 

SRC=192.168.1.1 DST=192.168.1.255 LEN=236 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=138 DPT=138 LEN=216

State           Recv-Q          Send-Q                     Local Address:Port                      Peer Address:Port                                                                                                                                        

UNCONN          0               0                                0.0.0.0:57263                          0.0.0.0:*              users:(("dhcpd",pid=925,fd=20))                                                                                              

UNCONN          0               0                           192.168.10.1:53                             0.0.0.0:*              users:(("named",pid=823,fd=533),("named",pid=823,fd=532),("named",pid=823,fd=531),("named",pid=823,fd=530),("named",pid=823,fd=529),("named",pid=823,fd=528),("named",pid=823,fd=527),("named",pid=823,fd=526),("named",pid=823,fd=525),("named",pid=823,fd=524),("named",pid=823,fd=523))

UNCONN          0               0                              127.0.0.1:53                             0.0.0.0:*              users:(("named",pid=823,fd=522),("named",pid=823,fd=521),("named",pid=823,fd=520),("named",pid=823,fd=519),("named",pid=823,fd=518),("named",pid=823,fd=517),("named",pid=823,fd=516),("named",pid=823,fd=515),("named",pid=823,fd=514),("named",pid=823,fd=513),("named",pid=823,fd=512))

UNCONN          0               0                                0.0.0.0:67                             0.0.0.0:*              users:(("dhcpd",pid=925,fd=8))                                                                                               

UNCONN          0               0                           192.168.1.10:123                            0.0.0.0:*              users:(("ntpd",pid=802,fd=8))                                                                                                

UNCONN          0               0                           192.168.10.1:123                            0.0.0.0:*              users:(("ntpd",pid=802,fd=7))                                                                                                

UNCONN          0               0                              127.0.0.1:123                            0.0.0.0:*              users:(("ntpd",pid=802,fd=6))                                                                                                

UNCONN          0               0                                   [::]:38182                             [::]:*              users:(("dhcpd",pid=925,fd=21))

le PC de mon fils ?
=> https://fr.wikipedia.org/wiki/NetBIOS (mon poste windows est éteint.
et samba difficile de le purger

Dernière modification par anonyme (11-08-2019 12:13:23)

enicar · 11-08-2019 11:54:32

anonyme a écrit :

déjà sur la passerelle

Bon, on sait ce que c'est, SRC=192.168.1.1 indique que c'est la livebox
qui cherche du netbios et compagnie.

enicar · 11-08-2019 12:00:51

On voit que dhcpd écoute sur toute les adresses ipv4 (0.0.0.0) sur le port 67
et 57263 et sur toutes les adresses en ipv6 ([::]) sur le port 38182.
Je ne comprends pas pourquoi il utilise d'autres ports que le 67. Ceci dit
je n'ai jamais utilisé dhcpd.

anonyme · 11-08-2019 12:01:48

et ça la live aussi

Aug 11 12:34:31 debian1 kernel: [44715.318135] INPUT_DROP IN=enp6s0f1 OUT= MAC= SRC=192.168.10.1 

DST=192.168.10.255 LEN=78 TOS=0x00 PREC=0x00 TTL=64 ID=61556 DF PROTO=UDP SPT=42537 DPT=137 LEN=58

Dernière modification par anonyme (11-08-2019 12:06:28)

enicar · 11-08-2019 12:06:22

anonyme a écrit :

et ça la live aussi

Même chose que précédemment, le port destination est 137…
C'est pour ça que j'avais proposé de rajouter :

udp dport {137, 138} reject

 

dans la chaîne input de la table ip filter.
Ça permet de ne plus voir ces messages, tout en gardant les logs
désignés par "INPUT_DROP".

Dernière modification par enicar (11-08-2019 12:12:46)

anonyme · 11-08-2019 12:15:23

un sur enp6s0f0 et 192.168.1.1
un sur enp6s0f1 et 192.168.10.1

apt-get -s remove --purge libwbclient0

Lecture des listes de paquets... Fait

Construction de l'arbre des dépendances       

Lecture des informations d'état... Fait

Les paquets suivants ont été installés automatiquement et ne sont plus nécessaires :

  albatross-gtk-theme blackbird-gtk-theme bluebird-gtk-theme fonts-cantarell greybird-gtk-theme gtk2-engines

  gtk2-engines-murrine libcdio-cdda2 libcdio-paranoia2 libcdio18 libgdata-common libgdata22 libgoa-1.0-0b libgoa-1.0-common

  libldb1 libmate-slab0 libmate-window-settings1 libmtp-common libmtp-runtime libmtp9 libnfs12 liboauth0 libtalloc2

  libtevent0 mate-control-center mate-control-center-common mate-icon-theme mate-themes murrine-themes python-talloc

Veuillez utiliser « apt autoremove » pour les supprimer.

Les paquets suivants seront ENLEVÉS :

  gvfs-backends* libsmbclient* libwbclient0* mate-core* mate-desktop-environment-core* samba-libs*

0 mis à jour, 0 nouvellement installés, 6 à enlever et 0 non mis à jour.

pour me débarrasser de samba ça va pas être simple , sinon pas de bureau pas viable
j'ai juste 3 paquets pour le client samba qui ne peuvent pas être enlevé sans casser Mate

Dernière modification par anonyme (11-08-2019 12:21:18)

enicar · 11-08-2019 12:20:55

anonyme a écrit :

un sur enp6s0f0 et 192.168.1.1
un sur enp6s0f1 et 192.168.10.1

Un quoi ?
Si tu mets la règle que j'ai proposé en #148 globalement sur la chaîne input
la règle sera prise en compte globalement sur toutes les interfaces.
Par exemple, ce serait bien de mettre cette règle après « iif lo accept ».
Sur l'interface « lo » on autorise tout, c'est plus simple comme ça.

Debian-facile

#126 09-08-2019 18:29:11

Re : [resolu]Migration de iptables a nftables sur une passerelle

#127 09-08-2019 18:33:46

Re : [resolu]Migration de iptables a nftables sur une passerelle

#128 10-08-2019 12:16:40

Re : [resolu]Migration de iptables a nftables sur une passerelle

#129 10-08-2019 14:42:41

Re : [resolu]Migration de iptables a nftables sur une passerelle

#130 10-08-2019 14:44:43

Re : [resolu]Migration de iptables a nftables sur une passerelle

#131 10-08-2019 19:45:31

Re : [resolu]Migration de iptables a nftables sur une passerelle

#132 11-08-2019 00:43:05

Re : [resolu]Migration de iptables a nftables sur une passerelle

#133 11-08-2019 00:58:03

Re : [resolu]Migration de iptables a nftables sur une passerelle

#134 11-08-2019 10:40:39

Re : [resolu]Migration de iptables a nftables sur une passerelle

#135 11-08-2019 10:41:38

Re : [resolu]Migration de iptables a nftables sur une passerelle

#136 11-08-2019 10:48:10

Re : [resolu]Migration de iptables a nftables sur une passerelle

#137 11-08-2019 10:49:53

Re : [resolu]Migration de iptables a nftables sur une passerelle

#138 11-08-2019 10:53:11

Re : [resolu]Migration de iptables a nftables sur une passerelle

#139 11-08-2019 11:17:57

Re : [resolu]Migration de iptables a nftables sur une passerelle

#140 11-08-2019 11:19:24

Re : [resolu]Migration de iptables a nftables sur une passerelle

#141 11-08-2019 11:20:40

Re : [resolu]Migration de iptables a nftables sur une passerelle

#142 11-08-2019 11:30:20

Re : [resolu]Migration de iptables a nftables sur une passerelle

#143 11-08-2019 11:38:48

Re : [resolu]Migration de iptables a nftables sur une passerelle

#144 11-08-2019 11:51:46

Re : [resolu]Migration de iptables a nftables sur une passerelle

#145 11-08-2019 11:54:32

Re : [resolu]Migration de iptables a nftables sur une passerelle

#146 11-08-2019 12:00:51

Re : [resolu]Migration de iptables a nftables sur une passerelle

#147 11-08-2019 12:01:48

Re : [resolu]Migration de iptables a nftables sur une passerelle

#148 11-08-2019 12:06:22

Re : [resolu]Migration de iptables a nftables sur une passerelle

#149 11-08-2019 12:15:23

Re : [resolu]Migration de iptables a nftables sur une passerelle

#150 11-08-2019 12:20:55

Re : [resolu]Migration de iptables a nftables sur une passerelle

Pied de page des forums