logo Debian Debian Debian-France Debian-Facile Debian-fr.org Forum-Debian.fr Debian ? Communautés logo inclusivité

Debian-facile

Bienvenue sur Debian-Facile, site d'aide pour les nouveaux utilisateurs de Debian.

Vous n'êtes pas identifié(e).

#51 06-08-2019 18:23:56

enicar
Membre
Lieu : pas ici
Distrib. : sid
Noyau : Linux 6.5.3
(G)UI : openbox
Inscription : 26-08-2010

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

Un autre truc auquel je pense en passant, tu es sûr que sur la passerelle, bind écoute bien
sur l'interface enps6s0f1, c'est à dire l'adresse 192.168.10.1 ?
Pour le voir tu peux faire :


ss -nlutp
 

Hors ligne

#52 06-08-2019 18:27:30

anonyme
Invité

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

c'est pas gentil de te moquer roll hmm  tongue   lol
je sais pas ce qu il trafique mais impressionnant les requêtes DNS qu'il fait ..........
bind9 avec debian il s' ennuie un peu tongue  , j'ai pourtant la météo sur tout les clients wink

sur le client


ss -nlutp
Netid          State            Recv-Q           Send-Q                     Local Address:Port                     Peer Address:Port                                                          
udp            UNCONN           0                0                                0.0.0.0:68                            0.0.0.0:*              users:(("dhclient",pid=623,fd=7))              
udp            UNCONN           0                0                                0.0.0.0:631                           0.0.0.0:*              users:(("cups-browsed",pid=644,fd=7))          
tcp            LISTEN           0                5                              127.0.0.1:631                           0.0.0.0:*              users:(("cupsd",pid=642,fd=8))                
tcp            LISTEN           0                20                             127.0.0.1:25                            0.0.0.0:*              users:(("exim4",pid=1401,fd=3))                
tcp            LISTEN           0                5                                  [::1]:631                              [::]:*              users:(("cupsd",pid=642,fd=7))  
 



ps: oublié exim4 , le port 25 a ouvrir
je passe sur le serveur ( il est parfait mon sous-réseau local tongue  wink  )

voila sur le serveur


su -
Mot de passe :
root@debian1:~# ss -nlutp
Netid        State         Recv-Q         Send-Q                 Local Address:Port                  Peer Address:Port                                                                                                                                      
udp          UNCONN        0              0                            0.0.0.0:20341                      0.0.0.0:*            users:(("dhcpd",pid=877,fd=20))                                                                                              
udp          UNCONN        0              0                       192.168.10.1:53                         0.0.0.0:*            users:(("named",pid=777,fd=533),("named",pid=777,fd=532),("named",pid=777,fd=531),("named",pid=777,fd=530),("named",pid=777,fd=529),("named",pid=777,fd=528),("named",pid=777,fd=527),("named",pid=777,fd=526),("named",pid=777,fd=525),("named",pid=777,fd=524),("named",pid=777,fd=523))
udp          UNCONN        0              0                          127.0.0.1:53                         0.0.0.0:*            users:(("named",pid=777,fd=522),("named",pid=777,fd=521),("named",pid=777,fd=520),("named",pid=777,fd=519),("named",pid=777,fd=518),("named",pid=777,fd=517),("named",pid=777,fd=516),("named",pid=777,fd=515),("named",pid=777,fd=514),("named",pid=777,fd=513),("named",pid=777,fd=512))
udp          UNCONN        0              0                            0.0.0.0:67                         0.0.0.0:*            users:(("dhcpd",pid=877,fd=8))                                                                                              
udp          UNCONN        0              0                       192.168.10.1:123                        0.0.0.0:*            users:(("ntpd",pid=755,fd=7))                                                                                                
udp          UNCONN        0              0                          127.0.0.1:123                        0.0.0.0:*            users:(("ntpd",pid=755,fd=6))                                                                                                
udp          UNCONN        0              0                               [::]:50348                         [::]:*            users:(("dhcpd",pid=877,fd=21))                                                                                              
tcp          LISTEN        0              128                          0.0.0.0:36330                      0.0.0.0:*            users:(("FAHClient",pid=894,fd=21))                                                                                          
tcp          LISTEN        0              10                      192.168.10.1:53                         0.0.0.0:*            users:(("named",pid=777,fd=22))                                                                                              
tcp          LISTEN        0              10                         127.0.0.1:53                         0.0.0.0:*            users:(("named",pid=777,fd=21))                                                                                              
tcp          LISTEN        0              20                      192.168.10.1:25                         0.0.0.0:*            users:(("exim4",pid=1154,fd=4))                                                                                              
tcp          LISTEN        0              20                         127.0.0.1:25                         0.0.0.0:*            users:(("exim4",pid=1154,fd=3))                                                                                              
tcp          LISTEN        0              128                        127.0.0.1:953                        0.0.0.0:*            users:(("named",pid=777,fd=23))                                                                                              
tcp          LISTEN        0              128                          0.0.0.0:7396                       0.0.0.0:*            users:(("FAHClient",pid=894,fd=20))                                                                                          
tcp          LISTEN        0              128                            [::1]:953                           [::]:*            users:(("named",pid=777,fd=24))
 


FAH est un utilitaire de calcul scientifique , il est inactif actuellement , il utilise la boucle locale et le port 80 , 8080 et les IP externes sont aléatoire selon le serveur utilisé
rien d'inquiétant
voilà

Dernière modification par anonyme (06-08-2019 18:41:04)

#53 06-08-2019 18:32:51

enicar
Membre
Lieu : pas ici
Distrib. : sid
Noyau : Linux 6.5.3
(G)UI : openbox
Inscription : 26-08-2010

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

