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).

#1 08-08-2019 23:46:30

anonyme
Invité

[resolu]Migration de iptables a nftables sur un client debian10

Bonjour
pas testé de migrer un fichier firewall iptables en nftables sur cette machine qui n'avait pas de pare feu.
ps: si je retrouve mon fichier "firewall" je teste la migration. ( a mon avis il doit être des plus basic roll )
voici mon nftables.conf actuel


#!/usr/sbin/nft -f

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 "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 filter; policy drop;
                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
                log prefix "INPUT6_DROP "
        }

        chain forward {
                type filter hook forward priority 0; policy drop;
                log prefix "FORWARD6_DROP "
        }

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

 



je sais pas encore si je filtre les 3 chaînes ou pas en IPv4.
faire un inventaire des services et ports utilisés.
pour l' IPv6 je fais des expériences roll , voir le genre de paquet qui transites

enlever le paquet iptables


(Lecture de la base de données... 160739 fichiers et répertoires déjà installés.)
Suppression de iptables (1.8.3-2) ...
update-alternatives: suppression de l'alternative sélectionnée manuellement - bascule de iptables vers le mode automatique
update-alternatives: suppression de l'alternative sélectionnée manuellement - bascule de ip6tables vers le mode automatique
update-alternatives: suppression de l'alternative sélectionnée manuellement - bascule de arptables vers le mode automatique
update-alternatives: suppression de l'alternative sélectionnée manuellement - bascule de ebtables vers le mode automatique
Traitement des actions différées (« triggers ») pour man-db (2.8.5-2) ...
 



pour l'instant les logs sont vide.

j'ai lancé steam , pas un jeux pour l'instant.


Aug  9 02:31:19 raven2200g kernel: [ 1788.545636] INPUT6_DROP IN=enp6s0 OUT= MAC= SRC=fe80:0000:0000:0000:6245:cbff:fe62:f693 DST=ff02:0000:0000:0000:0000:0000:0000:0001 LEN=156 TC=0 HOPLIMIT=1 FLOWLBL=86829 PROTO=UDP SPT=27036 DPT=27036 LEN=116
Aug  9 02:31:19 raven2200g kernel: [ 1788.545780] INPUT_DROP IN=enp6s0 OUT= MAC= SRC=192.168.10.47 DST=255.255.255.255 LEN=69 TOS=0x00 PREC=0x00 TTL=64 ID=47928 DF PROTO=UDP SPT=27036 DPT=27036 LEN=49
Aug  9 02:31:19 raven2200g kernel: [ 1788.545797] INPUT6_DROP IN=enp6s0 OUT= MAC= SRC=fe80:0000:0000:0000:6245:cbff:fe62:f693 DST=ff02:0000:0000:0000:0000:0000:0000:0001 LEN=89 TC=0 HOPLIMIT=1 FLOWLBL=86829 PROTO=UDP SPT=27036 DPT=27036 LEN=49
Aug  9 02:31:21 raven2200g kernel: [ 1790.542624] INPUT_DROP IN=enp6s0 OUT= MAC= SRC=192.168.10.47 DST=255.255.255.255 LEN=69 TOS=0x00 PREC=0x00 TTL=64 ID=48094 DF PROTO=UDP SPT=27036 DPT=27036 LEN=49
Aug  9 02:31:21 raven2200g kernel: [ 1790.542669] INPUT6_DROP IN=enp6s0 OUT= MAC= SRC=fe80:0000:0000:0000:6245:cbff:fe62:f693 DST=ff02:0000:0000:0000:0000:0000:0000:0001 LEN=89 TC=0 HOPLIMIT=1 FLOWLBL=86829 PROTO=UDP SPT=27036 DPT=27036 LEN=49
Aug  9 02:31:23 raven2200g kernel: [ 1792.576012] INPUT_DROP IN=enp6s0 OUT= MAC= SRC=192.168.10.47 DST=255.255.255.255 LEN=141 TOS=0x00 PREC=0x00 TTL=64 ID=48595 DF PROTO=UDP SPT=27036 DPT=27036 LEN=121
Aug  9 02:31:23 raven2200g kernel: [ 1792.576053] INPUT6_DROP IN=enp6s0 OUT= MAC= SRC=fe80:0000:0000:0000:6245:cbff:fe62:f693 DST=ff02:0000:0000:0000:0000:0000:0000:0001 LEN=161 TC=0 HOPLIMIT=1 FLOWLBL=86829 PROTO=UDP SPT=27036 DPT=27036 LEN=121
Aug  9 02:31:28 raven2200g kernel: [ 1797.573929] INPUT_DROP IN=enp6s0 OUT= MAC= SRC=192.168.10.47 DST=255.255.255.255 LEN=69 TOS=0x00 PREC=0x00 TTL=64 ID=49565 DF PROTO=UDP SPT=27036 DPT=27036 LEN=49
Aug  9 02:31:28 raven2200g kernel: [ 1797.573968] INPUT6_DROP IN=enp6s0 OUT= MAC= SRC=fe80:0000:0000:0000:6245:cbff:fe62:f693 DST=ff02:0000:0000:0000:0000:0000:0000:0001 LEN=89 TC=0 HOPLIMIT=1 FLOWLBL=86829 PROTO=UDP SPT=27036 DPT=27036 LEN=49
Aug  9 02:31:35 raven2200g smartd[613]: Device: /dev/sdb [SAT], SMART Usage Attribute: 194 Temperature_Celsius changed from 54 to 53
Aug  9 02:31:42 raven2200g kernel: [ 1811.589723] INPUT_DROP IN=enp6s0 OUT= MAC= SRC=192.168.10.47 DST=255.255.255.255 LEN=141 TOS=0x00 PREC=0x00 TTL=64 ID=49935 DF PROTO=UDP SPT=27036 DPT=27036 LEN=121
Aug  9 02:31:42 raven2200g kernel: [ 1811.589769] INPUT6_DROP IN=enp6s0 OUT= MAC= SRC=fe80:0000:0000:0000:6245:cbff:fe62:f693 DST=ff02:0000:0000:0000:0000:0000:0000:0001 LEN=161 TC=0 HOPLIMIT=1 FLOWLBL=86829 PROTO=UDP SPT=27036 DPT=27036 LEN=121
 



