Vous n'êtes pas identifié(e).
je surveille les logs (a priori la chaine forward peut être bloqué ? )
Sur un poste client l'ip forwarding n'est pas activé. Il ne devrait rien passé
dans cette chaîne. Ton log des paquets dans cette chaîne ne sert à rien.
C'est bien tout de même de garder sa policy sur drop.
Hors ligne
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)
Je pense que c'est inutile. En plus si un site utilise
un port non standard, ça va bloquer la communication.
Hors ligne
ping6 lo
Ping sur un nom d'interface, ça marche ce truc ? (test chez moi : non mais c'est avec jessie)
Dernière modification par raleur (10-08-2019 14:11:09)
Il vaut mieux montrer que raconter.
Hors ligne
ceci fonctionne (sur la machine avec nftables )
pour #26 et 27 ok , pour le forward pas sur de moi donc je retire le log , et pour le output oui tu a pitié de moi
bon je duplique ça sur tous les postes client et je continue les tests
merci
ps: j' ajoute ceci (avec l'ipv6 affecté a la carte )
Ping sur un nom d'interface, ça marche ce truc ? (test chez moi : non mais c'est avec jessie)
Oh ! T'as raison je me suis trompé, il faut faire :
bien entendu !
Hors ligne
ceci fonctionne (sur la machine avec nftables )
C'est sans table pour l'ipv6, ça prouve que par défaut l'ipv6 passe
quand il n'y a que des règles pour le filtrages de l'ipv4. Ce qui n'est pas
très étonnant. À toi de voir, si tu as envie de laisser les choses comme ça
ou pas. Personnellement, je me protégerais aussi en ipv6 rien que pour
être cohérent.
Hors ligne
je n'ai que des fe80xxxxxxx comme ipv6
d un client vers un autre un ping ipv6 passera pas
Ben si, on peut faire un ping (et bien d'autres choses) avec des adresses link local en fe80. Il faut juste spécifier l'interface de sortie. Selon la commande et la variante, il peut y avoir deux syntaxes :
- en suffixe de l'adresse avec le symbole "%", par exemple
- dans une option séparée, par exemple
Dernière modification par raleur (10-08-2019 15:24:18)
Il vaut mieux montrer que raconter.
Hors ligne
le ping a été fait de :
l'interface "enp6s0"
le client qui a répondu au ping a l'interface "enp0s31f6" et l'adresse "fe80::2e4d:54ff:fe54:68ea"
comme certitude la passerelle isole bien l'ipv6 de la livebox (et du net)?
si je dois filtrer aussi l'ipv6 pas cool
j'ai testé comme ceci , ça fonctionne
et comme ceci aussi correct
Dernière modification par anonyme (10-08-2019 16:17:30)
comme certitude la passerelle isole bien l'ipv6 de la livebox (et du net)?
Oui, si elle ne route pas l'IPv6 (net.ipv6.conf.all.forwarding=0) ou le filtre en FORWARD.
Dernière modification par raleur (10-08-2019 16:31:08)
Il vaut mieux montrer que raconter.
Hors ligne
mail et ping fonctionnent (sauf ipv6 tout en drop)
Dernière modification par anonyme (11-08-2019 16:54:58)
chain forward {
type filter hook forward priority filter; policy drop;
log prefix "FORWARD_DROP "
}
Tu n'as pas besoin de mettre « log prefix "FORWARD_DROP " ».
Sur tes postes clients, l'ip forwarding est désactivé (c'est la valeur par
défaut dans les noyaux debian). Donc, rien ne devrait passer dans la chaîne
forward. C'est bien de garder la chaîne forward avec la policy sur drop.
C'est pour éviter de se poser la question quand on regarde les règles quelques mois
plus tard.
Hors ligne
avec ceci ça fonctionne
Dernière modification par anonyme (11-08-2019 22:14:49)
sur deux clients j'ai un souci , sur forward l'option "filter" est refusé , "0" est accepté
Normal, la priorité c'est un nombre, plus il est petit plus la chaîne est prioritaire.
On peut avoir des priorités négatives. Ça ne sert que lorsqu'on attache plusieurs chaînes
au même hook. Donc dans ton cas ça ne sert à rien, mais c'est nécessaire pour la
syntaxe de déclaration du hook auquel la chaîne est attachée.
Hors ligne
pourquoi le premier fonctionne avec le paramètre "filter" en fin de ligne , et les 3 suivant non , uniquement avec une valeur numérique.
De quoi tu parles exactement ? Dans toutes tes chaînes
je vois que la priorité est exprimé avec un nombre.
Je crois me souvenir que l'on peut utiliser autre chose qu'un nombre
il faut que je retrouve cette explication dans le wiki de nftables.
Hors ligne
qui a toujours fonctionné et actuellement encore
je fais trois autres machines
ne me prend que ceci
tu me dit que sur un client la chaine forward n'est pas utilise (une seule carte réseau ) mais qu'il vaut mieux la fixer a drop
quelle différence entre le client raven2200g avec "filter" et les trois autres clients avec "0" sinon le nftables bug
si tu regarde ce fil , la chaine forward est a "filter" , pour la passerelle a "1"
ps: regarde en #1 la fin de la chaine forward est a "filter" depuis le début , c'est une erreur de ma part ? (et ça fonctionne pour cette machine )
sinon voila avec ma petite modification pour filtrer netbios (port 138)
ps: pour enlever le client samba , il faut que je change de bureau , passer de mate a xfce4
la passerelle et le raven2200g sont en xfce4
pour les autres machines je suis en mate donc avec des annonces en port 138 et 192.168.10.255
Si [famille] est omis, ip sera utilisé (c'est à dire que les règles dans cette
table opérerons sur des paquets qui ont une adresse en ipv4). Voir ici
pour les familles disponibles. Les familles servent lors de la
création des tables.
La création des chaînes de base est différente. On précise leur type, le hook
auquel elles sont rattachées, leur priorité et enfin optionnellement la police
par défaut (accept par défaut, sinon drop).
En résumé on a :
Le nom de la chaîne est absolument libre. On met le nom que l'on veut. Au sein
d'une même table il doit être unique. Cependant un même nom de chaîne
peut-être utilisé dans des tables différentes ; ce sont alors des chaînes
différentes. Le hook peut prendre les valeur suivante : prerouting,
postrouting, input, output et ingress.
Toute les combinaisons famille/type ne sont pas possible. Ainsi, le type
ingress ne peut être utilisé que dans une table de la famille netdev, c'est un
cas particulier.
Bref, ça fait beaucoup de briques différentes que l'on doit utiliser d'une
manière précise.
Les règles sont incluses dans des chaînes qui sont incluses dans des tables.
J'espère que c'est plus clair à présent.
Hors ligne
tu me dit que sur un client la chaine forward n'est pas utilise (une seule carte réseau ) mais qu'il vaut mieux la fixer a drop
Sur le wiki de nftables, j'ai même lu que dans ce cas on pouvait omettre cette chaîne.
Hors ligne
c'est pas grave en #39 tu m'a donné ceci pour le premier client
En fait, le post #39 c'est toi qui l'a écrit. Et je viens de regarder
cette priority filter pour la chaîne forward était déjà présent dans ton post #1.
Si c'est moi qui a écrit cela, je me suis trompé. Si nftables l'accepte parfois et parfois pas,
je ne comprends pas pourquoi.
Hors ligne
Hors ligne
je suis loin de comprendre comme toi le cheminement du réseau (pour preuve sur la passerelle )
Ça viendra, c'est une question de pratique. Il faut aussi du temps pour intégrer
ces histoires, je n'ai pas compris la première fois que je l'ai lu lors du passage à
iptables dans les noyaux 2.4.
Hors ligne
il contacte un serveur
il a en réponse une ip d un serveur disponible pour le téléchargement
une requette pour ma carte graphique
connexion et téléchargement
début du calcul
dans l'autre sens idem , récupérer une nouveau calcul , envoie du résultat du calcul terminé etc ....
ps: a partir du client ça fonctionne , la passerelle accepte les requêtes
Dernière modification par anonyme (12-08-2019 13:22:58)