anonyme a écrit :

sur le client


Ben c'était pour voir si bind écoutait sur l'adresse 192.168.10.1, sur la passerelle
que tu appelles serveur…

Hors ligne

#54 06-08-2019 18:34:32

enicar
Membre
Lieu : pas ici
Distrib. : sid
Noyau : Linux 6.5.3
(G)UI : openbox
Inscription : 26-08-2010

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

Mais bon tu m'a montré ce que tu voulais avec tous ces ping ? C'est ça ?

Hors ligne

#55 06-08-2019 18:47:26

enicar
Membre
Lieu : pas ici
Distrib. : sid
Noyau : Linux 6.5.3
(G)UI : openbox
Inscription : 26-08-2010

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

En tous cas, bind fonctionne correctement. Le DNS devrait fonctionner.

Hors ligne

#56 06-08-2019 18:49:13

enicar
Membre
Lieu : pas ici
Distrib. : sid
Noyau : Linux 6.5.3
(G)UI : openbox
Inscription : 26-08-2010

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

Et du coup je ne sais plus ce qui ne va pas… Il faudrait montrer la configuration
du pare-feu avec laquelle tu as eu des pings fonctionnels.

Hors ligne

#57 06-08-2019 18:50:58

anonyme
Invité

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

je pense que le filtrage sur enp6s0f0  doit être sérieux (surtout en input)
sur enp6s0f1 plus permisif (input et output)
je sais pas si possible.
oui je te montre ce qui fonctionne actuellement
par exemple un ping par nom c'est pratique , savoir que la machine est allumé et répond.
que n'importe quelle  machine qui se connecte en cable se configure automatiquement et a un accès au net
ps: les petit raspberry comme le PI3 , pas de wifi pour l'instant , mais le wifi 6 arrive , on trouve déjà module M2 wifi et routeur. (avec le WPA3 qui a été déjà craqué tongue )

#58 06-08-2019 18:59:23

anonyme
Invité

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

enicar a écrit :

Et du coup je ne sais plus ce qui ne va pas… Il faudrait montrer la configuration
du pare-feu avec laquelle tu as eu des pings fonctionnels.



le #41 , le nftables.conf  en permisif (accept)
ce qui y a actuellement sur le serveur
ce qui manque fais planter nft
par exemple du syslog


Aug  6 17:15:58 debian1 systemd[1]: Starting nftables...
Aug  6 17:15:58 debian1 nft[1614]: /etc/nftables.conf:25:21-25: Error: syntax error, unexpected dport
Aug  6 17:15:58 debian1 nft[1614]: #011#011upd dport 53 accept
Aug  6 17:15:58 debian1 nft[1614]: #011#011                  ^^^^^
Aug  6 17:15:58 debian1 systemd[1]: nftables.service: Main process exited, code=exited, status=1/FAILURE
Aug  6 17:15:58 debian1 systemd[1]: nftables.service: Failed with result 'exit-code'.
Aug  6 17:15:58 debian1 systemd[1]: Failed to start nftables.
Aug  6 17:17:01 debian1 CRON[1621]: (root) CMD (   cd / && run-parts --report /etc/cron.hourly)
Aug  6 17:17:18 debian1 systemd[1]: Starting nftables...
Aug  6 17:17:19 debian1 nft[1625]: /etc/nftables.conf:24:21-25: Error: syntax error, unexpected dport
Aug  6 17:17:19 debian1 nft[1625]: #011#011upd dport 53 accept
Aug  6 17:17:19 debian1 nft[1625]: #011#011                  ^^^^^
Aug  6 17:17:19 debian1 systemd[1]: nftables.service: Main process exited, code=exited, status=1/FAILURE
Aug  6 17:17:19 debian1 systemd[1]: nftables.service: Failed with result 'exit-code'.
Aug  6 17:17:19 debian1 systemd[1]: Failed to start nftables.
Aug  6 17:18:08 debian1 systemd[1]: Starting nftables...
Aug  6 17:18:09 debian1 nft[1633]: /etc/nftables.conf:24:21-25: Error: syntax error, unexpected dport
Aug  6 17:18:09 debian1 nft[1633]: #011#011upd dport 53 accept
Aug  6 17:18:09 debian1 nft[1633]: #011#011                  ^^^^^
Aug  6 17:18:09 debian1 systemd[1]: nftables.service: Main process exited, code=exited, status=1/FAILURE
Aug  6 17:18:09 debian1 systemd[1]: nftables.service: Failed with result 'exit-code'.
Aug  6 17:18:09 debian1 systemd[1]: Failed to start nftables.
Aug  6 17:18:39 debian1 systemd[1]: Starting nftables...
Aug  6 17:18:39 debian1 nft[1637]: /etc/nftables.conf:24:21-25: Error: syntax error, unexpected dport
Aug  6 17:18:39 debian1 nft[1637]: #011#011upd dport 53 accept
Aug  6 17:18:39 debian1 nft[1637]: #011#011                  ^^^^^
Aug  6 17:18:39 debian1 systemd[1]: nftables.service: Main process exited, code=exited, status=1/FAILURE
Aug  6 17:18:39 debian1 systemd[1]: nftables.service: Failed with result 'exit-code'.
Aug  6 17:18:39 debian1 systemd[1]: Failed to start nftables.
 



bon on fait une pause pour ce soir , j'ai bien avancé quand même
il fait très chaud chez moi   hmm
coffeecup.gif

Dernière modification par anonyme (06-08-2019 19:05:41)

#59 06-08-2019 19:24:25

enicar
Membre
Lieu : pas ici
Distrib. : sid
Noyau : Linux 6.5.3
(G)UI : openbox
Inscription : 26-08-2010

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

