Re: Quel firewall pour Buster et au delà ?

[Thierry Despeyroux]

non pas de date fixée

Le Fri, 11 Jan 2019 16:23:44 +0100,
Wallace  a écrit :

> Le 11/01/2019 à 16:05, didier gaumet a écrit :
> >
> > Alors je suis une truffe pour tout ce qui est réseaux mais j'ai
> > quand même l'impression qu'il y a un quiproquo sur
> > nftables/firewalld, non?
> >
> > Firewalld n'est qu'une surcouche à, auparavant iptables, désormais
> > nftables? Un peu comme Shorewall  
> Aucune idée je n'ai pas encore creusé le sujet.
> >
> > D'après ce que j'ai compris, le paquet iptables sera dans la
> > prochaine version Debian et ne sera pas un pseudo-paquet pointant
> > vers nftables, mais utilisera le backend nftables dans le noyau
> > mais en conservant la syntaxe iptables? Et si on souhaite utiliser
> > véritablement nftables, il est possible (au moins pour le moment)
> > d'utiliser l'ancienne syntaxe iptables ou la nouvelle syntaxe
> > dédiée nftables?  
> 
> Ca voudrait donc dire que iptables ne fait plus parti du kernel?
> 
> J'ai rien trouvé en news à ce sujet.
> 
> Néanmoins quand on voit un article comme celui là :
> 
> https://cilium.io/blog/2018/04/17/why-is-the-kernel-community-replacing-iptables/
> 
> On peut se dire que nftables est un remplaçant à peine plus
> performant. BPF semble bien plus prometteur pour les réseaux à plus
> de 10Gbs.
> 
> >
> > Didier, truffe réseau en mal de culture ad-hoc ;-)  
> On ne peut pas tout maitriser et j'avoue avoir un peu lâcher ce sujet
> vu qu'iptables fait le boulot et qu'on a pas encore été confronté à
> des interfaces à plus de 10Gbs...
> 

Re: Réseau : accès VPN et LAN simultanés

[roger . tarani]

- Original Message -
> From: "Pascal Hambourg" 
> To: debian-user-french@lists.debian.org
> Sent: Friday, January 11, 2019 9:16:14 PM
> Subject: Re: Réseau : accès VPN et LAN simultanés
> 
> Le 10/01/2019 à 15:28, roger.tar...@free.fr a écrit :
> > 
> >> From: "Pascal Hambourg" 
> >>
> >> Serait-il possible de configurer ton logiciel de messagerie pour
> >> citer
> >> correctement (avec des marques de citation ">") le message auquel
> >> tu
> >> réponds, parce que là c'est difficile à lire.
> > 
> > Voilà c'est fait !
> > C'est possible avec Zimbra : (Préférences/Composition
> > d'emails/Utiliser un préfixe des emails inclus ou retransmis)
> 
> Il y a qund même un défaut gênant : cela retaille les lignes citées
> avec
> des retours à la ligne intempestifs. Les lignes de texte original
> sont
> coupées à 72 caractères pour permettre d'ajouter plusieurs niveaux de
> citation sans dépasser 80 caractères.
> 
Là je n'ai pas trouvé d'autres options de composition d'emailsTu utiles quoi 
comme client de messagerie ?

> > Je me demande bien pourquoi raspbian donne la possibilité à
> > l'utilisateur pi (qui n'est pas root) d'exécuter du code dans sbin
> > normalement réservé à root. Même sudo ne demande pas le mot de
> > passe de l'utilisateur pi. C'est sans doute pour faciliter la vie
> > de l'utilisateur qui débute en Linux avec un pi.
> 
> Certains commandes de /sbin ou /usr/sbin comme ip ou ifconfig peuvent
> être exécutées par un utilisateur standard pour réaliser des
> opérations
> de consultation en lecture seule qui ne nécessitent pas de
> privilèges.
> Mais ce n'est pas d'iptables.
> 
> 
Ok.

>  MACHINE 2
> >> (...)
>  192.168.0.0/24 via FREEBOX_IP dev tun0
> >>>
> >>> Cette route est erronée. Elle ne devrait pas exister et est la
> >>> cause
> >>> probable de la perte de connectivité entre les deux machines :
> >>> celle-ci
> >>> croit que l'autre est joignable via le VPN, mais le serveur de
> >>> VPN ne
> >>> route pas ce préfixe.
> >>>
> >>> Si elle est mise en place par l'ouverture du VPN, il faut
> >>> rechercher
> >>> quelle est l'option erronée qui la crée dans la configuration VPN
> >>> du
> >>> client (route) ou du serveur (push).
> >>>
> >>> Réponse :
> >>> ce résultat de ip route correspond à une situation avec
> >>> connectivité via VPN ou via LAN entre les 2 machines.
> >>
> >> Je ne comprends pas ce que tu veux dire.
> 
> Peux-tu expliquer ta réponse ?
> 
> 
Le résultat de la commande 'ip route' est obtenu alors que la configuration 
réseau permet aux deux machines de communiquer ensemble via le LAN OU/ET le VPN.

Peux-tu montrer un exemple de route qui est bonne ?


> >>> J'ai fait un test en modifiant /etc/network/interfaces
> >>> où j'ai commenté les directives (optionnelles) qui sont absentes
> >>> de
> >>> l'autre machine qui
> >>> # gateway 192.168.0.1
> >>
> >> Si l'interface est configurée avec la méthode "static", l'absence
> >> de
> >> l'option gateway l'empêchera d'atteindre l'extérieur du réseau.
> >>
> > ça doit fonctionner car il y a aussi cette ligne :
> >   dns-nameservers 192.168.0.1 8.8.8.8
> 
> Rien à voir. C'est pour la configuration DNS.
> 
> > C'est sans doute cette directive qui permet à la machine de trouver
> > la gateway.
> 
> Non, pas du tout. Les serveurs DNS servent à la résolution de noms et
> n'ont aucun rôle dans le routage IP.
> 
> 
Ok.