a priori j'ai IPv4 et IPv6 de la passerelle ou simplement local de la machine 192.168.10.47 ?
laisser l' IPv6 en "accept" , uniquement du fe80 , ça reste local ça roll
pour l' IPv4 autoriser les ports 27xxx , il me semble que steam (sur son site) donne les ports a ouvrir
ps: avec iptables j'avais une règle , faut que je cherche
l' utilitaire fonctionne , il me reste a lancer un jeux  roll

les adresses du client


ip address
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: enp6s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 60:45:cb:62:f6:93 brd ff:ff:ff:ff:ff:ff
    inet 192.168.10.47/24 brd 192.168.10.56 scope global dynamic enp6s0
       valid_lft 26374sec preferred_lft 26374sec
    inet6 fe80::6245:cbff:fe62:f693/64 scope link
       valid_lft forever preferred_lft forever
 



le jeux fonctionne (Talos) , pas de log supplémentaire

voila la règle steam sous iptables pour la passerelle (pour le client idem autoriser 27xxx )


Pour autoriser la plateforme de jeux STEAM

/sbin/iptables -A INPUT -i eth1 -p udp -m udp --sport 27000 -m\
 state --state NEW,ESTABLISHED -j ACCEPT
/sbin/iptables -A INPUT -i eth0 -p udp -m udp --sport 27000 -m\
 state --state ESTABLISHED -j ACCEPT
 



et le lien du wiki "passerelle" sous iptables  tongue =>  https://debian-facile.org/doc:reseau:ip … passerelle
nota: jamais réussi a le faire fonctionner , pour le client oui mais sûrement pas parfait  roll
le client sous iptables => https://debian-facile.org/doc:reseau:ip … ting-shell
pas tout jeune , de 2014 , mais un sacré travail du membre pour faire ces wiki  hmm

=>  https://support.steampowered.com/kb_art … -GLVN-8711

les ports utilisés (tous ne sont pas utiles pour jouer)


Required Ports for Steam

Which ports do I need to open on my router or firewall for Steam?
To log into Steam and download content:

    HTTP (TCP remote port 80) and HTTPS (443)
    UDP remote port 27015--27030
    TCP remote port 27015--27030

Steam Client

    UDP remote port 27000--27100: Game traffic
    UDP local port 27031 and 27036: In-Home Streaming
    TCP local port 27036 and 27037: In-Home Streaming
    UDP remote port 4380

