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

#26 05-08-2019 14:08: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 :

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

#27 05-08-2019 17:52: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 :

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.


#!/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
        # le reste pour le filtrage de la chaîne input ici
    }

    chain forward {
        type filter hook forward priority filter; policy drop;
        ct state invalid limit rate 4/second log prefix "INVALID_INPUT " drop
        ct state established,related accept
        oifname "enp6s0f0" accept
        icmp type { destination-unreachable, time-exceeded, parameter-problem } 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;
    }
}
 


Comme ça la passerelle pourra laisser passer les flux vers internet,
ça peut être utile wink
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

#28 06-08-2019 11:01:56

anonyme
Invité

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

Bonjour
pour l'instant je suis sur une machine de bureau avec une seule carte réseau en client (le but reste quand même de basculer la passerelle en nftables).
il y a aussi une commande pour autoriser uniquement une série d IP (sur un sous-réseau par exemple ) pas testé
j'ai pas tout tester encore , imprimante en réseau , les jeux (steam par exemple) , serveur de temps , dhcpd , bind9 etc ..... ssh si besoin (j'en oublie peut être )

donc pour ma remarque ci dessous c'est pour le client


anonyme a écrit :

    pour le #22 c'est corrigé
    ça donne ceci
 


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  tongue  )
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  roll

#29 06-08-2019 12:19: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 une passerelle

Sur la passerelle pour la chaîne input de la table filter tu peux créer une chaĩne et séparer les flux
en entrée de l'interface côté réseau local, comme cela :



define passerelle_adr=192.168.1.1

table ip filter {
    chain local_in {
        icmp type { echo-request, echo-reply } accept
        ip daddr $passerelle_adr accept
        drop
    }

    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
        iifname "enps6s0f1" jump local_in
        # le reste pour le filtrage de la chaîne input ici
    }
    # Les chaînes forward et output ici
}
 


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 :


tcp dport 22 accept
 


Pour le dns sur le port 53


udp dport 53 accept
tcp dport 53 accept
 


On peut rajouter le dhcp de la même façon :


udp dport 67 accept
 


Puis le port pour CUPS :


tcp dport 631 accept
 


Ce qui donnerait pour la chaîne local_in


chain local_in {
    icmp type { echo-request, echo-reply } accept
    tcp dport 22 accept
    upd dport 53 accept
    tcp dport 53 accept
    udp dport 67 accept
    tcp dport 631 accept
    drop
}
 


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 :


chain local_in {
    icmp type { echo-request, echo-reply } accept
    tcp dport { 22, 53, 631 } accept
    upd dport { 53, 67 } accept
    drop
}
 


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

#30 06-08-2019 13:10:32

anonyme
Invité

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

tu va trop vite tongue
j'ai une petite question
j' utilise le copier/coller mais c'est pas propre , j' aimerai traiter ma (ou mes) tables avec les commandes "nft".
j'ai commencé a lire la doc , comment par exemple insérer une règle par exemple sur une table existante  , mais la dur dur pour moi.
je vais retenter le passage a nft sur la passerelle
pour les services oui j'ai vue , on peu utiliser http et https , 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)
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
uniquement 2 sont actives (un seul sous-réseau) , coté net 192.168.1.0/24 (box)  , coté sous-réseau 192.168.10.0/24.
une seule IP par interfaces , 192.168.1.10 et 192.168.10.1 (la passerelle pour les clients 192.16.10.1 et pour tous les services pour le sous réseau)
pas de ssh (ou uniquement en local sur 192.168.10.0/24 )

#31 06-08-2019 14:02: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

La syntaxe pour ajouter une règle avec nft en cli est :


nft add rule <table> <chain> <règle>
 



  • <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 :


nft add chain ip filter <new_chain>
 


Pour la supprimer :


nft delete chain ip filter <new_chain>
 

Hors ligne

#32 06-08-2019 14:08:54

anonyme
Invité

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

je suis en train de potasser et me faire une doc
une question pour ceci (foo)
exemple
% nft add chain ip foo input { type filter hook input priority 0 \; }
"foo" correspond a <table-name> , on peu l'ignorer ?

pour le reste ci dessus j'ai compris , modifier une "chain" c'est possible ? je vais chercher smile
pour l'instant j'ai add et delete et ne pas oublier le flush avant pour delete