anonyme a écrit :

je pense que le filtrage sur enp6s0f0  doit être sérieux (surtout en input)
sur enp6s0f1 plus permisif (input et output)
je sais pas si possible.


Tout est possible. Mais il faut savoir ce que tu veux.
Pour avoir quelque chose permissif sur l'interface enp6s0f1, c'est facile :


table ip filter {
    chain input {
        type filter hook input priority 0; policy drop;
        iif lo accept
        iifname "enps6s0f1" 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
        log
    }

    chain forward {
        type filter hook forward priority 0; policy drop;
        iifname "enps6s0f1" accept
        ct state invalid  limit rate 4/second burst 5 packets  log prefix "INVALID_INPUT " drop
        ct state established,related accept
        log
    }

    chain output {
        type filter hook output priority 0; policy accept;
    }
}

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;
    }
}
 


J'ai passé tous les noms des chaînes en minuscules (ça fait partie des choses
que j'ai toujours détesté dans iptables, ça est les -- à tout bout de champ).

J'ai juste autorisé toutes les connexions sur la passerelle sur l'interface
enp6s0f1, et sur l'autre interface il y a juste le suivis de connexion en
entrée et quelques messages icmp nécessaires. En sortie tout est autorisé.
Pour le forward, c'est à dire les flux qui ne sont pas à destination de la
passerelle, on autorise seulement les paquets qui proviennent de enp6s0f1,
le reste c'est le contrack qui le fait. Pour le nat je n'ai rien
changé.

Il faut évidemment activer l'ip forwarding, mais tu l'avais déjà fait.

Hors ligne

#60 06-08-2019 19:27:18

enicar
Membre
Lieu : pas ici
Distrib. : sid
Noyau : Linux 6.5.3
(G)UI : openbox
Inscription : 26-08-2010

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

anonyme a écrit :

le #41 , le nftables.conf  en permisif (accept)
ce qui y a actuellement sur le serveur
ce qui manque fais planter nft
par exemple du syslog


Oui je m'étais trompé, j'avais écrit « upd » au lieu de « udp », et avec
nftables quand il te dit qu'il ne comprend pas un mot, il faut regarder
celui qui le précède wink

Hors ligne

#61 07-08-2019 00:18:13

anonyme
Invité

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

corrigé l'erreur , idem ça bloque , mais plus de problème sur nftables
voici un retour dans /var/log/syslog
juste un bout de la ligne , le client 192.168.10.47 a le net


=192.168.10.47 DST=2.22.112.82 LEN=60 TOS=0x00 PREC=0x00 TTL=63 ID=23691 DF PROTO=TCP SPT=54884 DPT=80 WINDOW=29200
 


voici le nftables.conf


table ip filter {

        chain INPUT {
                type filter hook input priority 0; policy accept;
                iif lo accept
                iifname "enps6s0f1" 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
                icmp type { echo-request, echo-reply } accept
                log
        }

        chain FORWARD {
                type filter hook forward priority 0; policy accept;
                iifname "enps6s0f1" accept
                ct state invalid  limit rate 4/second burst 5 packets  log prefix "INVALID_INPUT " drop
                ct state established,related accept
                log
        }

        chain OUTPUT {
                type filter hook output priority 0; policy accept;
        }
}
 


si je passe le "chain INPUT" a "drop" plus le net (du moins le forum)
par contre j'ai des logs sur le syslog maintenant
par contre avec "accept" toutes les lignes derrière ne sont plus utile a par peut être "log"

#62 07-08-2019 11:17:17

enicar
Membre
Lieu : pas ici
Distrib. : sid
Noyau : Linux 6.5.3
(G)UI : openbox
Inscription : 26-08-2010

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

anonyme a écrit :

si je passe le "chain INPUT" a "drop" plus le net (du moins le forum)
par contre j'ai des logs sur le syslog maintenant
par contre avec "accept" toutes les lignes derrière ne sont plus utile a par peut être "log"


Oui mais non, il faut mettre la policy à drop pour les chaînes input et forward.
De plus, « ça marche pas » ne m'aide pas du tout comme diagnostique.
Il faudrait voir les logs quand la policy est drop.

Edit : J'ai encore fait une erreur de frappe.
Il fallait écrire « enp6s0f1 » et non « enps6s0f1 » comme je l'ai fait.
Le bon devrait être :


flush ruleset

table ip filter {
    chain input {
        type filter hook input priority 0; policy drop;
        iif lo accept
        ct state invalid  limit rate 4/second burst 5 packets  log prefix "INPUT_INVALID " drop
        ct state established,related accept
        iifname "enp6s0f1" accept
        icmp type { destination-unreachable,time-exceeded, parameter-problem } accept
        log prefix "INPUT_DROP "
    }

    chain forward {
        type filter hook forward priority 0; policy drop;
        ct state invalid  limit rate 4/second burst 5 packets  log prefix "FORWARD_INVALID " drop
        ct state established,related accept
        iifname "enp6s0f1" accept
        log prefix "FORWARD_DROP "
    }

    chain output {
        type filter hook output priority 0; policy accept;
    }
}

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;
    }
}
 


Voilà ce que c'est de ne pas savoir copier correctement un nom tongue

Dernière modification par enicar (07-08-2019 12:06:12)

Hors ligne

#63 07-08-2019 12:42:07

anonyme
Invité

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

Bonjour
voila sur le client (raven-2200g) la règle que j'ai appliqué (donc une seule carte réseau)


#!/usr/sbin/nft -f

flush ruleset