> >>> En même temps, le client vpn ne gère-il pas son affaire grâce à
> >>> la
> >>> directive ajouté au fichier de conf ? (route 192.168.40.0
> >>> 255.255.255.0 net_gateway)
> >>
> >> Cette directive est juste une rustine qui sert à masquer une
> >> erreur de
> >> configuration.
> > 
> > Peut-on se passer de cette rustine ?
> 
> Normalement oui puisque machine 1 n'avait pas cette route erronée.
> Tu pourrais montrer la configuration openvpn des deux machines ?
> 
> 
Voici le fichier de configuration openvpn, 
identique pour MACHINE 1 et MACHINE 2 :

  client
  remote SERVER_VPN_IP 6504
  proto udp
  nobind
  dev-type tun
  
  # rustine pour contourner un pb de mauvaise configuration réseau
  # et permettre une comm simultanée via LAN ET via VPN
  # auparavant, c'était LAN ou bien VPN 
  route 192.168.0.0 255.255.255.0 net_gateway

  pull
  dev tun0
  redirect-gateway
  # auth-user-pass # config initialement fournie par Serveur VPN Freebox
  auth-user-pass login.txt
  auth-retry interact
  fragment 1452
  mssfix 1452
  explicit-exit-notify 3
  cipher AES-256-CBC
  remote-cert-tls server
  verify-x509-name "C=FR, O=Freebox SA, CN=Freebox OpenVPN server 
NOMBRE_HEXA_32_CARAC>"


A l'original produit par leserveur openvpn Freebox, j'ai juste :
- ajouté une directive pour lire un fichier login.txt
- ajouté ta rustine

Voilà.

Re: Configuration réseau

[roger . tarani]

- Original Message -


From: "Alban Vidal"  
To: debian-user-french@lists.debian.org, "roger tarani"  
Cc: "Gaëtan Perrier"  
Sent: Friday, January 11, 2019 8:10:06 PM 
Subject: Re: Configuration réseau 

Bonsoir, 

Sur mon PC portable je suis allé au plus simple, je gère tout avec NM aussi. 

Ça fait un moment que j'ai pas monté mon vpn, mais j'avais un petit soucis pour 
configurer le DNS en automatique une fois le tunnel monté (pour utiliser mon 
DNS qui se trouve à cote du vpn), il me semble que j'avais résolu simplement en 
installant resolvconf. 

Si tu veux gérer en ligne de commande, tu as ce qu'il faut pour t'aider, de 
tête c'est les commandes "nmcli" et "nmgui". 





D'installé, j'ai nmcli et nmtui (Text User Interface/curses-based comme 
l'installeur Debian). 
nmgui, ça n'est pas installé sur ma machine. 

C'est difficile de trouver de la doc claire sur debian.org . Le problème, c'est 
qu'il y a un tas de vieux trucs, qui parlent du fichier resolv.conf, du 
programme resolvconf (...!!) , des legacy methods, etc. 

J'ai trouvé cet article archlinux qui me semble complet et récent (dernière màj 
2019) : 
https://wiki.archlinux.org/index.php/NetworkManager 

On y apprend que : 
Gnome a ce qui ce qu'il faut (j'utilise Gnome). 
KDE Plasma a besoin du paquet plasma-nm. 
etc... 

nmgui : je n'ai pas. 

Je crains que NM ne fasse pas tout ce que je veux, ou fasse des trucs dans mon 
dos. 
Justement, l'article suivant parle du problème de "paramètres introduits par NM 
dans la configuration réseau d'une machine" ("Because of the extra variables it 
introduces into the state of a test machine’s networking configuration"): 
https://support.qacafe.com/knowledge-base/how-do-i-prevent-network-manager-from-controlling-an-interface/
 

Il suggère trois solutions : 
- Configure Network Manager to ignore test interfaces 
- Manually stop Network Manager 
- Remove Network Manager from the system 
Mais comme on veut pouvoir utiliser NM pour gérer aisément les interfaces 
habituelles qui ne sont pas des interfaces de test, il propose de configurer NM 
pour qu'il IGNORE les interfaces de test. En modifiant 
/etc/NetworkManager/NetworkManager.conf selon 2 méthodes, ou en créant des 
règles udev. 

Que pensez-vous de cette solution ? 

Comment configures-tu ta machine pour pouvoir gérer, par exemple, ton openvpn 
en CLI ou en GUI tout en étant sûr qu'elle reste dans un état cohérent ? 
Cad pour que NM n'indique pas autre chose que l'état assuré/observé par 
systemd, ou bien n'affiche pas des choses en différé. 
Par exemple, avec du Mobile broadband (3G/4G), j'ai déjà vu la connexion 
indisponible via le GUI car un menu déroulant ne sélectionnait plus la dernière 
configuration valide de l'opérateur télécom. Il faut alors reconfigurer en 
sélectionnant cette config réseau, parfois parmis un certain nombre. Pour un 
utilisateur normal c'est perturbant. 
Voilà le genre d'expériences que j'ai eue avec NM. 

Merci 

PS 
Voilà ce qu'il y a d'installé : 
$ dpkg -l | grep network-manager 
network-manager 0.9.10.0-7 
network-manager-gnome 0.9.10.0-2 
network-manager-openvpn 0.9.10.0-1 
network-manager-openvpn-gnome 0.9.10.0-1 

$ dpkg -l | grep network 
renvoie toutes les libs 

$ nmcli dev status 
DEVICE TYPE STATE CONNECTION 
tun0 tun connected tun0 
eth0 ethernet unmanaged -- 

lo loopback unmanaged -- 





Concernant la question sur le /etc/hosts et l'adresse des autres PC, soit il 
faut faire à la main, soit faire confiance à la résolution DNS de la box, soit 
monter son DNS + DHCP. 

Bon courage, 

Alban 


Le 11 janvier 2019 19:45:50 GMT+01:00, roger.tar...@free.fr a écrit : 



- Original Message -