Dedicated or Listen Servers

    TCP local port 27015 (default): SRCDS Rcon port
    UDP local port 27015 (default): gameplay traffic

Steamworks P2P Networking and Steam Voice Chat

    UDP remote port 3478
    UDP remote port 4379
    UDP remote port 4380
 

Dernière modification par anonyme (13-08-2019 00:30:45)

#2 09-08-2019 09:28:12

raleur
Membre
Inscription : 03-10-2014

Re : [resolu]Migration de iptables a nftables sur un client debian10

anonyme a écrit :

a priori j'ai IPv4 et IPv6 de la passerelle ou simplement local de la machine 192.168.10.47 ?


C'est du multicast link local IPv6 all-nodes (ff02::1) et du broadcast limité IPv4 (255.255.255.255) émis par la machine elle-même (et reçue par elle puisque le multicast et le broadcast s'adressent à tout le monde). Cela ne joue un rôle que pour les jeux en réseau local (LAN), pas via internet.

L'adresse de broadcast dirigé 192.168.10.56 définie sur enp6s0 est anormale. Compte tenu de l'adresse et du masque /24, cela devrait être 192.168.10.255. Si c'est en DHCP (dynamic), le serveur DHCP n'enverrait pas un peu n'importe quoi ?


Il vaut mieux montrer que raconter.

Hors ligne

#3 09-08-2019 10:58: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 un client debian10

raleur a écrit :

L'adresse de broadcast dirigé 192.168.10.56 définie sur enp6s0 est anormale. Compte tenu de l'adresse et du masque /24, cela devrait être 192.168.10.255.


C'est un mauvais réglage dans la conf du serveur DHCP : elle est ici :
https://debian-facile.org/viewtopic.php … 75#p307675.
Je m'étais d'ailleurs posé la question de pourquoi configurer le broadcast de cette façon.

Dernière modification par enicar (09-08-2019 11:00:41)

Hors ligne

#4 09-08-2019 11:26:50

anonyme
Invité

Re : [resolu]Migration de iptables a nftables sur un client debian10

Bonjour
pour limiter le nombre d' IP affecter par le dhcpd 20 a 55 , le broadcast est a 56 (+1)
ça me pose pas de problème de mettre 255
mais je l'ai pas inventé

mais bon c'est pas le sujet du post  roll  qui est de filtrer mes applications.
modifié


subnet 192.168.10.0 netmask 255.255.255.0 {
 range 192.168.10.20 192.168.10.55;
 option domain-name-servers 192.168.10.1;
 option domain-name "mondomaine";
 option routers 192.168.10.1;
 option broadcast-address 192.168.10.255;
 option ntp-servers 192.168.10.1;
# option netbios-name-servers 192.168.10.1;
 


ps: c'est sur le #47 du post "Migration de iptables a nftables sur une passerelle".

Dernière modification par anonyme (09-08-2019 11:39:22)

#5 09-08-2019 11:30:27

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 un client debian10

anonyme a écrit :

pour limiter le nombre d' IP affecter par le dhcpd 20 a 55 , le broadcast est a 56 (+1)
ça me pose pas de problème de mettre 255
mais je 'ai pas inventé


En réalité, je me suis posé la question, mais je me souviens avoir lu (il y a longtemps) sur irc
que c'était possible.

Hors ligne

#6 09-08-2019 11:46:15

anonyme
Invité

Re : [resolu]Migration de iptables a nftables sur un client debian10

voila :


ip address
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: enp6s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 60:45:cb:62:f6:93 brd ff:ff:ff:ff:ff:ff
    inet 192.168.10.47/24 brd 192.168.10.255 scope global dynamic enp6s0
       valid_lft 28657sec preferred_lft 28657sec
    inet6 fe80::6245:cbff:fe62:f693/64 scope link
       valid_lft forever preferred_lft forever
 




Suivant ce principe, une adresse de diffusion pourrait ne pas forcément se terminer par .255.
Ce cas très rare n'est utilisé que dans des sous-réseaux spéciaux très petits
 


=> https://fr.wikipedia.org/wiki/Broadcast_(informatique)
=> https://fr.wikipedia.org/wiki/Broadcast
sujet clos , revenons a nos moutons , heu nos paquets tongue  wink

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

#7 09-08-2019 12:09:20

anonyme
Invité

Re : [resolu]Migration de iptables a nftables sur un client debian10

raleur a écrit :

anonyme a écrit :

a priori j'ai IPv4 et IPv6 de la passerelle ou simplement local de la machine 192.168.10.47 ?


C'est du multicast link local IPv6 all-nodes (ff02::1) et du broadcast limité IPv4 (255.255.255.255) émis par la machine elle-même (et reçue par elle puisque le multicast et le broadcast s'adressent à tout le monde). Cela ne joue un rôle que pour les jeux en réseau local (LAN), pas via internet.



