Vous n'êtes pas identifié(e).
le "flush ruleset" je sais pas a quoi il est utile (flush c'est pour supprimer il me semble) ,
Ça supprime (flush) l'ensemble des règles (ruleset).
Hors ligne
pour le #22 c'est corrigé
ça donne ceci
Sauf que ça ne devrait pas fonctionner, il faut autoriser le trafic qui
sort par l'interface enp6s0f0 (ou celui qui entre par l'interface
enp6s0f1) dans la chaîne forward.
Comme ça la passerelle pourra laisser passer les flux vers internet,
ça peut être utile
J'ai remis le code pour le nat, je ne sais pas dans quels cas servent
les chaînes input et output pour la table nat, mais bon. Je n'ai pas encore
bien compris tout ce que l'on pouvait faire avec ça.
Hors ligne
et ça fonctionne
pour le input coté passerelle sur le sous réseau sur la carte enps6s0f1 normalement c'est fiable . ( a moins d'avoir un client infecté ou un utilisateur mal veillant )
c'est le input sur enps6f0 ou faut que je sois rigoureux sur ce que j'autorise (coté net ) en entrée .
pour la passerelle un nouveau test va se faire , l'été très peu de machines en activité en cas de coupure du serveur
Ici j'ai défini une variable « passerelle_adr » où tu pourras mettre
l'adresse de ta passerelle. pour l'utiliser dans une règle il suffit de la
préfixé par « $ », comme dans le shell. Ici ce que je montre est artificiel
car ce qui arrive dans la chaîne input par l'interface "enps60f1" est forcément
à destination de la passerelle (sauf si ton interface à plusieurs ip, mais
je ne pense pas que ce soit le cas). Sinon les paquets qui ne sont pas à
destination de l'ip de la passerelle vont passer dans la chaîne forward.
Dans la chaîne local_in tu peux mettre les règles dont tu as besoin.
Par exemple pour autoriser le ssh sur le port 22 :
Pour le dns sur le port 53
On peut rajouter le dhcp de la même façon :
Puis le port pour CUPS :
Ce qui donnerait pour la chaîne local_in
J'ai rajouté la possibilité d'émettre et de recevoir des pings, car
c'est quand même parfois pratique.
Évidemment tu peux vouloir faire quelque chose de plus précis.
Mais comme tu le vois les règles s'expriment de façon assez simple.
En tous cas je trouve cela plus lisible que les règles d'iptables.
Remarque : on peut simplifier le code précédent en :
On peut aussi utiliser les noms des services à la place des numéros de ports.
Dernière modification par enicar (06-08-2019 12:34:26)
Hors ligne
où
<table> est la table concernée, par exemple filter,
<chain> est la chaîne concernée, par exemple input (ou local_in)
<règle> la règle à ajouter.
Évidemment, tu ne peux ajouter qu'une règle à une chaine qui appartient à table
désignée par <table>. C'est évident mais je préfère prendre des précautions.
Pour rajouter une chaîne à la table :
Pour la supprimer :
Hors ligne
Dernière modification par anonyme (06-08-2019 14:12:18)
pour moi il me faut si je me trompe pas, le port 80 , 8080 , et 443 pour mes applications (pas de serveur http sur le réseau)
Je ne comprend pas… le port 80 sur quel interface et depuis quelle adresse ?
pour les cartes réseau c'est 4 + 1 pour la gestion du serveur (dans le bios uniquement 2 active , la gestion du serveur uniquement en local
Là non plus je ne sais pas ce que tu veux dire par 4+1. Par contre j'ai bien compris que tu as deux
cartes réseaux l'une branché à la box, l'autre relié au réseau local (via un switch ?).
Hors ligne
la passerelle et tous les clients utilisent les ports 80 , 8080 et 443 (pour le https il me semble) via le net .
donc enp6s0f0 et enp6s0f1 et IP serveur 192.168.1.10 et IP client 192.168.10.0/24
Dernière modification par anonyme (06-08-2019 14:27:59)
Dernière modification par anonyme (06-08-2019 14:39:00)
la machine windows qui utilise uniquement la passerelle (en IP fixe) fonctionne
les clients debian ne fonctionne pas
si je passe "input" en accept tout est correct dans la chaine "filter"
forward et output en accept pendant les tests
a priori le nat fait son taf , je sais pas ou j'ai mal fait
ps: le client avec nftables aussi , me suis fait piégé passé les règles en accept de filter , le souci est bien coté passerelle.
bien reçu une IP (dhcp) , mais pas de résolution de nom , ni de ping (nom ou ip) ni d internet.
la passerelle fonctionne normalement , j'ai le net mais pas de ping du client
le service dhcpd et le dns est sur la passerelle , le resolv.conf => nameserver 127.0.0.1
ce qui fonctionne bien en plus du nat c'est cette règle => "ct state established,related accept"
Dernière modification par anonyme (06-08-2019 16:51:08)
la passerelle et tous les clients utilisent les ports 80 , 8080 et 443 (pour le https il me semble) via le net .
Ce sont les ports pour quelles adresses, de quelles machines ? Parce qu'un port
tout seul comme ça, ça n'a pas beaucoup de sens.
Les sockets qui permettent la communication sur « le réseau » ont deux paires :
(adresse source, port source) et (addresse destination, port destination). Du
coup le port 80 tout seul par exemple, ne me permet pas de communiquer, il
manque trois autres éléments…
Il faut se souvenir que au plus simple, quand un programme demande une
connexion tcp/ip il faut qu'il donne l'adresse de destination et le port de
destination. L'adresse source qui sera donné à la socket dépendra du routage
(c'est à dire que ce sera l'adresse de l'interface de sortie) et le port est
lui aussi attribué par le noyau (enfin il me semble).
Si tu parles de filtrer les flux sortant provenant du sous réseau local pour
n'autoriser que ces ports sur les destination, c'est en général inutile.
pour revenir a la conf , il existe 3 types de "chain"
route
filtre
nat
Là également, je ne vois pas de quoi tu parles.
Il y a bien trois ces trois types de chaînes mais pour l'instant
on s'est limité à utiliser filter et nat que l'on a regroupé dans deux tables
différentes, filter et nat qu'on peut nommer à notre convenance. C'est juste plus
facile de regrouper toutes les chaînes de type filter dans une table qui a pour nom
filter.
Les chaînes de bases sont attachés à un hook du noyau (prerouting, input,
foward, output ou postrouting, et aussi ingress avant le hook prerouting, mais
on ne s'en servira pas).
Ensuite il y a les chaînes utilisateur comme celle que j'ai appelé local_in.
Aucun trafic ne passe dans ces chaînes tant qu'on a pas explicitement créé une
règle dans une chaîne de base pour y sauter (jump).
Les chaînes de base sont attachés à un hook. Par exemple la chaîne input
de la table filter pour la famille ip (c'est à dire ipv4) on a :
La ligne :
dit que cette chaîne est attaché au hook input du noyau et est
de type filter, et fixe aussi la priorité du traitement à 0.
En plus on dit que pour ce hook, la règle par défaut est de jeter
les paquets (drop).
Si il n'y avait pas cette information qui attache la chaîne au hook du
noyau, ce ne serait pas une chaîne de base. C'est une spécificité de
nftables par rapport à iptables. D'ailleurs cette chaîne, on peut lui
donner le nom qu'on veut, comme « entree » par exemple (je ne sais
pas si les caractères utf8 sont acceptés).
Hors ligne
la machine windows qui utilise uniquement la passerelle (en IP fixe) fonctionne
les clients debian ne fonctionne pas
Tu as mis les règles pour le nat ?
Le programmes qui fonctionnent sont à destination de quelle adresse ?
Même question pour ceux qui ne fonctionnent pas.
Quelles sont les adresses exactes de ces machines ? T'es sûr qu'elles sont
bien sur le même sous-réseau ? Regarde les masques de sous-réseau.
Edit : tu devrais pouvoir pinger la passerelle depuis les clients, tout en mettant
policy drop pour la chaîne input de type filter.
Dernière modification par enicar (06-08-2019 16:51:55)
Hors ligne
a priori le nat fait son taf
Remarque les paquets qui ne sont pas à destinations de la passerelle
passe dans la chaîne forward (et pas input) de la table filter.
Ensuite il sont naté (avec la masquerade) au niveau de la chaîne
postrouting de type nat.
Hors ligne
il me semble que avec iptables le dhcp n'a pas besoin de regles sur le pare-feu
pour les masques tu les connais
192.168.1.0/24 coté box
192.168.10.0/24 coté sous réseau
pour les programmes aucune idée de l'adresse , c'est bind9 qui la fourni , sauf pour windows ou c'est le DNS orange
pour le nat bien sur il est actif
Dernière modification par anonyme (06-08-2019 17:33:56)
ps: le client avec nftables aussi , me suis fait piégé passé les règles en accept de filter , le souci est bien coté passerelle.
bien reçu une IP (dhcp) , mais pas de résolution de nom , ni de ping (nom ou ip) ni d internet.
la passerelle fonctionne normalement , j'ai le net mais pas de ping du client
le service dhcpd et le dns est sur la passerelle , le resolv.conf => nameserver 127.0.0.1
ce qui fonctionne bien en plus du nat c'est cette règle => "ct state established,related accept"
Tout cela est un peu brouillon et j'ai du mal à m'y retrouver.
Pour le que le DNS marche il faut passer l'adresse de la passerelle
(192.168.10.1) dans les paramètre à passer au niveau du serveur dhcp
(sur la passerelle donc).
Il y a une autre solution, laisser la box gérer le DNS directement, pour cela
il suffit de créer une règle spécifique dans la chaîne forward pour le traffic
à destination de l'adresse de la box sur le port 53. Mais ce n'est pas
terrible.
Est-ce que du côté côté client tu as bien reçu la bonne ip pour le serveur DNS ?
Remarque que mettre dans le resolv.conf « nameserver 127.0.0.1 » ne marche que
sur la passerelle. Sur les machines de ton réseau local tu devrais avoir
« nameserver 192.168.10.1 ».
Par contre, sur les clients :
devrait fonctionner.
Tu pourrais logger tous les paquets qui sont refusés sur la passerelle,
en rajoutant log à la fin de la chaîne input de la table filter :
Remarque j'ai mis le jump sur local_in avant de passer à la moulinette du
suivi de connexion. C'est peut être ça qui bloquait.
Hors ligne
il me semble que avec iptables le dhcp n'a pas besoin de regles sur le pare-feu
C'est pareil, ça dépend comment c'est réglé.
Hors ligne
la machine windows est en IP fixe en dehors du dhcp et 192.168.10.xxx et elle a le DNS orange.
Sur quel réseau local se situe cette machine ?
Hors ligne
il me semble que avec iptables le dhcp n'a pas besoin de regles sur le pare-feu
pour les masques tu les connais
192.168.1.0/24 coté box
192.168.10.0/24 coté sous réseau
Ce n'est pas la question… la question c'était est-ce que les machines du réseau local récupère
le bon sous réseau et le bon masque. On peut faire faire n'importe quoi au serveur dhcp.
Hors ligne
pour les programmes aucune idée de l'adresse , c'est bind9 qui la fourni
Alors je suppose que tu parles du DNS, ça ne peut pas être bind qui fournit l'adresse
du DNS… Lui fournit le service du DNS, ce qui est bien différent. Mais avant
que cela soit possible, il faut qu'au niveau de la machine un « nameserver » soit
déclaré dans /etc/resolv.conf (à moins d'utiliser un autre système, mais on va rester
simple). Dans le cas où l'adresse ip est fixé par dhcp, la plupart du temps, c'est aussi
le serveur dhcp qui donne ce résolveur de nom. Ce n'est pas obligatoire, mais on fait très
souvent de cette façon. Pour cela il faut demander au serveur dhcp de donner l'adresse de la passerelle
au client. Ça fait partie des réglages du serveur dhcp. Ceci dit, je n'ai jamais fait, mais ça ne doit pas
être bien compliqué.
Hors ligne
le réseau local on s'en fou , seul mon fils a sa machine en windows (192.168.1.0/24 ) masque 255
on ne parle que du sous réseau de mes machines debian et une machine windows en IP fixe (192.168.10.0/24) masque 255
le DNS et le DHCP ne travaille que sur enp6s0f1 (le dns si il ne peu résoudre un nom va le prendre sur le net )
pour le sous réseau j'ai un domaine bidon (pas enregistré et que local) me permet de ping par nom de machine (ou par nom-machine.mondomaine )
le dhcpd met a jour bind9
comme ceci
le resolv.conf du serveur
celui du client
comme autre service celui du temps sur le serveur (paquet openntp il me semble )
la configuration du dhcpd
je passe sur le client et je te donne les informations
on ne parle que du sous réseau de mes machines debian et une machine windows en IP fixe (192.168.10.0/24) masque 255
Mais alors pourquoi la windows a une ip fixe ?
Hors ligne
le resolv.conf exact donné par le dhcpd
ping du serveur
ping de la machine windows a partir du client
inconnu du domaine et c'est très bien comme cela (c'est voulu)
idem pas de route du réseau local 192.168.1.0/24 vers le sous réseau 192.168.10.0/24 voulu aussi
du client je peu faire un ping de la box
idem pour un nom sur le net toujours du client
son hostname
son fichier host
voila pour les infos
Dernière modification par anonyme (06-08-2019 18:23:03)
parce que windows me pourri les logs du DNS local
Alors ça, c'est bizarre, à moins que ce soit une fonctionnalité
Hors ligne