table ip filter {
        chain input {
                type filter hook input priority 0; policy drop;
                iif lo accept
                ct state established,related accept
        }

        chain forward {
                 type filter hook forward priority filter; policy accept;
        }

        chain output {
                type filter hook output priority 0; policy accept;
        }
}
 


j'ai le net (forum) , un ping de google fonctionne
la première cause de soucis c'est l'utilisateur (moi en autre ).
je pense que je vais repartir de zéro et sur la machine cliente (une seule carte réseau) pour commencer
pour que l'on parle de la même chose
input => ce qui vient de la passerelle
output => ce qui sort du client
forward => jamais compris la nuance
ps: pour la passerelle je suppose un input coté net et un input coté sous-réseau.
il me semble raisonnable de bloquer uniquement dans un premier temps , le input drop (forward et output en accept).
et stop les copier/coller roll
je sais pas ce que tu en pense ? , effacer ma chain actuel , recréer une chain IP.
créer mes règles

j'ai trouvé ceci


Lors de l'ajout d'une chaîne au point d'entrée, il est obligatoire de spécifier le périphérique auquel la chaîne sera attachée:
 


mais


nft add chain netdev foo dev0filter { type filter hook ingress device enp6s0 priority 0 \; }
 



Error: No such file or directory
add chain netdev foo dev0filter { type filter hook ingress device enp6s0 priority 0 ; }
                 ^^^
 


voila le résultat quand on comprend pas ce que l'on fait  roll

pour revenir a nftables.conf ci dessus , sur input , la boucle locale est en "accept"
ce qui sort , la réponse en entrée est accepté , le reste est bloqué
pour les ping pour l'instant ils sont autorisé en sortie , pas en entrée . (je le teste , c'est exact)

Dernière modification par anonyme (07-08-2019 12:43:34)

#64 07-08-2019 12:58:24

anonyme
Invité

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

j'ai fait la correction du nom sur la passerelle , j'ai le net du client avec "input drop" sur le serveur
je peu tester de passer "forward" aussi en drop
ps: c'est a moi de corriger ce genre d'erreur  roll

pour ceci


De plus, « ça marche pas » ne m'aide pas du tout comme diagnostique.
 


d'accord avec toi mais il était tard ou très tôt , comme tu préfère  tongue

sur la passerelle pas exactement le même que toi (en #62) , faut que je mette a jour

#65 07-08-2019 13:14:12

enicar
Membre
Lieu : pas ici
Distrib. : sid
Noyau : Linux 6.5.3
(G)UI : openbox
Inscription : 26-08-2010

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

anonyme a écrit :

input => ce qui vient de la passerelle
output => ce qui sort du client
forward => jamais compris la nuance



Forward, input, output se réfère à la machine sur laquelle on est.

Les paquets dans la chaîne input de la table filter sont les paquets
qui sont à destination de cette machine peu importe l'interface d'entrée.
Pour être concret, pour ta passerelle, les paquets qui sont à destination
de 192.168.1.10 et 192.168.10.1 passent dans la chain input de la passerelle.

La chaîne output de la table filter concerne les paquets qui ont été générés
par un processus de la passerelle, donc ils ont comme source 192.168.1.10 ou
192.168.10.1, tout dépend de la destination, c'est le routage qui décide.

La chaîne forward de la table filter concerne les paquets qui ne sont pas à destination
de la passerelle mais qui passe par elle (comme ceux que tu envoies lorsque tu vas sur le
forum ou ceux qui reviennent vers toi depuis le forum). Par exemple sur
les clients il devraient rien passer dans la chaîne forward. D'ailleurs sur ces machines
l'ip forwarding n'est pas activé.

La chose importante c'est que les paquets ne peuvent pas passer par les deux chaînes,
c'est input ou forward.


Du temps des noyaux 2.2 ce  n'était pas comme ça, hormis le fait qu'il n'y avait pas
de table, tous les paquets qui passaient par la machine, traversaient la chaîne input.
Ceux qui faisaient juste que traversaient la machine passaient aussi dans forward.
Du coup, c'était très pénible à configurer, il fallait dupliquer les règles de forward dans
input ou un truc dans le genre.  Ça faisait double emploi. Ce que je faisais, c'est que je
bloquais les paquets en input, et j'utilisais la masquerade dans le forward (il n'y avait pas
de nat à l'époque).

Ce qu'il faut retenir c'est ce que input, output et forward sont relatifs à la machine
sur laquelle on se trouve.

anonyme a écrit :

je sais pas ce que tu en pense ?


Je pense que tu peux essayer ce que j'ai proposé pour la passerelle en #62.
C'est une configuration minimale qui permet de tout autoriser depuis
le réseau local, mais interdit tout connexion dans l'autre sens.
Aussi, il faut bien préciser quelle est la machine concernée quand tu parles
d'input, d'output ou de forward.

Hors ligne

#66 07-08-2019 13:15:02

anonyme
Invité

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

voila celui en place
testé du client , le forum , un ping de la passerelle ça fonctionne


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;
    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
    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;
  }
}
 


actuellement on a un drop sur "enp6s0f0" et accept sur "enp6s0f1" ?

#67 07-08-2019 13:16:52

enicar
Membre
Lieu : pas ici
Distrib. : sid
Noyau : Linux 6.5.3
(G)UI : openbox
Inscription : 26-08-2010

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

anonyme a écrit :

actuellement on a un drop sur "enp6s0f0" et accept sur "enp6s0f1" ?


En effet.

Edit : Mais as-tu compris pourquoi ?

Dernière modification par enicar (07-08-2019 13:20:06)

Hors ligne

#68 07-08-2019 13:30:12

anonyme
Invité

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

le log