Avant de pouvoir supprimer la chaîne, vous devrez vider le jeu de règles de cette chaîne.
avec
nft flush chain foo input
 

Dernière modification par anonyme (06-08-2019 14:12:18)

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

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 :

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 ?

anonyme a écrit :

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

#34 06-08-2019 14:27:26

anonyme
Invité

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

adsl => box => réseau local => switch manageable 1Gb => passerelle => switch 1Gb => sous-réseau local

c'est moi qui suis tordu roll  , le serveur 4 cartes réseau 1Gb (deux sont désactivées dans le bios) et une réservé a la maintenance du serveur
pour ceci


Je ne comprend pas… le port 80 sur quel interface et depuis quelle adresse ?
 


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)

#35 06-08-2019 14:34:31

anonyme
Invité

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

remarque:
a une époque j'ai fait du "bonding" (pas sur du terme) mais ridicule couplé 2 cartes  réseau 1Gb (pour doublé le débit) avec une ADSL pourri mais pour le fun tongue
le switch est compatible coté box
sûrement des traces sur le forum .............

pour revenir a la conf , il existe 3 types de "chain"
route
filtre
nat

Dernière modification par anonyme (06-08-2019 14:39:00)

#36 06-08-2019 16:36:33

anonyme
Invité

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

ça bloque ici


table ip filter {
        chain local_in {
                icmp type { echo-request, echo-reply } accept
                ip daddr 192.168.10.1 accept
                }

        chain INPUT {
                type filter hook input priority 0; policy accept;
                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 "enps6s0f1" jump local_in
        }

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

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



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)

#37 06-08-2019 16:43:06

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 :

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.

anonyme a écrit :

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 :


table ip filter {
    chain input {
        type filter hook input priority 0; policy drop;
        # le reste des règles ici
    }
}
 


La ligne :


type filter hook input priority 0; policy drop;
 


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

#38 06-08-2019 16:49:00

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 :

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

#39 06-08-2019 16:55:06

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 :

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

#40 06-08-2019 17:03:56

anonyme
Invité

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

certain c'est isc-dhcp-server qui donne les IP en 192.168.10.0/24 au client
la machine windows est en IP fixe en dehors du dhcp et 192.168.10.xxx et elle a le DNS orange.
pour le client du test par exemple 192.168.10.47
elle est ici


Aug  6 16:45:00 debian1 dhcpd[877]: DHCPDISCOVER from 60:45:cb:62:f6:93 via enp6s0f1
Aug  6 16:45:01 debian1 dhcpd[877]: DHCPOFFER on 192.168.10.47 to 60:45:cb:62:f6:93 (raven2200g) via enp6s0f1
Aug  6 16:45:01 debian1 dhcpd[877]: DHCPREQUEST for 192.168.10.47 (192.168.10.1) from 60:45:cb:62:f6:93 (raven2200g) via enp6$
Aug  6 16:45:01 debian1 dhcpd[877]: DHCPACK on 192.168.10.47 to 60:45:cb:62:f6:93 (raven2200g) via enp6s0f1
 



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


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

#41 06-08-2019 17:06:49

anonyme
Invité

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

non le ping ne fonctionne ni de la passerelle ni du client dés que je passe "input" en "drop"

j'ai commencé par input (forward est resté en accept).
j'ai du faire une erreur quelque part  hmm

pour le pare feu , nftables est efficace tongue , je vais le laisser comme actuellement et réfléchir a tête reposé
actuellement comme ceci


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 {
    icmp type { echo-request, echo-reply } accept
    ip daddr 192.168.10.1 accept
    }

  chain INPUT {
    type filter hook input priority 0; policy accept;
    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 "enps6s0f1" jump local_in
  }

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

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

Dernière modification par anonyme (06-08-2019 17:33:56)

#42 06-08-2019 17:29:11

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 :

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 :


ping 192.168.10.1
 


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 :