par contre ceci est intéressant
je me pose la question de l'intérêt de filtrer (bloquer ) l'IPv6 sur un client du sous-réseau avec des adresses IPv6 uniquement locale.
ps: la passerelle bloque l'IPv6 dans le cas ou il serait activé sur la box.

je pourrai même supprimer cette table roll


table ip6 filter {
        chain input {
                type filter hook input priority 0; policy accept;
                #iif lo accept
                #log prefix "INPUT6_DROP "
        }

        chain forward {
                type filter hook forward priority 0; policy accept;
                #log prefix "FORWARD6_DROP "
        }

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



pour IPv4 je compte pas faire du jeux en réseau local , je suppose que si plusieurs clients sur une  même partie , ou une application comme "steam link" ce peut être utile.

Dernière modification par anonyme (09-08-2019 12:21:55)

#8 09-08-2019 13:48:38

raleur
Membre
Inscription : 03-10-2014

Re : [resolu]Migration de iptables a nftables sur un client debian10

anonyme a écrit :

pour limiter le nombre d' IP affecter par le dhcpd 20 a 55 , le broadcast est a 56 (+1)
ça me pose pas de problème de mettre 255 mais je l'ai pas inventé


D'où sors-tu cette règle ? Je pense que si, tu l'as inventée, ou mal interprétée.
Par convention, l'adresse de broadcast est la dernière adresse du préfixe (ou sous-réseau) et n'a rien à voir avec la plage d'adresses attribuables par DHCP à l'intérieur de ce préfixe.

Techniquement on pourrait choisir une autre adresse (BSD a utilisé la première adresse, appelée également adresse de réseau, comme adresse de broadcast) mais alors il faudrait que toutes les machines du réseau soient configurées explicitement pour utiliser la même adresse de broadcast, qu'elles soient en DHCP ou en statique. Or je vois dans le fil pointé par enicar que le fichier interfaces du serveur DHCP lui-même ne définit pas cette adresse de broadcast.

anonyme a écrit :

Suivant ce principe, une adresse de diffusion pourrait ne pas forcément se terminer par .255.
Ce cas très rare n'est utilisé que dans des sous-réseaux spéciaux très petits


"Réseaux très petits" = réseaux de moins de 256 adresses, avec un préfixe de longueur strictement supérieure à 24, soit un masque strictement supérieur à 255.255.255.0. Ce qui n'est pas le cas ici. D'autre part cela ne signifie pas qu'on peut choisir arbitrairement l'adresse de broadcast mais seulement que celle-ci, qui est toujours la dernière adresse du réseau, ne finit pas forcément par 255.


Il vaut mieux montrer que raconter.

Hors ligne

#9 09-08-2019 13:54:59

raleur
Membre
Inscription : 03-10-2014

Re : [resolu]Migration de iptables a nftables sur un client debian10

anonyme a écrit :

je me pose la question de l'intérêt de filtrer (bloquer ) l'IPv6 sur un client du sous-réseau avec des adresses IPv6 uniquement locale


Ça dépend si tu utilises IPv6 sur ton LAN et s'il y a des menaces potentielles en IPv6 sur ce LAN, par exemple s'il peut arriver d'y connecter des appareils non dignes de confiance (contre lesquels le filtrage de la passerelle ne protègera pas un poste du LAN).
Si tu n'utilises pas IPv6 et qu'il peut constituer une menace, alors ça justifie de le bloquer. En sortie aussi, car ça n'a pas de sens d'autoriser tout en sortie et de bloquer tout en entrée.

Dernière modification par raleur (09-08-2019 13:56:34)


Il vaut mieux montrer que raconter.

Hors ligne

#10 09-08-2019 14:33:10

anonyme
Invité

Re : [resolu]Migration de iptables a nftables sur un client debian10

On avait vue ensemble , sur le sous-réseau pas d' annonce de routeur , juste des adresses fe80xxxx attribué par défaut
donc non je ne l'utilise pas IPv6 coté sous-réseau. (192.168.10.1)
le seul routeur qui fait des annonces c'est la box en 192.168.1.1 (IPv6 désactivé actuellement)
je peu tout bloqué et ignorer les logs du noyau pour éviter de surcharger le syslog
nota: éventuellement un portable peu se connecter et pas forcément de confiance .
normalement le 192.168.1.0/24 est réservé aux invités et le 192.168.10.0/24 est a part mais bon c'est en théorie

pour le #8 j'ai modifié 192.168.10.255 avant ta remarque sur le dhcp
je te fais remarquer que mon sous-réseau utilise moins de 256 adresses (20 à 55) , la 192.168.10.1 pour le serveur , la 0 ,56 et 255 réservé au système
une machine windows10 en IP fixe 192.168.10.254 qui n'a droit a aucune ressources du sous-réseau (utilise uniquement la passerelle pour le net et un DNS externe) . (un jour il faudra que je m' en débarrasse roll ).
a mon avis ça change pas grand chose mais j'ai modifié wink

