Vous n'êtes pas identifié(e).
Hors ligne
ps: oublié exim4 , le port 25 a ouvrir
je passe sur le serveur ( il est parfait mon sous-réseau local )
voila sur le serveur
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)
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
Hors ligne
Hors ligne
Hors ligne
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
bon on fait une pause pour ce soir , j'ai bien avancé quand même
il fait très chaud chez moi
Dernière modification par anonyme (06-08-2019 19:05:41)
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 :
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
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
Hors ligne
voici le nftables.conf
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"
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 :
Voilà ce que c'est de ne pas savoir copier correctement un nom
Dernière modification par enicar (07-08-2019 12:06:12)
Hors ligne
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
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
mais
voila le résultat quand on comprend pas ce que l'on fait
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)
d'accord avec toi mais il était tard ou très tôt , comme tu préfère
sur la passerelle pas exactement le même que toi (en #62) , faut que je mette a jour
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.
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
actuellement on a un drop sur "enp6s0f0" et accept sur "enp6s0f1" ?
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
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
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 ?
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)
je regarde le souci exact , il suffit de supprimer le fichier paniclog et de résoudre ce qui la provoquer
je redémarre le serveur
Dernière modification par anonyme (07-08-2019 13:49:48)
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
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.
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
Là je ne vois pas du tout où tu veux venir…
Hors ligne
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
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
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 :
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
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
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