table ip filter {
    chain local_in {
        icmp type { echo-request, echo-reply } accept
        ip daddr 192.168.10.1 accept
        }

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

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


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

#43 06-08-2019 17:30:00

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 :

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

#44 06-08-2019 17:30:55

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 :

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

#45 06-08-2019 17:32:59

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 :

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

#46 06-08-2019 17:44:11

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 :

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

#47 06-08-2019 17:53:50

anonyme
Invité

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

je vais commencer par le #42
le fichier interfaces du serveur


# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

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
 


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


$TTL 3600 ; 1 hour
47      PTR raven2200g.mondomaine.
 


le resolv.conf du serveur


nameserver 127.0.0.1
 


celui du client


nameserver 192.168.10.1
 


comme autre service celui du temps sur le serveur (paquet openntp il me semble )
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;
 


je passe sur le client et je te donne les informations

#48 06-08-2019 17:57:30

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 :

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

#49 06-08-2019 18:02:23

anonyme
Invité

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

parce que windows me pourri les logs du DNS local
son IP  192.168.10.249
le DNS 81.253.149.10
passerelle par défaut 192.168.10.1

je passe maintenant sur le client linux en dhcp

voila pour la machine debian 10
le fichier interfaces


# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

source /etc/network/interfaces.d/*

# The loopback network interface
auto lo
iface lo inet loopback

# interface enp6s0
#allow-hotplug enp6s0
auto enp6s0
iface enp6s0 inet dhcp
 


le resolv.conf exact donné par le dhcpd


domain mondomain
search mondomain
nameserver 192.168.10.1
 



ping du serveur


ping -c4 debian1
 



PING debian1.mondomaine (192.168.10.1) 56(84) bytes of data.
64 bytes from debian1.mondomaine (192.168.10.1): icmp_seq=1 ttl=64 time=0.335 ms
64 bytes from debian1.mondomaine (192.168.10.1): icmp_seq=2 ttl=64 time=0.365 ms
64 bytes from debian1.mondomaine (192.168.10.1): icmp_seq=3 ttl=64 time=0.336 ms
64 bytes from debian1.mondomaine (192.168.10.1): icmp_seq=4 ttl=64 time=0.358 ms

--- debian1.mondomaine ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 32ms
rtt min/avg/max/mdev = 0.335/0.348/0.365/0.022 ms
 



ping de la machine windows a partir du client


ping -c4 192.168.10.249
PING 192.168.10.249 (192.168.10.249) 56(84) bytes of data.

--- 192.168.10.249 ping statistics ---
4 packets transmitted, 0 received, 100% packet loss, time 75ms
 


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


ping -c4 192.168.1.1
PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
64 bytes from 192.168.1.1: icmp_seq=1 ttl=63 time=1.03 ms
64 bytes from 192.168.1.1: icmp_seq=2 ttl=63 time=0.979 ms
64 bytes from 192.168.1.1: icmp_seq=3 ttl=63 time=0.981 ms
64 bytes from 192.168.1.1: icmp_seq=4 ttl=63 time=0.926 ms

--- 192.168.1.1 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 6ms
rtt min/avg/max/mdev = 0.926/0.977/1.025/0.051 ms
 


idem pour un nom sur le net toujours du client


ping -c4 google.fr
PING google.fr (216.58.209.227) 56(84) bytes of data.
64 bytes from par10s29-in-f3.1e100.net (216.58.209.227): icmp_seq=1 ttl=53 time=24.0 ms
64 bytes from par10s29-in-f3.1e100.net (216.58.209.227): icmp_seq=2 ttl=53 time=25.2 ms
64 bytes from par10s29-in-f3.1e100.net (216.58.209.227): icmp_seq=3 ttl=53 time=24.10 ms
64 bytes from par10s29-in-f3.1e100.net (216.58.209.227): icmp_seq=4 ttl=53 time=25.2 ms

--- google.fr ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 6ms
rtt min/avg/max/mdev = 24.006/24.839/25.229/0.527 ms
 



son hostname


raven2200g
 


son fichier host


127.0.0.1 localhost
127.0.1.1 raven2200g

# The following lines are desirable for IPv6 capable hosts
::1     localhost ip6-localhost ip6-loopback
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
 


voila pour les infos

Dernière modification par anonyme (06-08-2019 18:23:03)

#50 06-08-2019 18:19:03

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 :

parce que windows me pourri les logs du DNS local


Alors ça, c'est bizarre, à moins que ce soit une fonctionnalité big_smile

Hors ligne

Pied de page des forums