Aug  7 14:06:38 debian1 systemd[1]: Started nftables.
Aug  7 14:06:39 debian1 kernel: [45873.373711] INPUT_DROP IN=enp6s0f0 OUT= MAC=01:00:5e:00:00:01:a4:3e:51:5b:f9:1b:08:00 SRC=192.168.1.1 DST=224.0.0.1 LEN=32 TOS=0x00 PREC=0x80 TTL=1 ID=0 DF PROTO=2
Aug  7 14:06:55 debian1 kernel: [45889.758245] INPUT_DROP IN=enp6s0f0 OUT= MAC=bc:ee:7b:1c:c6:93:a0:63:91:7e:ec:fa:08:00 SRC=192.168.1.2 DST=192.168.1.10 LEN=76 TOS=0x00 PREC=0x00 TTL=64 ID=13668 PROTO=UDP SPT=1024 DPT=123 LEN=56
Aug  7 14:07:19 debian1 kernel: [45913.371094] INPUT_DROP IN=enp6s0f0 OUT= MAC=01:00:5e:00:00:01:a4:3e:51:5b:f9:1b:08:00 SRC=192.168.1.1 DST=224.0.0.1 LEN=32 TOS=0x00 PREC=0x80 TTL=1 ID=0 DF PROTO=2
Aug  7 14:07:59 debian1 kernel: [45953.368461] INPUT_DROP IN=enp6s0f0 OUT= MAC=01:00:5e:00:00:01:a4:3e:51:5b:f9:1b:08:00 SRC=192.168.1.1 DST=224.0.0.1 LEN=32 TOS=0x00 PREC=0x80 TTL=1 ID=0 DF PROTO=2
Aug  7 14:08:05 debian1 kernel: [45958.786494] INPUT_DROP IN=enp6s0f0 OUT= MAC=bc:ee:7b:1c:c6:93:a0:63:91:7e:ec:fa:08:00 SRC=192.168.1.2 DST=192.168.1.10 LEN=76 TOS=0x00 PREC=0x00 TTL=64 ID=13669 PROTO=UDP SPT=1024 DPT=123 LEN=56
Aug  7 14:08:39 debian1 kernel: [45993.365896] INPUT_DROP IN=enp6s0f0 OUT= MAC=01:00:5e:00:00:01:a4:3e:51:5b:f9:1b:08:00 SRC=192.168.1.1 DST=224.0.0.1 LEN=32 TOS=0x00 PREC=0x80 TTL=1 ID=0 DF PROTO=2
Aug  7 14:09:14 debian1 kernel: [46027.818608] INPUT_DROP IN=enp6s0f0 OUT= MAC=bc:ee:7b:1c:c6:93:a0:63:91:7e:ec:fa:08:00 SRC=192.168.1.2 DST=192.168.1.10 LEN=76 TOS=0x00 PREC=0x00 TTL=64 ID=13670 PROTO=UDP SPT=1024 DPT=123 LEN=56
Aug  7 14:09:19 debian1 kernel: [46033.363259] INPUT_DROP IN=enp6s0f0 OUT= MAC=01:00:5e:00:00:01:a4:3e:51:5b:f9:1b:08:00 SRC=192.168.1.1 DST=224.0.0.1 LEN=32 TOS=0x00 PREC=0x80 TTL=1 ID=0 DF PROTO=2
Aug  7 14:09:59 debian1 kernel: [46073.360714] INPUT_DROP IN=enp6s0f0 OUT= MAC=01:00:5e:00:00:01:a4:3e:51:5b:f9:1b:08:00 SRC=192.168.1.1 DST=224.0.0.1 LEN=32 TOS=0x00 PREC=0x80 TTL=1 ID=0 DF PROTO=2
Aug  7 14:10:23 debian1 kernel: [46096.844654] INPUT_DROP IN=enp6s0f0 OUT= MAC=bc:ee:7b:1c:c6:93:a0:63:91:7e:ec:fa:08:00 SRC=192.168.1.2 DST=192.168.1.10 LEN=76 TOS=0x00 PREC=0x00 TTL=64 ID=13671 PROTO=UDP SPT=1024 DPT=123 LEN=56
Aug  7 14:10:39 debian1 kernel: [46113.358142] INPUT_DROP IN=enp6s0f0 OUT= MAC=01:00:5e:00:00:01:a4:3e:51:5b:f9:1b:08:00 SRC=192.168.1.1 DST=224.0.0.1 LEN=32 TOS=0x00 PREC=0x80 TTL=1 ID=0 DF PROTO=2
Aug  7 14:11:19 debian1 kernel: [46153.355483] INPUT_DROP IN=enp6s0f0 OUT= MAC=01:00:5e:00:00:01:a4:3e:51:5b:f9:1b:08:00 SRC=192.168.1.1 DST=224.0.0.1 LEN=32 TOS=0x00 PREC=0x80 TTL=1 ID=0 DF PROTO=2
Aug  7 14:11:32 debian1 kernel: [46165.873669] INPUT_DROP IN=enp6s0f0 OUT= MAC=bc:ee:7b:1c:c6:93:a0:63:91:7e:ec:fa:08:00 SRC=192.168.1.2 DST=192.168.1.10 LEN=76 TOS=0x00 PREC=0x00 TTL=64 ID=13672 PROTO=UDP SPT=1024 DPT=123 LEN=56
Aug  7 14:11:59 debian1 kernel: [46193.353447] INPUT_DROP IN=enp6s0f0 OUT= MAC=01:00:5e:00:00:01:a4:3e:51:5b:f9:1b:08:00 SRC=192.168.1.1 DST=224.0.0.1 LEN=32 TOS=0x00 PREC=0x80 TTL=1 ID=0 DF PROTO=2
Aug  7 14:12:39 debian1 kernel: [46233.350275] INPUT_DROP IN=enp6s0f0 OUT= MAC=01:00:5e:00:00:01:a4:3e:51:5b:f9:1b:08:00 SRC=192.168.1.1 DST=224.0.0.1 LEN=32 TOS=0x00 PREC=0x80 TTL=1 ID=0 DF PROTO=2
Aug  7 14:12:41 debian1 kernel: [46234.902557] INPUT_DROP IN=enp6s0f0 OUT= MAC=bc:ee:7b:1c:c6:93:a0:63:91:7e:ec:fa:08:00 SRC=192.168.1.2 DST=192.168.1.10 LEN=76 TOS=0x00 PREC=0x00 TTL=64 ID=13673 PROTO=UDP SPT=1024 DPT=123 LEN=56
Aug  7 14:13:19 debian1 kernel: [46273.347744] INPUT_DROP IN=enp6s0f0 OUT= MAC=01:00:5e:00:00:01:a4:3e:51:5b:f9:1b:08:00 SRC=192.168.1.1 DST=224.0.0.1 LEN=32 TOS=0x00 PREC=0x80 TTL=1 ID=0 DF PROTO=2
Aug  7 14:13:50 debian1 kernel: [46303.931515] INPUT_DROP IN=enp6s0f0 OUT= MAC=bc:ee:7b:1c:c6:93:a0:63:91:7e:ec:fa:08:00 SRC=192.168.1.2 DST=192.168.1.10 LEN=76 TOS=0x00 PREC=0x00 TTL=64 ID=13674 PROTO=UDP SPT=1024 DPT=123 LEN=56
Aug  7 14:13:59 debian1 kernel: [46313.345021] INPUT_DROP IN=enp6s0f0 OUT= MAC=01:00:5e:00:00:01:a4:3e:51:5b:f9:1b:08:00 SRC=192.168.1.1 DST=224.0.0.1 LEN=32 TOS=0x00 PREC=0x80 TTL=1 ID=0 DF PROTO=2
Aug  7 14:14:14 debian1 kernel: [46328.434347] 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  7 14:14:14 debian1 kernel: [46328.434505] 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  7 14:14:39 debian1 kernel: [46353.342556] INPUT_DROP IN=enp6s0f0 OUT= MAC=01:00:5e:00:00:01:a4:3e:51:5b:f9:1b:08:00 SRC=192.168.1.1 DST=224.0.0.1 LEN=32 TOS=0x00 PREC=0x80 TTL=1 ID=0 DF PROTO=2
Aug  7 14:14:59 debian1 kernel: [46372.960585] INPUT_DROP IN=enp6s0f0 OUT= MAC=bc:ee:7b:1c:c6:93:a0:63:91:7e:ec:fa:08:00 SRC=192.168.1.2 DST=192.168.1.10 LEN=76 TOS=0x00 PREC=0x00 TTL=64 ID=13675 PROTO=UDP SPT=1024 DPT=123 LEN=56
Aug  7 14:15:19 debian1 kernel: [46393.339901] INPUT_DROP IN=enp6s0f0 OUT= MAC=01:00:5e:00:00:01:a4:3e:51:5b:f9:1b:08:00 SRC=192.168.1.1 DST=224.0.0.1 LEN=32 TOS=0x00 PREC=0x80 TTL=1 ID=0 DF PROTO=2
Aug  7 14:15:59 debian1 kernel: [46433.337262] INPUT_DROP IN=enp6s0f0 OUT= MAC=01:00:5e:00:00:01:a4:3e:51:5b:f9:1b:08:00 SRC=192.168.1.1 DST=224.0.0.1 LEN=32 TOS=0x00 PREC=0x80 TTL=1 ID=0 DF PROTO=2
Aug  7 14:16:08 debian1 kernel: [46441.989983] INPUT_DROP IN=enp6s0f0 OUT= MAC=bc:ee:7b:1c:c6:93:a0:63:91:7e:ec:fa:08:00 SRC=192.168.1.2 DST=192.168.1.10 LEN=76 TOS=0x00 PREC=0x00 TTL=64 ID=13676 PROTO=UDP SPT=1024 DPT=123 LEN=56
Aug  7 14:16:39 debian1 kernel: [46473.334654] INPUT_DROP IN=enp6s0f0 OUT= MAC=01:00:5e:00:00:01:a4:3e:51:5b:f9:1b:08:00 SRC=192.168.1.1 DST=224.0.0.1 LEN=32 TOS=0x00 PREC=0x80 TTL=1 ID=0 DF PROTO=2
Aug  7 14:17:01 debian1 CRON[2218]: (root) CMD (   cd / && run-parts --report /etc/cron.hourly)
Aug  7 14:17:17 debian1 kernel: [46511.019016] INPUT_DROP IN=enp6s0f0 OUT= MAC=bc:ee:7b:1c:c6:93:a0:63:91:7e:ec:fa:08:00 SRC=192.168.1.2 DST=192.168.1.10 LEN=76 TOS=0x00 PREC=0x00 TTL=64 ID=13677 PROTO=UDP SPT=1024 DPT=123 LEN=56
Aug  7 14:17:19 debian1 kernel: [46513.332035] INPUT_DROP IN=enp6s0f0 OUT= MAC=01:00:5e:00:00:01:a4:3e:51:5b:f9:1b:08:00 SRC=192.168.1.1 DST=224.0.0.1 LEN=32 TOS=0x00 PREC=0x80 TTL=1 ID=0 DF PROTO=2
Aug  7 14:17:59 debian1 kernel: [46553.329482] INPUT_DROP IN=enp6s0f0 OUT= MAC=01:00:5e:00:00:01:a4:3e:51:5b:f9:1b:08:00 SRC=192.168.1.1 DST=224.0.0.1 LEN=32 TOS=0x00 PREC=0x80 TTL=1 ID=0 DF PROTO=2
Aug  7 14:18:26 debian1 kernel: [46580.048054] INPUT_DROP IN=enp6s0f0 OUT= MAC=bc:ee:7b:1c:c6:93:a0:63:91:7e:ec:fa:08:00 SRC=192.168.1.2 DST=192.168.1.10 LEN=76 TOS=0x00 PREC=0x00 TTL=64 ID=13678 PROTO=UDP SPT=1024 DPT=123 LEN=56
Aug  7 14:18:39 debian1 kernel: [46593.326862] INPUT_DROP IN=enp6s0f0 OUT= MAC=01:00:5e:00:00:01:a4:3e:51:5b:f9:1b:08:00 SRC=192.168.1.1 DST=224.0.0.1 LEN=32 TOS=0x00 PREC=0x80 TTL=1 ID=0 DF PROTO=2
 