From: "Gaëtan Perrier"  
To: debian-user-french@lists.debian.org, "roger tarani" , 
"Liste Debian"  
Sent: Friday, January 11, 2019 7:12:59 PM 
Subject: Re: Configuration réseau 

Salut, 

Si tu as Network Manager a part besoin spécifique tu ne devrais pas avoir à 
utiliser /etc/network/interfaces ni resolvconf. Tout devrait se passer dans NM. 

Gaëtan 






Argh ! 
C'est tout ? 
J'ai tellement entendu du mal de NM de la part de gens de réseaux à propos de 
ses "bugs" (pas récemment mais il y a environ 4 ans) et j'ai une mauvaise 
expérience avec NM, alors je l'ai mis de côté. 
Etait-ce vrai ? 



En bref, inutile de faire sudo apt-get install network-manager-gnome car NM est 
déjà installé. 

Vu ce que j'ai dans le menu All settings/network (juste network proxy), et je 
gère mon client openvpn avec systemctl, la question est : 
comment configurer correctement l'outil NM ? 


Au fait, tu parles de NM en CLI ou de NM graphique ? 

Parce que je veux pouvoir gérer mes réseaux en CLI (et tout, d'ailleurs). 

et parce que j'ai souvent observé que NM graphique était désynchronisé de ce 
qui se passait sous le capot 



Merci. 



Le 11 janvier 2019 19:04:33 GMT+01:00, roger.tar...@free.fr a écrit : 

Bonjour, 

J'ouvre un fil distinct sur la gestion des fichiers /etc/resolv.conf et 
/etc/hosts . 
Je suis embêt

Re: Réseau : accès VPN et LAN simultanés

[Pascal Hambourg]

Le 10/01/2019 à 15:28, roger.tar...@free.fr a écrit :



From: "Pascal Hambourg" 

Serait-il possible de configurer ton logiciel de messagerie pour
citer
correctement (avec des marques de citation ">") le message auquel tu
réponds, parce que là c'est difficile à lire.


Voilà c'est fait !
C'est possible avec Zimbra : (Préférences/Composition d'emails/Utiliser un 
préfixe des emails inclus ou retransmis)


Il y a qund même un défaut gênant : cela retaille les lignes citées avec 
des retours à la ligne intempestifs. Les lignes de texte original sont 
coupées à 72 caractères pour permettre d'ajouter plusieurs niveaux de 
citation sans dépasser 80 caractères.