Dernière modification par anonyme (09-08-2019 14:34:24)

#11 09-08-2019 14:41:39

raleur
Membre
Inscription : 03-10-2014

Re : [resolu]Migration de iptables a nftables sur un client debian10

anonyme a écrit :

je te fais remarquer que mon sous-réseau utilise moins de 256 adresses (20 à 55)


Non, c'est seulement la plage DHCP qui utilise les adresses 20 à 55. Le sous-réseau lui-même, de par son masque 255.255.255.0 ou /24 utilise toutes les adresses de 0 à 255.

anonyme a écrit :

une machine windows10 en IP fixe 192.168.10.254 qui n'a droit a aucune ressources du sous-réseau


Elle est quand même dans le sous-réseau.

anonyme a écrit :

a mon avis ça change pas grand chose mais j'ai modifié


En pratique ça n'influe que sur les applications qui utilisent l'adresse de broadcast dirigé. Il me semble que la résolution de nom NetBIOS (NBNS, qui peut être utilisé par Samba et Windows) en fait partie. Il existe une autre adresse de broadcast dit limité (non routable contrairement au broadcast dirigé), 255.255.255.255, définie par défaut qui est toujours la même dans tous les réseaux. Visiblement c'est elle qu'utilise Steam.

Dernière modification par raleur (09-08-2019 14:43:17)


Il vaut mieux montrer que raconter.

Hors ligne

#12 09-08-2019 14:50:27

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 un client debian10

raleur a écrit :

Or je vois dans le fil pointé par enicar que le fichier interfaces du serveur DHCP lui-même ne définit pas cette adresse de broadcast.


Tu dois avoir mal lu :

anonyme a écrit :


la configuration du dhcpd