par exemple bind9 qui a besoin d un DNS externe si il n'a pas réussi a résoudre un nom
ou openntp qui a besoin d un serveur de temps sur le net pour distribuer le temps au client
exim4 qui est un smarhost qui fait parvenir les mail des clients a ma boite mail externe .
tous ces services sont sur la passerelle et utilise 192.168.1.10 et écoute sur 192.168.10.1.
le réseau 192.168.1.0/24 n'utilise aucune ressources du sous-réseau 192.168.10.0/24
on verra a l'utilisation  smile


Edit : Mais as-tu compris pourquoi ?
 


non pas tout , ci dessus je pose la question comment cela se passe pour les services de la passerelle qui ont besoin du net
je suis pas trop inquiet vue que firefox sur le serveur a le net
mais je comprend pas trop comment avec un drop sur enp6s0f0 ça fonctionne.
a cause de ceci qui est appliqué au 2 cartes ?


ct state established,related accept
 



si c'est le cas c'est parfait , je n'ai aucun service en entrée sur le net (comme ssh ou une imprimante ou un serveur web sur le net etc ....)
donc si pas une demande locale , le paquet doit être refusé en entrée  sur enp6s0f0.

Dernière modification par anonyme (07-08-2019 13:41:10)

#69 07-08-2019 13:46:55