Je me demande bien pourquoi raspbian donne la possibilité à l'utilisateur pi 
(qui n'est pas root) d'exécuter du code dans sbin normalement réservé à root. 
Même sudo ne demande pas le mot de passe de l'utilisateur pi. C'est sans doute 
pour faciliter la vie de l'utilisateur qui débute en Linux avec un pi.


Certains commandes de /sbin ou /usr/sbin comme ip ou ifconfig peuvent 
être exécutées par un utilisateur standard pour réaliser des opérations 
de consultation en lecture seule qui ne nécessitent pas de privilèges. 
Mais ce n'est pas d'iptables.




MACHINE 2

(...)

192.168.0.0/24 via FREEBOX_IP dev tun0


Cette route est erronée. Elle ne devrait pas exister et est la cause
probable de la perte de connectivité entre les deux machines : celle-ci
croit que l'autre est joignable via le VPN, mais le serveur de VPN ne
route pas ce préfixe.

Si elle est mise en place par l'ouverture du VPN, il faut rechercher
quelle est l'option erronée qui la crée dans la configuration VPN du
client (route) ou du serveur (push).

Réponse :
ce résultat de ip route correspond à une situation avec
connectivité via VPN ou via LAN entre les 2 machines.


Je ne comprends pas ce que tu veux dire.


Peux-tu expliquer ta réponse ?



J'ai fait un test en modifiant /etc/network/interfaces
où j'ai commenté les directives (optionnelles) qui sont absentes de
l'autre machine qui
# gateway 192.168.0.1


Si l'interface est configurée avec la méthode "static", l'absence de
l'option gateway l'empêchera d'atteindre l'extérieur du réseau.


ça doit fonctionner car il y a aussi cette ligne :
  dns-nameservers 192.168.0.1 8.8.8.8


Rien à voir. C'est pour la configuration DNS.


C'est sans doute cette directive qui permet à la machine de trouver la gateway.


Non, pas du tout. Les serveurs DNS servent à la résolution de noms et 
n'ont aucun rôle dans le routage IP.




En même temps, le client vpn ne gère-il pas son affaire grâce à la
directive ajouté au fichier de conf ? (route 192.168.40.0
255.255.255.0 net_gateway)


Cette directive est juste une rustine qui sert à masquer une erreur de
configuration.


Peut-on se passer de cette rustine ?


Normalement oui puisque machine 1 n'avait pas cette route erronée.
Tu pourrais montrer la configuration openvpn des deux machines ?

Re: Configuration réseau

[Alban Vidal]

Bonsoir,

Sur mon PC portable je suis allé au plus simple, je gère tout avec NM aussi.

Ça fait un moment que j'ai pas monté mon vpn, mais j'avais un petit soucis pour 
configurer le DNS en automatique une fois le tunnel monté (pour utiliser mon 
DNS qui se trouve à cote du vpn), il me semble que j'avais résolu simplement en 
installant resolvconf.

Si tu veux gérer en ligne de commande, tu as ce qu'il faut pour t'aider, de 
tête c'est les commandes "nmcli" et "nmgui".

Concernant la question sur le /etc/hosts et l'adresse des autres PC, soit il 
faut faire à la main, soit faire confiance à la résolution DNS de la box, soit 
monter son DNS + DHCP.

Bon courage,

Alban

Le 11 janvier 2019 19:45:50 GMT+01:00, roger.tar...@free.fr a écrit :
>- Original Message -
>
>> From: "Gaëtan Perrier" 
>> To: debian-user-french@lists.debian.org, "roger tarani"
>> , "Liste Debian"
>> 
>> Sent: Friday, January 11, 2019 7:12:59 PM
>> Subject: Re: Configuration réseau
>
>> Salut,
>
>> Si tu as Network Manager a part besoin spécifique tu ne devrais pas
>> avoir à utiliser /etc/network/interfaces ni resolvconf. Tout devrait
>> se passer dans NM.
>
>> Gaëtan
>
>Argh ! 
>C'est tout ? 
>J'ai tellement entendu du mal de NM de la part de gens de réseaux à
>propos de ses "bugs" (pas récemment mais il y a environ 4 ans) et j'ai
>une mauvaise expérience avec NM, alors je l'ai mis de côté. 
>Etait-ce vrai ? 
>
>En bref, inutile de faire sudo apt-get install network-manager-gnome
>car NM est déjà installé. 
>
>Vu ce que j'ai dans le menu All settings/network (juste network proxy),
>et je gère mon client openvpn avec systemctl, la question est : 
>comment configurer correctement l'outil NM ? 
>
>Au fait, tu parles de NM en CLI ou de NM graphique ? 
>
>Parce que je veux pouvoir gérer mes réseaux en CLI (et tout,
>d'ailleurs). 
>
>et parce que j'ai souvent observé que NM graphique était désynchronisé
>de ce qui se passait sous le capot 
>
>Merci. 
>
>> Le 11 janvier 2019 19:04:33 GMT+01:00, roger.tar...@free.fr a écrit :
>> > Bonjour,
>> 
>
>> > J'ouvre un fil distinct sur la gestion des fichiers
>> > /etc/resolv.conf
>> > et /etc/hosts .
>> 
>> > Je suis embêté par des problèmes de réseau depuis plusieurs jours.
>> > Et
>> > ce doit être l'occasion de les régler une bonne fois pour toutes et
>> > que ça serve à d'autres.
>> 
>
>> > A partir de ma modeste expérience et après avoir lu de nombreuses
>> > docs et forums, j'en suis arrivé à (croire) la chose suivante :
>> 
>
>> > 1/ pour un serveur
>> 
>> > /etc/nsswitch.conf doit être normalement correct et dire où et dans
>> > quel ordre allers chercher (files, dns...)
>> 
>> > On configure statiquement
>> 
>> > /etc/network/interfaces
>> 
>> > /etc/resolv.conf
>> 
>> > Ça marche et puis c'est tout.
>> 
>
>> > 2/ pour une machine amenée à changer souvent de configuration
>> > réseau
>> > (machine de dev, PC portable, etc.), on utilise des programmes
>> > censés nous simplifier la vie. Humm...
>> 
>> > En particulier, la doc Debian rappelle que le fichier resolv.conf
>> > est
>> > dynamiquement modifié par divers programmes (le démon
>> > network-manager, le programme resolvconf, les clients DHCP, etc.
>> > sans comter les services systemd, commandes service ou systemctl).
>> 
>> > En pratique (de mon expérience), j'observe un comportement bizarre
>> > des "outils censés me simplifier la vie".
>> 
>
>> > Je ne suis pour l'instant pas arrivé à conclure plus que :
>> 
>> > On dispose de /etc/nsswitch.conf qui doit être normalement correct
>> > (bonne distribution !)
>> 
>
>> > On configure
>> 
>> > /etc/network/interfaces
>> 
>
>> > Et ensuite... resolvconf, Networkmanager, etc.
>> 
>> > Je vous pose la question plutôt que de bidouiller une synthèse
>> > bancale.
>> 
>
>> > Sur une machine Debian, comment configurez-vous fiablement les
>> > programmes qui configurent votre réseau ?
>> 
>
>> > Pour /etc/hosts, je le fais à la main.
>> 
>> > Comment gérez-vous ce fichier /etc/hosts dans un (petit) réseau de
>> > plusieurs machines ?
>> 
>
>> > Merci
>> 
>
>> --
>> Envoyé de mon appareil Android avec Courriel K-9 Mail. Veuillez
>> excuser ma brièveté.

-- Envoyé depuis mon mobile /e/ - e.foundation

Re: Quel firewall pour Buster et au delà ?

[didier gaumet]

Le 11/01/2019 à 18:13, Olivier a écrit :
> 
> Justement, j'ai compris que BPF, c'était la cuisine interne de Linux: on
> configure avec nftables ou firewalld ou autre et c'est nftables qui
> s'appuie sur BPF à l'insu de l'administrateur.
> Bien entendu, je peux avoir compris de travers  et je serai ravi qu'une
> personne plus qualifiée que moi me corrige ;-)))

Je connaissais l'existence des différentes versions de (Berkeley) Packet
Filter ((B)PF) dans les différentes versions de BSD en tant que pare-feu.

De ce que je crois comprendre, Linux utilise déjà certaines briques de
l'infrastructure BPF (qui serait une interface aux couches réseau plus
qu'un simple pare-feu) et dont la pure partie pare-feu n'aurait jamais
été intégrée à Linux ni à ses distributions. eBPF est la prochaine
itération de BPF qui semble offrir des possibilités tellement
avantageuses par rapport à l'existant que Linux cherche à en profiter,
l'une des possibilités étant de la faire fonctionner en coordination
avec nftables.

Tout ça au conditionnel parce que signé La Truffe Réseau ;-)

Re: Configuration réseau

[roger . tarani]

- Original Message -

> From: "Gaëtan Perrier" 
> To: debian-user-french@lists.debian.org, "roger tarani"
> , "Liste Debian"
> 
> Sent: Friday, January 11, 2019 7:12:59 PM
> Subject: Re: Configuration réseau

> Salut,

> Si tu as Network Manager a part besoin spécifique tu ne devrais pas
> avoir à utiliser /etc/network/interfaces ni resolvconf. Tout devrait
> se passer dans NM.

> Gaëtan