subnet 192.168.10.0 netmask 255.255.255.0 {
 range 192.168.10.20 192.168.10.55;
 option domain-name-servers 192.168.10.1;
 option domain-name "mondomaine";
 option routers 192.168.10.1;
 option broadcast-address 192.168.10.56;
 option ntp-servers 192.168.10.1;
# option netbios-name-servers 192.168.10.1;
 


On voit clairement


option broadcast-address 192.168.10.56;
 


C'est cela qui avait fixé le broadcast des clients sur cette adresse.

Hors ligne

#13 09-08-2019 14:55:47

raleur
Membre
Inscription : 03-10-2014

Re : [resolu]Migration de iptables a nftables sur un client debian10

C'est toi qui as mal lu ; je parlais du fichier interfaces, pas de la configuration de dhcpd :

Or je vois dans le fil pointé par enicar que le fichier interfaces du serveur DHCP lui-même ne définit pas cette adresse de broadcast.


Il y a donc discordance entre l'adresse de broadcast utilisée par le serveur lui-même et l'adresse de broadcast qu'il annonce à ses clients.

Dernière modification par raleur (09-08-2019 14:57:42)


Il vaut mieux montrer que raconter.

Hors ligne

#14 09-08-2019 14:57:36

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 un client debian10

raleur a écrit :

Non, c'est seulement la plage DHCP qui utilise les adresses 20 à 55. Le sous-réseau lui-même, de par son masque 255.255.255.0 ou /24 utilise toutes les adresses de 0 à 255.


C'est ce qui m'a fait douter, le fait qu'il n'utilise qu'un plage limitée d'adresse pour le serveur
dhcp. Mais je n'aurais pas du.

(Et je regrette parfois de n'avoir pas fait cette formation en réseau en 2003 comme
j'en avais la possibilité, mais ça c'est une autre histoire tongue)

Hors ligne

#15 09-08-2019 14:58:43

raleur
Membre
Inscription : 03-10-2014

Re : [resolu]Migration de iptables a nftables sur un client debian10

Je n'ai jamais suivi de formation réseau, ça ne m'a pas manqué. Je me suis formé tout seul.

Il vaut mieux montrer que raconter.

Hors ligne

#16 09-08-2019 15:00:07

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 un client debian10

raleur a écrit :

C'est toi qui as mal lu ; je parlais du fichier interfaces, pas de la configuration de dhcpd :


J'ai surtout pas compris ce que tu entendais par « serveur DHCP »…
la configuration était bancale de toute façon.

Hors ligne

#17 09-08-2019 15:01:35

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 un client debian10

raleur a écrit :

Je n'ai jamais suivi de formation réseau, ça ne m'a pas manqué. Je me suis formé tout seul


Si tu as des liens intéressants à partager sur le réseau, je suis preneur et ça devrait
intéressait d'autres personnes aussi.

Hors ligne

#18 09-08-2019 15:01:47

raleur
Membre
Inscription : 03-10-2014

Re : [resolu]Migration de iptables a nftables sur un client debian10

enicar a écrit :

J'ai surtout pas compris ce que tu entendais par « serveur DHCP »…


Il s'agit de la machine qui fait office de serveur DHCP, et pas spécifiquement le service dhcpd qui tourne sur celle-ci.


Il vaut mieux montrer que raconter.

Hors ligne

#19 09-08-2019 17:16:06

anonyme
Invité

Re : [resolu]Migration de iptables a nftables sur un client debian10

pour enicar , la passerelle comme je t'ai expliqué avant a 4 services , exim4 , openntpd , bind9 et isc-dhcp-server
le fichier interfaces (avec bien netmask => 255.255.255.0 comme a dit raleur )
pour avoir moins d'IP il faut choisir une autre IP fixe et un mask différent (255.0.0.0 par exemple et l'IP fixe qui va bien (pas trop mon truc non plus tongue ) )