anonyme
Invité

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

ça commence tongue


journalctl -r -p err
 



-- Logs begin at Wed 2019-08-07 01:22:09 CEST, end at Wed 2019-08-07 14:43:59 CEST. --
août 07 06:25:01 debian1 exim4[1430]: ALERT: exim paniclog /var/log/exim4/paniclog has non-zero size, mail system possibly bro
lines 1-2/2 (END)
 


je regarde le souci exact , il suffit de supprimer le fichier paniclog et de résoudre ce qui la provoquer


cat paniclog
 



2019-08-04 17:50:57 socket bind() to port 25 for address 192.168.10.1 failed: Cannot assign requested address: daemon abandoned
 



je redémarre le serveur

Dernière modification par anonyme (07-08-2019 13:49:48)

#70 07-08-2019 13:51:20

enicar
Membre
Lieu : pas ici
Distrib. : sid
Noyau : Linux 6.5.3
(G)UI : openbox
Inscription : 26-08-2010

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

Cette ligne là :


Aug  7 14:06:39 debian1 kernel: [45873.373711] INPUT_DROP IN=enp6s0f0 OUT= MAC=01:00:5e:00:00:01:a4:3e:51:5b:f9:1b:08:00 SRC=192.168.1.1 DST=224.0.0.1 LEN=32 TOS=0x00 PREC=0x80 TTL=1 ID=0 DF PROTO=2
 


est intéressant, ce sont des paquets igmp à destination d'une adresse multicast.
Ma bbox chez moi ne génère pas ce genre de choses. La livebox doit chercher
les groupes multicast (un truc qui permet d'envoyer des paquets à plusieurs
clients en même temps, mais contrairement au broadcast, il faut s'abonner
à un groupe multicat pour recvoir les paquets, c'est géré au niveau de routeurs
multicast, enfin  d'après ce que j'ai vaguement compris).

La ligne


Aug  7 14:06:55 debian1 kernel: [45889.758245] INPUT_DROP IN=enp6s0f0 OUT= MAC=bc:ee:7b:1c:c6:93:a0:63:91:7e:ec:fa:08:00 SRC=192.168.1.2 DST=192.168.1.10 LEN=76 TOS=0x00 PREC=0x00 TTL=64 ID=13668 PROTO=UDP SPT=1024 DPT=123 LEN=56
 


Montre que la machine qui a pour adresse 192.168.1.2 cherche à se connecter
à la passerelle en udp sur le port 123, c'est à dire le service ntp.

Dans ton log, il n'y a que ça.

anonyme a écrit :

par exemple bind9 qui a besoin d un DNS externe si il n'a pas réussi a résoudre un nom
ou openntp qui a besoin d un serveur de temps sur le net pour distribuer le temps au client
exim4 qui est un smarhost qui fait parvenir les mail des clients a ma boite mail externe .
tous ces services sont sur la passerelle et utilise 192.168.1.10 et écoute sur 192.168.10.1.
le réseau 192.168.1.0/24 n'utilise aucune ressources du sous-réseau 192.168.10.0/24
on verra a l'utilisation  smile


Là je ne vois pas du tout où tu veux venir…

Hors ligne

#71 07-08-2019 13:54:49