Argh ! 
C'est tout ? 
J'ai tellement entendu du mal de NM de la part de gens de réseaux à propos de 
ses "bugs" (pas récemment mais il y a environ 4 ans) et j'ai une mauvaise 
expérience avec NM, alors je l'ai mis de côté. 
Etait-ce vrai ? 

En bref, inutile de faire sudo apt-get install network-manager-gnome car NM est 
déjà installé. 

Vu ce que j'ai dans le menu All settings/network (juste network proxy), et je 
gère mon client openvpn avec systemctl, la question est : 
comment configurer correctement l'outil NM ? 

Au fait, tu parles de NM en CLI ou de NM graphique ? 

Parce que je veux pouvoir gérer mes réseaux en CLI (et tout, d'ailleurs). 

et parce que j'ai souvent observé que NM graphique était désynchronisé de ce 
qui se passait sous le capot 

Merci. 

> Le 11 janvier 2019 19:04:33 GMT+01:00, roger.tar...@free.fr a écrit :
> > Bonjour,
> 

> > J'ouvre un fil distinct sur la gestion des fichiers
> > /etc/resolv.conf
> > et /etc/hosts .
> 
> > Je suis embêté par des problèmes de réseau depuis plusieurs jours.
> > Et
> > ce doit être l'occasion de les régler une bonne fois pour toutes et
> > que ça serve à d'autres.
> 

> > A partir de ma modeste expérience et après avoir lu de nombreuses
> > docs et forums, j'en suis arrivé à (croire) la chose suivante :
> 

> > 1/ pour un serveur
> 
> > /etc/nsswitch.conf doit être normalement correct et dire où et dans
> > quel ordre allers chercher (files, dns...)
> 
> > On configure statiquement
> 
> > /etc/network/interfaces
> 
> > /etc/resolv.conf
> 
> > Ça marche et puis c'est tout.
> 

> > 2/ pour une machine amenée à changer souvent de configuration
> > réseau
> > (machine de dev, PC portable, etc.), on utilise des programmes
> > censés nous simplifier la vie. Humm...
> 
> > En particulier, la doc Debian rappelle que le fichier resolv.conf
> > est
> > dynamiquement modifié par divers programmes (le démon
> > network-manager, le programme resolvconf, les clients DHCP, etc.
> > sans comter les services systemd, commandes service ou systemctl).
> 
> > En pratique (de mon expérience), j'observe un comportement bizarre
> > des "outils censés me simplifier la vie".
> 

> > Je ne suis pour l'instant pas arrivé à conclure plus que :
> 
> > On dispose de /etc/nsswitch.conf qui doit être normalement correct
> > (bonne distribution !)
> 

> > On configure
> 
> > /etc/network/interfaces
> 

> > Et ensuite... resolvconf, Networkmanager, etc.
> 
> > Je vous pose la question plutôt que de bidouiller une synthèse
> > bancale.
> 

> > Sur une machine Debian, comment configurez-vous fiablement les
> > programmes qui configurent votre réseau ?
> 

> > Pour /etc/hosts, je le fais à la main.
> 
> > Comment gérez-vous ce fichier /etc/hosts dans un (petit) réseau de
> > plusieurs machines ?
> 

> > Merci
> 

> --
> Envoyé de mon appareil Android avec Courriel K-9 Mail. Veuillez
> excuser ma brièveté.

Configuration réseau

[roger . tarani]

Bonjour,

J'ouvre un fil distinct sur la gestion des fichiers /etc/resolv.conf et 
/etc/hosts .
Je suis embêté par des problèmes de réseau depuis plusieurs jours. Et ce doit 
être l'occasion de les régler une bonne fois pour toutes et que ça serve à 
d'autres.

A partir de ma modeste expérience et après avoir lu de nombreuses docs et 
forums, j'en suis arrivé à (croire) la chose suivante :

1/ pour un serveur
/etc/nsswitch.conf doit être normalement correct et dire où et dans quel ordre 
allers chercher (files, dns...)
On configure statiquement 
  /etc/network/interfaces
  /etc/resolv.conf
Ça marche et puis c'est tout.

2/ pour une machine amenée à changer souvent de configuration réseau (machine 
de dev, PC portable, etc.), on utilise des programmes censés nous simplifier la 
vie. Humm...
En particulier, la doc Debian rappelle que le fichier resolv.conf est 
dynamiquement modifié par divers programmes (le démon network-manager, le 
programme resolvconf, les clients DHCP, etc. sans comter les services systemd, 
commandes service ou systemctl).
En pratique (de mon expérience), j'observe un comportement bizarre des "outils 
censés me simplifier la vie".

Je ne suis pour l'instant pas arrivé à conclure plus que : 
On dispose de /etc/nsswitch.conf qui doit être normalement correct (bonne 
distribution !)

On configure
  /etc/network/interfaces

Et ensuite... resolvconf, Networkmanager, etc.
Je vous pose la question plutôt que de bidouiller une synthèse bancale.

Sur une machine Debian, comment configurez-vous fiablement les programmes qui 
configurent votre réseau ?

Pour /etc/hosts, je le fais à la main.
Comment gérez-vous ce fichier /etc/hosts dans un (petit) réseau de plusieurs 
machines ?

Merci

Re: Quel firewall pour Buster et au delà ?

[Olivier]

Le ven. 11 janv. 2019 à 17:55, Wallace  a écrit :

> Clairement vu ce que je ressort de la conversation, quitte à faire un saut
> autant sauter directement à BPF.
>
Justement, j'ai compris que BPF, c'était la cuisine interne de Linux: on
configure avec nftables ou firewalld ou autre et c'est nftables qui
s'appuie sur BPF à l'insu de l'administrateur.
Bien entendu, je peux avoir compris de travers  et je serai ravi qu'une
personne plus qualifiée que moi me corrige ;-)))

[HS] Recommandations pour la collecte des statistiques de commutateurs

[Olivier]

Bonjour,

Parmi mes bonnes résolutions de 2019, figure la collecte et le stockage de
statistiques produites pas des commutateurs sur des réseaux locaux distants.