source /etc/network/interfaces.d/*

# The loopback network interface
auto lo
iface lo inet loopback

# carte reseau enp6s0f0
auto enp6s0f0
iface enp6s0f0 inet static
address 192.168.1.10
netmask 255.255.255.0
network 192.168.1.0
gateway 192.168.1.1
dns-nameservers 127.0.0.1

# carte enp6s0f1
auto enp6s0f1
iface enp6s0f1 inet static
address 192.168.10.1
netmask 255.255.255.0
network 192.168.10.0
 



donc debian1 (la passerelle) est un serveur de tous ses services ci dessus pour le sous-réseau 192.168.10.0/24 (et localhost)
sauf openntpd qui en plus maintenant distribue le temps sur les 2 cartes réseau pour le switch 192.168.1.2 dont a parlé plus haut

#20 09-08-2019 17:54: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 un client debian10

anonyme a écrit :

pour avoir moins d'IP il faut choisir une autre IP fixe et un mask différent (255.0.0.0 par exemple et l'IP fixe qui va bien (pas trop mon truc non plus tongue ) )


Euh… t'es sûr ? Parce qu'un netmask de 255.0.0.0, ça veut dire que la partie
réseau de l'adresse est sur les 8 premiers bits (comme dans les les adresses 10.0.0.0/8).
Le reste (c'est à dire les 24 derniers bits) sont pour la partie  « hôte ».
À moins que je me trompe…

Edit : J'ai compté les bits depuis la gauche au lieu du contraire dans
mon commentaire…
En effet pour avoir un plus petit sous réseau il faut ajouter
un 1 (ou plusieurs) à partir de la gauche au netmask.
Par exemple avec un netmask de 255.255.255.128.
et un réseau ayant pour adresse 192.168.1.0
la plage d'adresse est 192.168.1.0 à 192.168.1.127
l'adresse de diffusion étant 192.168.1.127.
Il me semble que c'est comme ça que ça marche, corrigez moi si
je me trompe, ça fait longtemps que je n'ai pas touché à ces histoires…

Dernière modification par enicar (09-08-2019 19:02:19)

Hors ligne

#21 09-08-2019 18:12:45

anonyme
Invité

Re : [resolu]Migration de iptables a nftables sur un client debian10

c'est pas moi qui va te dire le contraire tongue , mais bon ça ce trouve facilement sur le net.
j'ai sûrement écrit une bêtise  wink

=> https://fr.wikipedia.org/wiki/Sous-r%C3%A9seau

moi ça me donne la migraine hmm  tongue , mais j' aurai pu faire autre chose que 192.168.10.0/24

Dernière modification par anonyme (09-08-2019 18:14:56)

#22 09-08-2019 18:17: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 un client debian10

anonyme a écrit :

j'ai sûrement écrit une bêtise wink


Ce n'est pas évident, il faut à chaque fois que j'y réfléchisse.
J'avais appris tout cela dans le networking howto il me semble.
Ce document est vraiment vieux, mais pour ces questions il
est encore d'actualité : http://tldp.org/HOWTO/NET3-4-HOWTO.html

Hors ligne

#23 09-08-2019 18:55:54

raleur
Membre
Inscription : 03-10-2014

Re : [resolu]Migration de iptables a nftables sur un client debian10

anonyme a écrit :

pour avoir moins d'IP il faut choisir une autre IP fixe et un mask différent (255.0.0.0 par exemple et l'IP fixe qui va bien


Pas du tout. Enicar a raison.
Pour un réseau plus petit il faut un masque plus grand. Par exemple 255.255.255.128 (/25) pour 128 adresses.
Et ce n'est pas parce que tu veux un /24 que tu dois utiliser 192.168.x.y ou vice versa. Les classes A, B, C sont obsolètes. Tu peux utiliser l'adresse IP que tu veux du moment que le sous-réseau contient dans le bloc correspondant.

Par exemple 192.168.x.y fait partie d'un bloc /16 donc tu peux utiliser n'importe quel masque supérieur ou égal à 255.255.0.0 ou longueur de préfixe supérieure ou à /16.
10.x.y.z fait partie d'un bloc /8 donc tu peux utiliser n'importe quel masque supérieur ou égal à 255.0.0.0 ou longueur de préfixe supérieure ou égale à 8.

Dernière modification par raleur (09-08-2019 18:57:44)


Il vaut mieux montrer que raconter.

Hors ligne

#24 10-08-2019 13:08:02

anonyme
Invité

Re : [resolu]Migration de iptables a nftables sur un client debian10

@enicar
j'ai modifié mon nftables comme ceci


#!/usr/sbin/nft -f

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 "INVALID_INPUT " drop
    ct state established,related accept
    icmp type { echo-request, echo-reply } accept
    icmp type { destination-unreachable,time-exceeded, parameter-problem } accept
    log prefix "INPUT_DROP "
  }

  chain forward {
    type filter hook forward priority filter; policy drop;
    log prefix "FORWARD_DROP "
  }

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



le ping fonctionne bien de client a client et vers le net (par ip , nom et nomdomaine)
firefox pas de souci
je surveille les logs (a priori la chaine forward peut être bloqué ? )
DNS et dhclient correct aussi
pour renforcer , je pourrais filtrer le output (en drop)
comme service:
dhcp client
dns
steam
http , https
smtp (25) exim4
et cups (imprimante)
je vois rien d'autres (machine de bureau)

ps: pour IPv6 en l'absence de table , c'est autorisé ?

#25 10-08-2019 13:14:02

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 un client debian10

anonyme a écrit :

ps: pour IPv6 en l'absence de table , c'est autorisé ?


Je ne sais pas trop… Je pense que non.
En fait j'avais mal lu, l'absence de table et de chaîne pour ipv6 est autorisée.
Par contre je ne sais pas si ça permet au traffic ipv6 d'être autorisé
ou pas dans ce cas.

Edit : Tu peux le vérifier avec ton interface lo
en faisant :


ping6 lo
 


Edit2 : Il faut faire


ping6 localhost
 


ou


ping6 ::1
 


Avec le nom d'interface, ça ne fonctionne pas wink

Dernière modification par enicar (10-08-2019 14:37:49)

Hors ligne

Pied de page des forums