enicar
Membre
Lieu : pas ici
Distrib. : sid
Noyau : Linux 6.5.3
(G)UI : openbox
Inscription : 26-08-2010

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

anonyme a écrit :

je regarde le souci exact , il suffit de supprimer le fichier paniclog et de résoudre ce qui la provoquer


cat paniclog
 


Et bien, exim n'arrive pas à ouvrir une scoket tcp en écoute sur le port 25 pour l'adresse
192.168.10.1, c'est curieux, il devrait y arriver. Il faudrait voir si il n'y a pas un message
correspondant dans les logs du noyau.

Dernière modification par enicar (07-08-2019 13:56:07)

Hors ligne

#72 07-08-2019 14:05:50

anonyme
Invité

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

pour exim4 ma messagerie me donne l'erreur depuis lundi (3 messages) donc a surveiller mais je pense que c'est les tests qui ont provoqué cela

pour 192.168.1.2 c'est le switch qui cherche a ce mettre a l'heure , je l' avais oublié celui la tongue
quand je suis passé de stretch a buster , j'ai perdu ntp (ne fonctionne plus ) remplace par openntp qui normalement ne diffuse que sur 192.168.10.1 et localhost
alors que ntp lui diffusé sur localhost et les deux cartes réseau

je vais donner un serveur de temps externe au switch , pour résoudre ce souci

#73 07-08-2019 14:35:47

enicar
Membre
Lieu : pas ici
Distrib. : sid
Noyau : Linux 6.5.3
(G)UI : openbox
Inscription : 26-08-2010

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

anonyme a écrit :

non pas tout , ci dessus je pose la question comment cela se passe pour les services de la passerelle qui ont besoin du net
je suis pas trop inquiet vue que firefox sur le serveur a le net
mais je comprend pas trop comment avec un drop sur enp6s0f0 ça fonctionne.
a cause de ceci qui est appliqué au 2 cartes ?


ct state established,related accept
 


si c'est le cas c'est parfait , je n'ai aucun service en entrée sur le net (comme ssh ou une imprimante ou un serveur web sur le net etc ....)
donc si pas une demande locale , le paquet doit être refusé en entrée  sur enp6s0f0.



Le terme « appliqué au 2 cartes » est inadéquat.
L'explication  réside en partie dans ce que j'ai expliqué pour
la chaîne input qui va voir ce qui arrive à destination des adresses
192.168.1.10 et 192.168 (et aussi lo, que l'on laissera de côté).
La règle


iifname "enp6s0f1" accept
 


Permet d'accepter tout le traffic qui arrive sur cette interface
et donc à destination de 192.168.10.1
Le suivi de connexion dans la chaîne input :


ct state established,related accept
 


permet d'accepter tout le trafic qui appartient à une connexion déjà
établie (established) ou relatif à une connexion initié par la passerelle.
Par exemple lorsque que bind fait une requête dns sur un serveur externe,
ça demande passe par la chaîne output (où on accepte tout), ceci est
enregistré dans le système de suivis de connexion, le serveur dns externe
va répondre, sa réponse passe dans la chaîne input, là on accepte
ces paquets car ils font partie d'une connexion relative. Et bind
peut alors lire la réponse.

Il se passe la même chose au niveau de la chaîne forward pour les
paquets qui ne sont pas à destination de la passerelle, c'est à dire les
paquets provenant du réseau local, et à destination d'internet.
Dans ta configuration les paquets à destinations de ta box sont traité
de la même manière.
En plus de cela les paquets qui sont entrées par l'interface "enp6s0f1"
sont naté dans la chaîne postrouting, Ça enregistre la correspondance
de l'addresse source et du port source, avec le nouveau port source
sur l'adresse 192.168.1.10. Par exemple, si ton paquet a pour source :
192.168.10.20:2000, le snat va lui faire correpondre 192.168.1.10:30000.
J'ai mis des nombres au pif pour les ports. Lorsque la réponse arrive
les paquets sont dénatés grâce à la table de correspondance. En réalité
c'est plus complexe que cela.
En tous cas, ces paquets qui sont dénatés vont passé de nouveau dans la chaîne
forward et c'est là que la règle de suivis de connexion permet de les
retourner.
Pour s'en convaincre il suffit de supprimer


ct state established,related accept
 


dans la chaîne forward. Et si ça marche encore, c'est que je me trompe à ce
sujet (je n'ai jamais eu l'occasion de tester).

Hors ligne

#74 07-08-2019 14:37:04

enicar
Membre
Lieu : pas ici
Distrib. : sid
Noyau : Linux 6.5.3
(G)UI : openbox
Inscription : 26-08-2010

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

anonyme a écrit :

je vais donner un serveur de temps externe au switch , pour résoudre ce souci


On peut aussi autoriser le switch à utiliser le serveur de temps de la passerelle.
Je te laisse chercher comment…

Hors ligne

#75 07-08-2019 15:19:11

anonyme
Invité

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

j'ai beaucoup de log input-drop , je pense qu il vaut mieux supprimer la ligne log (je sais pas si les commentaires sont accepté je ne pense pas (par un # par exemple) ).
l'utiliser seulement pour surveiller et en cas de problème

oui je suppose qu'il est possible d' autoriser le switch a le faire
oui une route 192.168.1.0/24 => 192.168.10.0/24
autoriser uniquement 192.168.1.2 en entrée
ou une route 192.168.1.2 => 192.168.10.1
ça dépasse mes compétences  tongue

plus simple dire au serveur de temps de distribuer l'heure sur les deux réseau et si nftables n y voit pas d' inconvénient roll
je vois le démon de ntp faire la syncro dans le syslog , donc en théorie il voit les serveur de temps internet

Pied de page des forums