J'ai survolé quelques infos sur Netflow/IPFIX et sFlow.
Je suppose ici que mes commutateurs supportent l'un ou l'autre des deux
protocoles.
Je suppose aussi qu'ils supportent aussi SNMP.

Voici mes questions:

1. Est-il possible/habituel/recommandé d'exclure certaines interfaces d'un
commutateur du périmètre ? Je pense aux liens directs entre deux
commutateurs: est-il utile d'accumuler des données sur les deux extrémités
d'un même lien Ethernet ? Idem pour les serveurs: faut-il collecter leurs
stats réseau sur le port du switch ou sur le serveur ?

2.  Que pensez-vous de nfdump pour collecter du Netflow ou du sFlow ?

Slts

Re: Quel firewall pour Buster et au delà ?

[Wallace]

Le 11/01/2019 à 17:28, Olivier a écrit :
>
>
> Le ven. 11 janv. 2019 à 16:24, Wallace  > a écrit :
>
>
> Ca voudrait donc dire que iptables ne fait plus parti du kernel?
>
>
> Je pense que des scripts iptables fonctionneront sans modification
> pendant encore de longues années.
> Pour une machine "ancienne", on devrait pouvoir la passer à Buster
> sans modification.
>
> Par contre, pour une nouvelle machine, je pense qu'on peut avoir
> intérêt à se poser la question d'une autre syntaxe ou d'un autre
> niveau d'abstraction.

Quand tu as des automatismes (Ansible, Chef, Puppet, scripts maison,
...) la nouveauté n'est pas forcément utile toute de suite. Pour avoir
connu la fin de ipchains, la transition avec iptables a été longue pour
mes ainés qui disaient qu'on ne s'amuse pas à changer quelque chose qui
marche et qui ne pose pas de problème. J'ai entendu la même pour IPv6 et
on voit que l'adoption est plus lent du coup.

Clairement vu ce que je ressort de la conversation, quitte à faire un
saut autant sauter directement à BPF.



signature.asc
Description: OpenPGP digital signature

Re: Quel firewall pour Buster et au delà ?

[Olivier]

Le ven. 11 janv. 2019 à 16:24, Wallace  a écrit :

>
> Ca voudrait donc dire que iptables ne fait plus parti du kernel?
>
>
> Je pense que des scripts iptables fonctionneront sans modification pendant
encore de longues années.
Pour une machine "ancienne", on devrait pouvoir la passer à Buster sans
modification.

Par contre, pour une nouvelle machine, je pense qu'on peut avoir intérêt à
se poser la question d'une autre syntaxe ou d'un autre niveau d'abstraction.

Re: Aide offline libreoffice 6

[ajh-valmer]

On Wednesday 09 January 2019 23:51:30 Migrec wrote:
> Le 07/01/2019 à 18:00, ajh-valmer a écrit :
> > Il y en a un autre :
> > OpenOffice et maintenant LibreOffice ont toujours eu ce défaut récurrent,
> > le Copier/Coller à l'intérieur d'un document LO ne fonctionne pas avec la
> > roulette de la souris.
> > Il faut mettre le texte en surbrillance, clic droit, "Copier", puis encore
> > clic droit et "Coller".
> > (alors qu'avec la roulette, texte en surbrillance puis clic roulette,
> > quel gain de temps !)

> Si ça peut rassurer, sur ma Kubuntu 18.10 avec LibreOffice 6.1.3.2, ça 
> fonctionne désormais !
> Par contre le copier-coller avec le clic droit fonctionne une fois sur 2 
> dans calc. Bogue saisi.

Je viens d'essayer, et non, 
pas de copier/coller texte en surbrillance puis clic roulette avec LO,
À L'INTÉRIEUR du document (dans le même ou on travaille).

Par contre, ça marche si le copier vient de l'extérieur,
c'est sans doute ce que tu fais.

A. Valmer

Re: Quel firewall pour Buster et au delà ?

[Olivier]

Le ven. 11 janv. 2019 à 16:05, didier gaumet  a
écrit :

>
> Firewalld n'est qu'une surcouche à, auparavant iptables, désormais
> nftables? Un peu comme Shorewall
>
> J'ai compris la même chose que toi.
Je recommande le lien [1] qui l'explique.

[1]
https://developers.redhat.com/blog/2018/08/10/firewalld-the-future-is-nftables/

En toute logique, quand on choisit firewalld, on ne configure plus
iptables, nftables ou autre (c'est firewalld qui s'appuie sur ces techno).

Le ven. 11 janv. 2019 à 16:05, didier gaumet  a
écrit :

> Le 11/01/2019 à 15:44, Wallace a écrit :
> > Bonjour,
> >
> > Merci d'avoir lancé le sujet qui trottait dans mon esprit.
> >
> > Actuellement on gère iptables grâce à Shorewall qui fait très bien le
> > travail et permet de retrouver une lecture similaire à une configuration
> > de firewall appliance. C'est pratique pour que tout le monde soit au
> > diapason sur la lecture. Y a Ferm qui fait pareil aussi.
> >
> > Shorewall a déjà annoncé qu'il ne partirait pas dans ce chantier de
> > refonte étant trop lié à iptables.
> >
> > Personnellement je n'ai rien à reprocher à iptables et j'envisage donc
> > de continuer de l'utiliser. Mais si l'on est bloqué par une suppression
> > de iptables et obligation de passer sur nftables alors il va falloir
> > anticiper.
> >
> > Il y a du coup deux questions :
> >
> > - y a t il eu une annonce quand on retrait du kernel ou le End Of Life
> > de iptables?
> >
> > - nftables est il forcément lié à firewalld? ou est-ce que l'on peut
> > parler directement au kernel comme avant?
>
> Alors je suis une truffe pour tout ce qui est réseaux mais j'ai quand
> même l'impression qu'il y a un quiproquo sur nftables/firewalld, non?
>
> Firewalld n'est qu'une surcouche à, auparavant iptables, désormais
> nftables? Un peu comme Shorewall
>
> D'après ce que j'ai compris, le paquet iptables sera dans la prochaine
> version Debian et ne sera pas un pseudo-paquet pointant vers nftables,
> mais utilisera le backend nftables dans le noyau mais en conservant la
> syntaxe iptables? Et si on souhaite utiliser véritablement nftables, il
> est possible (au moins pour le moment) d'utiliser l'ancienne syntaxe
> iptables ou la nouvelle syntaxe dédiée nftables?
>
> Didier, truffe réseau en mal de culture ad-hoc ;-)
>
>
>

Re: [HS] Plateforme de type NUC avec une interface NbaseT, 10Gb/s ou SFP+

[Olivier]

Les grands esprits se rencontrent :
j'avais moi aussi repéré cette machine de Supermicro (NUC-killer) mais je
la voyait plus pour par exemple, produire ou recevoir du trafic réseau dans
un labo, à cause de ses nombreuses interfaces.

Ma question originale visait une machine de routage assez performante pour
router du traffic (avec NAT et tout le toutim) vers deux interfaces à 1
Gb/s.
On trouve des routeurs sur étagère mais administrer des machines Debian me
convient mieux qu'apprendre des OS spécialisés et leurs pièges ;-))).

Pourquoi un NUC, alors ?
J'apprécie leur capacité disque (quand on les comparent aux routeurs), leur
silence et leur compacité (des clients à l'autre mot de la France acceptent
de me les renvoyer ce qui est plus difficile avec des machines plus
grandes).
J'ai aussi l'impression qu'avec un Core i3/i5/i7 et les qualités
intrinsèques à Linux, je peux atteindre le niveau de performance voulu.

J'ai lu des annonces d'adaptateurs NbaseT sur USB mais les produits et la
version Linux nécessaires ne sont pas, à ma connaissance, encore
disponibles.

En résumé, mon objectif est de construire un routeur une unique interface
physique qui arrive à saturer deux liens à 1 Gb/s.

Le ven. 11 janv. 2019 à 10:54, Vincent  a écrit :

> Le 11/01/2019 à 10:05, Olivier a écrit :
> > Bonjour,
> >
> > Connaissez-vous une plateforme de type NUC avec une interface NbaseT,
> > 10Gb/s ou SFP+ ?
> > J'en ai croisées avec une deuxième interface 10/100 mais rien qui
> > dépasse le Gigabit.
> >
> > Slts
> >
>
> Pas vraiment un nuc ( miniITX, pas de hdmi, son, usb limité ) mais très
> complet niveau réseau pour la taille.
>
> https://www.supermicro.com/products/system/Mini-ITX/SYS-E300-9A.cfm
>
> sinon
>
> https://www.supermicro.com/products/system/Mini-ITX/SYS-E300-8D.cfm
>
> https://www.supermicro.com/products/system/Mini-ITX/SYS-E300-9D.cfm
>
> https://www.supermicro.com/products/system/Mini-ITX/SYS-E300-9C.cfm ou
> autre miniITX + carte réseau qui va bien
>
> C'est pour quel usage ?
>
>

Re: Quel firewall pour Buster et au delà ?

[Wallace]

Le 11/01/2019 à 16:05, didier gaumet a écrit :
>
> Alors je suis une truffe pour tout ce qui est réseaux mais j'ai quand
> même l'impression qu'il y a un quiproquo sur nftables/firewalld, non?
>
> Firewalld n'est qu'une surcouche à, auparavant iptables, désormais
> nftables? Un peu comme Shorewall
Aucune idée je n'ai pas encore creusé le sujet.
>
> D'après ce que j'ai compris, le paquet iptables sera dans la prochaine
> version Debian et ne sera pas un pseudo-paquet pointant vers nftables,
> mais utilisera le backend nftables dans le noyau mais en conservant la
> syntaxe iptables? Et si on souhaite utiliser véritablement nftables, il
> est possible (au moins pour le moment) d'utiliser l'ancienne syntaxe
> iptables ou la nouvelle syntaxe dédiée nftables?

Ca voudrait donc dire que iptables ne fait plus parti du kernel?

J'ai rien trouvé en news à ce sujet.

Néanmoins quand on voit un article comme celui là :

https://cilium.io/blog/2018/04/17/why-is-the-kernel-community-replacing-iptables/

On peut se dire que nftables est un remplaçant à peine plus performant.
BPF semble bien plus prometteur pour les réseaux à plus de 10Gbs.

>
> Didier, truffe réseau en mal de culture ad-hoc ;-)
On ne peut pas tout maitriser et j'avoue avoir un peu lâcher ce sujet vu
qu'iptables fait le boulot et qu'on a pas encore été confronté à des
interfaces à plus de 10Gbs...



signature.asc
Description: OpenPGP digital signature

Re: Quel firewall pour Buster et au delà ?

[didier gaumet]

Le 11/01/2019 à 15:44, Wallace a écrit :
> Bonjour,
> 
> Merci d'avoir lancé le sujet qui trottait dans mon esprit.
> 
> Actuellement on gère iptables grâce à Shorewall qui fait très bien le
> travail et permet de retrouver une lecture similaire à une configuration
> de firewall appliance. C'est pratique pour que tout le monde soit au
> diapason sur la lecture. Y a Ferm qui fait pareil aussi.
> 
> Shorewall a déjà annoncé qu'il ne partirait pas dans ce chantier de
> refonte étant trop lié à iptables.
> 
> Personnellement je n'ai rien à reprocher à iptables et j'envisage donc
> de continuer de l'utiliser. Mais si l'on est bloqué par une suppression
> de iptables et obligation de passer sur nftables alors il va falloir
> anticiper.
> 
> Il y a du coup deux questions :
> 
> - y a t il eu une annonce quand on retrait du kernel ou le End Of Life
> de iptables?
> 
> - nftables est il forcément lié à firewalld? ou est-ce que l'on peut
> parler directement au kernel comme avant?

Alors je suis une truffe pour tout ce qui est réseaux mais j'ai quand
même l'impression qu'il y a un quiproquo sur nftables/firewalld, non?

Firewalld n'est qu'une surcouche à, auparavant iptables, désormais
nftables? Un peu comme Shorewall

D'après ce que j'ai compris, le paquet iptables sera dans la prochaine
version Debian et ne sera pas un pseudo-paquet pointant vers nftables,
mais utilisera le backend nftables dans le noyau mais en conservant la
syntaxe iptables? Et si on souhaite utiliser véritablement nftables, il
est possible (au moins pour le moment) d'utiliser l'ancienne syntaxe
iptables ou la nouvelle syntaxe dédiée nftables?

Didier, truffe réseau en mal de culture ad-hoc ;-)

Re: Quel firewall pour Buster et au delà ?

[Wallace]

Bonjour,

Merci d'avoir lancé le sujet qui trottait dans mon esprit.

Actuellement on gère iptables grâce à Shorewall qui fait très bien le
travail et permet de retrouver une lecture similaire à une configuration
de firewall appliance. C'est pratique pour que tout le monde soit au
diapason sur la lecture. Y a Ferm qui fait pareil aussi.

Shorewall a déjà annoncé qu'il ne partirait pas dans ce chantier de
refonte étant trop lié à iptables.

Personnellement je n'ai rien à reprocher à iptables et j'envisage donc
de continuer de l'utiliser. Mais si l'on est bloqué par une suppression
de iptables et obligation de passer sur nftables alors il va falloir
anticiper.

Il y a du coup deux questions :

- y a t il eu une annonce quand on retrait du kernel ou le End Of Life
de iptables?

- nftables est il forcément lié à firewalld? ou est-ce que l'on peut
parler directement au kernel comme avant?


Le 10/01/2019 à 14:33, Olivier a écrit :
> Bonjour,
>
> Je maintiens depuis des années un script qui configure le firewalling
> sur des serveurs.
> Ce script est installé dans /etc/network/if-pre-up.d
> Il comprend une bonne trentaine de règles iptables dont des règles
> pour le NAT.
>
> J'ai lu que Linux remplaçait iptables par nftables.
> Par ailleurs, la technologie eBPF semble aussi très prometteuse.
>
> J'ai toute confiance sur l'existence dans Buster et ses successeurs de
> moyens pour conserver le bon fonctionnement de scripts iptables.
> Néanmoins, je me demande si le moment n'est pas le bienvenu pour
> justement pour sauter le pas en réécrivant mes scripts iptables avec
> autre chose.
>
> On annonce ici ou là:
> - une plus grande pérennité
> - de meilleurs performances
> - une syntaxe plus simple.
>
> Je serai très heureux d'échanger ici des réflexions sur le sujet.
> Voici en vrac quelques questions et réflexions:
>
> 1. Avez-vous un retour d'expérience positif ou non sur un passage
> d'iptables à firewalld, en général (ie sur Stretch, Jessie, ...) ?
>
> 2. Trouvez-vous facilement de l'aide (mailing lists, documentation en
> ligne, publications, ...) sur la version 0.6.3 de firewalld (celle de
> Buster) ?
>
> 3. Comme le suggère la réponse à une question dans [1], doit-on
> vraiment voir eBPF comme une cuisine interne à Linux et se focaliser
> sur firewalld ?
>
> 4. Commentaires et suggestions ?
>
> [1]
> https://developers.redhat.com/blog/2018/08/10/firewalld-the-future-is-nftables/
>
> Slts
>


signature.asc
Description: OpenPGP digital signature

Re: Quel firewall pour Buster et au delà ?

[G2PC]

> J'ai lu que Linux remplaçait iptables par nftables.
> Par ailleurs, la technologie eBPF semble aussi très prometteuse.
>
Vu que je tente d'utiliser Iptables de façon laborieuse, je veux bien en
savoir plus.
Ce changement est prévu dans la nouvelle version de Debian ?

Dès lors, faut t'il se concentrer sur nftables ?

Re: [HS] Plateforme de type NUC avec une interface NbaseT, 10Gb/s ou SFP+

[Vincent]

Le 11/01/2019 à 10:05, Olivier a écrit :
> Bonjour,
> 
> Connaissez-vous une plateforme de type NUC avec une interface NbaseT,
> 10Gb/s ou SFP+ ?
> J'en ai croisées avec une deuxième interface 10/100 mais rien qui
> dépasse le Gigabit.
> 
> Slts
> 

Pas vraiment un nuc ( miniITX, pas de hdmi, son, usb limité ) mais très
complet niveau réseau pour la taille.

https://www.supermicro.com/products/system/Mini-ITX/SYS-E300-9A.cfm

sinon

https://www.supermicro.com/products/system/Mini-ITX/SYS-E300-8D.cfm

https://www.supermicro.com/products/system/Mini-ITX/SYS-E300-9D.cfm

https://www.supermicro.com/products/system/Mini-ITX/SYS-E300-9C.cfm ou
autre miniITX + carte réseau qui va bien

C'est pour quel usage ?

Re: Gnome-openbox

[Stephane Ascoet]

Le 10/01/2019 à 16:22, Jean Bernon a écrit :



Merci de l'avoir fait. Tu es manifestement plus rompu que moi à ce genre 
d'exercice.


Bonjour, et oui, j'ai roule ma bosse ;-)



Curieux non ?
Jean

Ca fait plus de 15 ans que je n'ai pas utilise serieusement Gnome donc 
je ne pourrais pas t'aider...


--
Cordialement, Stephane Ascoet

[HS] Plateforme de type NUC avec une interface NbaseT, 10Gb/s ou SFP+

[Olivier]

Bonjour,

Connaissez-vous une plateforme de type NUC avec une interface NbaseT,
10Gb/s ou SFP+ ?
J'en ai croisées avec une deuxième interface 10/100 mais rien qui dépasse
le Gigabit.

Slts