Re: Problème IPv6 et firewall avec Buster
Bonsoir, Je pense avoir résolu mon souci, non pas avec la MTU mais en redémarrant la VM. J'ai l'impression que la prise en compte de la config réseau, notamment de la désactivation de l'autoconf de l'IPv6, n'a pas été totale la première fois? Car maintenant, même avec le firewall actif, tout fonctionne nickel chrome ! Alain JUPIN Le 15/09/2021 à 11:19, NoSpam a écrit : Bonjour essaye en passant la mtu ipv6 en 1496 ou 1492 Le 15/09/2021 à 10:11, JUPIN Alain a écrit : Bonjour, Sur une machine virtuelle fraîchement installée avec Buster en version 10.10, l'IPv6 a été configuré de la même manière que les autres VM. La connexion IPv6 fonctionne très bien sauf qu'au bout d'un moment assez aléatoire (de quelques minutes à quelques dizaine de minutes), la connexion tombe ! Sous SSH, plus de réponse puis : "client_loop: send disconnect: Broken pipe", les autres service aussi ne répondent plus en IPv6 Fait "intriguant", la connexion IPv4 fonctionne parfaitement. Si je désactive le firewall, tout rentre dans l'ordre. Si je le réactive, tout fonctionne jusqu'à ce que ... patatrac ! Si je désactive le firewall, aucun soucis, je reste connecté en IPv6 sans limitations de durée (au moins pendant plusieurs heures). L'hôte de la machine virtuelle est un serveur dédié SoYouStart (de chez OVH), lui aussi sous Debian 10 faisant tourner Proxmox. Quand j'ai le soucis d'IPv6 avec cette machine virtuelle, toutes les autres VM du même serveur fonctionnent encore parfaitement en IPv6, et même en dehors du serveur, le ping6 vers ipv6.ggogle.com, le surf etc en IPv6 fonctionne parfaitement. Par contre en SSH (en IPv4), depuis le serveur en question, impossible de pinguer en IPv6 par ipv6.google.com : "connect: Le réseau n'est pas accessible" J'écarte donc momentanément le soucis de config IPv6 chez moi, mais plutôt celui d'un problème de firewall probablement avec l'autoconfig d'IPv6 ou d'IPv6 lui-même ? Enfin, le script du firewall (qui est le même que sur toute les autres VM dans son concept, car sur d'autres VM, d'autres ports comme le HTTP⋅S sont ouverts) : # Politique par défaut IN/FWD est DROP, OUT en ACCEPT iptables -P INPUT DROP iptables -P FORWARD DROP iptables -P OUTPUT ACCEPT ip6tables -P INPUT DROP ip6tables -P FORWARD DROP ip6tables -P OUTPUT ACCEPT # Autoriser le Loopback iptables -A INPUT -i lo -j ACCEPT iptables -A OUTPUT -o lo -j ACCEPT ip6tables -A INPUT -i lo -j ACCEPT ip6tables -A OUTPUT -o lo -j ACCEPT ### # INBOUND TRAFIC # ### # On accepte tout le trafic des paquets déjà établis iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT ip6tables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT # SSH iptables -A INPUT -p tcp --dport 22 -j ACCEPT ip6tables -A INPUT -p tcp --dport 22 -j ACCEPT # ICECAST iptables -A INPUT -p tcp --dport 8000 -j ACCEPT ip6tables -A INPUT -p tcp --dport 8000 -j ACCEPT # On accepte les requetes ICMP iptables -A INPUT -p icmp -j ACCEPT ip6tables -A INPUT -p icmpv6 --icmpv6-type neighbour-solicitation -m hl --hl-eq 255 -j ACCEPT ip6tables -A INPUT -p icmpv6 --icmpv6-type neighbour-advertisement -m hl --hl-eq 255 -j ACCEPT ip6tables -A INPUT -p icmpv6 --icmpv6-type router-advertisement -m hl --hl-eq 255 -j ACCEPT ip6tables -A INPUT -p icmpv6 --icmpv6-type echo-request -j ACCEPT Pour vous aider (on sait jamais), voici la table de routage (route -A inet6) Table de routage IPv6 du noyau Destination Next Hop Flag Met Ref Use If localhost/128 [::] U 256 2 0 lo 2001:41d0:2:5fdd::/64 [::] U 256 2 0 ens18 vss-2-6k.fr.eu/128 [::] U 1024 2 0 ens18 2001:41d0:2:5f00::/56 [::] UAe 256 1 0 ens18 fe80::/64 [::] U 256 1 0 ens18 [::]/0 [::] !n -1 1 0 lo localhost/128 [::] Un 0 5 0 lo 2001:41d0:2:5fdd::199:1/128 [::] Un 0 3 0 ens18 fe80::ff:fe5d:1c39/128 [::] Un 0 3 0 ens18 ff00::/8 [::] U 256 3 0 ens18 [::]/0 [::] !n -1 1 0 lo Merci à vous pour votre aide, et petite précision, je suis pas un "pro" de l'IPv6 ! J'ai donc peut être zappé des points essentiels.
Re: buster => bullseye, upgrade vs reinstall
On 15/09/2021 20:20, Daniel Caillibaud wrote: Salut, Version courte : dans quel cas une réinstall peut donner de meilleurs résultats qu'un upgrade ? Pour moi, reinstaller est faisable aisément quand le /home n 'est pas sur la même partition disque que le système (c'est-à-dire / ...) Il m'arrive même de changer de distribution (Debian vers Ubuntu ou Mint) dans ce cas. Et je crois que ce qui peut poser souvent problème, c'est le chipset graphique et le wifi. Donc: si possible, re-installation minimale via ethernet (cable). Bon courage. PS. Pour ceux qui participent à des projets financés (HorizonEurope, ANR), voir http://refpersys.org/ et contactez moi en et si intéressés. -- Basile Starynkevitch (only mine opinions / les opinions sont miennes uniquement) 92340 Bourg-la-Reine, France web page: starynkevitch.net/Basile/
Re: gestion des mises à jour
Le 13/09/21 à 19:27, Hugues Larrive a écrit : > Bonjour, > > J'utilise apticron qui me notifie par e-mail quand des mises à jour sont > disponibles. Après > j'archive les e-mail, ça me fait un historique. Par contre je fais mes mises > à jour > manuellement. Et c'est plus prudent ;-) (à condition de lire ces mails) J'avais utilisé autre chose y'a pas mal d'années, qui appliquait les mises à jour de sécurité tout seul (et envoyait le rapport, peut-être cron-apt mais j'en suis pas si sûr), mais j'ai eu quelques services plantés à cause de ça (sans aucune anomalie dans le rapport), en général à cause de scripts postinstall un peu foireux (qui supposent par ex que tu as laissé tous les paramètres de config par défaut et qui modifient les droits sur les fichier de conf par ex). Vu du système tout allait bien (paquet à jour avec upgrade sans erreur), mais vu de l'utilisateur y'avait plus rien qui marchait (serveur web HS, accès à la base de données coupé, etc.). Avec un grand merci au passage à ceux qui ont créé le paquet dbconfig-no-thanks ;-) (vu le nb de plantages occasionnés par des upgrades de paquets qui se reposent sur dbconfig) -- Daniel J'aurais aimé être publicitaire pour faire dire des conneries aux vedettes.
buster => bullseye, upgrade vs reinstall
Salut, Version courte : dans quel cas une réinstall peut donner de meilleurs résultats qu'un upgrade ? Pour ceux qui veulent des détails sur le contexte, la version longue : Sur mon PC portable récent (2020 avec i5 1035G1) installé avec buster, j'ai toujours pas mal de pbs, mais moins qu'il y a qq temps ;-) Les plantages i915 ont été réglés en désactivant pas mal de trucs, au prix de qq ralentissements et d'artefact graphiques désagréables, mais moins que les plantages violents précédents (plus rien ne répondait). Le module ath10k (wifi) plante souvent, et faut un reboot pour récupérer le réseau, mais en général je garde la main et je peux faire un reboot soft (même si parfois ça veut pas s'arrêter et faut couper le jus pour pouvoir redémarrer). Je vais donc passer à bullseye pour voir si ça s'améliore un peu (j'ai peu d'espoir, je suis déjà sur un kernel 5.12), et j'hésite à faire une réinstall complète plutôt qu'un upgrade (car nettement plus laborieux, j'ai des partitions lvm chiffrées avec un montage auto quand la 1re est déchiffrée). -- Daniel Une pomme par jour éloigne le médecin, pourvu que l'on vise bien. Winston Churchill
Problème IPv6 et firewall avec Buster
Bonjour, Sur une machine virtuelle fraîchement installée avec Buster en version 10.10, l'IPv6 a été configuré de la même manière que les autres VM. La connexion IPv6 fonctionne très bien sauf qu'au bout d'un moment assez aléatoire (de quelques minutes à quelques dizaine de minutes), la connexion tombe ! Sous SSH, plus de réponse puis : "client_loop: send disconnect: Broken pipe", les autres service aussi ne répondent plus en IPv6 Fait "intriguant", la connexion IPv4 fonctionne parfaitement. Si je désactive le firewall, tout rentre dans l'ordre. Si je le réactive, tout fonctionne jusqu'à ce que ... patatrac ! Si je désactive le firewall, aucun soucis, je reste connecté en IPv6 sans limitations de durée (au moins pendant plusieurs heures). L'hôte de la machine virtuelle est un serveur dédié SoYouStart (de chez OVH), lui aussi sous Debian 10 faisant tourner Proxmox. Quand j'ai le soucis d'IPv6 avec cette machine virtuelle, toutes les autres VM du même serveur fonctionnent encore parfaitement en IPv6, et même en dehors du serveur, le ping6 vers ipv6.ggogle.com, le surf etc en IPv6 fonctionne parfaitement. Par contre en SSH (en IPv4), depuis le serveur en question, impossible de pinguer en IPv6 par ipv6.google.com : "connect: Le réseau n'est pas accessible" J'écarte donc momentanément le soucis de config IPv6 chez moi, mais plutôt celui d'un problème de firewall probablement avec l'autoconfig d'IPv6 ou d'IPv6 lui-même ? Enfin, le script du firewall (qui est le même que sur toute les autres VM dans son concept, car sur d'autres VM, d'autres ports comme le HTTP⋅S sont ouverts) : # Politique par défaut IN/FWD est DROP, OUT en ACCEPT iptables -P INPUT DROP iptables -P FORWARD DROP iptables -P OUTPUT ACCEPT ip6tables -P INPUT DROP ip6tables -P FORWARD DROP ip6tables -P OUTPUT ACCEPT # Autoriser le Loopback iptables -A INPUT -i lo -j ACCEPT iptables -A OUTPUT -o lo -j ACCEPT ip6tables -A INPUT -i lo -j ACCEPT ip6tables -A OUTPUT -o lo -j ACCEPT ### # INBOUND TRAFIC # ### # On accepte tout le trafic des paquets déjà établis iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT ip6tables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT # SSH iptables -A INPUT -p tcp --dport 22 -j ACCEPT ip6tables -A INPUT -p tcp --dport 22 -j ACCEPT # ICECAST iptables -A INPUT -p tcp --dport 8000 -j ACCEPT ip6tables -A INPUT -p tcp --dport 8000 -j ACCEPT # On accepte les requetes ICMP iptables -A INPUT -p icmp -j ACCEPT ip6tables -A INPUT -p icmpv6 --icmpv6-type neighbour-solicitation -m hl --hl-eq 255 -j ACCEPT ip6tables -A INPUT -p icmpv6 --icmpv6-type neighbour-advertisement -m hl --hl-eq 255 -j ACCEPT ip6tables -A INPUT -p icmpv6 --icmpv6-type router-advertisement -m hl --hl-eq 255 -j ACCEPT ip6tables -A INPUT -p icmpv6 --icmpv6-type echo-request -j ACCEPT Pour vous aider (on sait jamais), voici la table de routage (route -A inet6) Table de routage IPv6 du noyau Destination Next Hop Flag Met Ref Use If localhost/128 [::] U 256 2 0 lo 2001:41d0:2:5fdd::/64 [::] U 256 2 0 ens18 vss-2-6k.fr.eu/128 [::] U 1024 2 0 ens18 2001:41d0:2:5f00::/56 [::] UAe 256 1 0 ens18 fe80::/64 [::] U 256 1 0 ens18 [::]/0 [::] !n -1 1 0 lo localhost/128 [::] Un 0 5 0 lo 2001:41d0:2:5fdd::199:1/128 [::] Un 0 3 0 ens18 fe80::ff:fe5d:1c39/128 [::] Un 0 3 0 ens18 ff00::/8 [::] U 256 3 0 ens18 [::]/0 [::] !n -1 1 0 lo Merci à vous pour votre aide, et petite précision, je suis pas un "pro" de l'IPv6 ! J'ai donc peut être zappé des points essentiels. -- Alain JUPIN
Re: Problème IPv6 et firewall avec Buster
Bonjour essaye en passant la mtu ipv6 en 1496 ou 1492 Le 15/09/2021 à 10:11, JUPIN Alain a écrit : Bonjour, Sur une machine virtuelle fraîchement installée avec Buster en version 10.10, l'IPv6 a été configuré de la même manière que les autres VM. La connexion IPv6 fonctionne très bien sauf qu'au bout d'un moment assez aléatoire (de quelques minutes à quelques dizaine de minutes), la connexion tombe ! Sous SSH, plus de réponse puis : "client_loop: send disconnect: Broken pipe", les autres service aussi ne répondent plus en IPv6 Fait "intriguant", la connexion IPv4 fonctionne parfaitement. Si je désactive le firewall, tout rentre dans l'ordre. Si je le réactive, tout fonctionne jusqu'à ce que ... patatrac ! Si je désactive le firewall, aucun soucis, je reste connecté en IPv6 sans limitations de durée (au moins pendant plusieurs heures). L'hôte de la machine virtuelle est un serveur dédié SoYouStart (de chez OVH), lui aussi sous Debian 10 faisant tourner Proxmox. Quand j'ai le soucis d'IPv6 avec cette machine virtuelle, toutes les autres VM du même serveur fonctionnent encore parfaitement en IPv6, et même en dehors du serveur, le ping6 vers ipv6.ggogle.com, le surf etc en IPv6 fonctionne parfaitement. Par contre en SSH (en IPv4), depuis le serveur en question, impossible de pinguer en IPv6 par ipv6.google.com : "connect: Le réseau n'est pas accessible" J'écarte donc momentanément le soucis de config IPv6 chez moi, mais plutôt celui d'un problème de firewall probablement avec l'autoconfig d'IPv6 ou d'IPv6 lui-même ? Enfin, le script du firewall (qui est le même que sur toute les autres VM dans son concept, car sur d'autres VM, d'autres ports comme le HTTP⋅S sont ouverts) : # Politique par défaut IN/FWD est DROP, OUT en ACCEPT iptables -P INPUT DROP iptables -P FORWARD DROP iptables -P OUTPUT ACCEPT ip6tables -P INPUT DROP ip6tables -P FORWARD DROP ip6tables -P OUTPUT ACCEPT # Autoriser le Loopback iptables -A INPUT -i lo -j ACCEPT iptables -A OUTPUT -o lo -j ACCEPT ip6tables -A INPUT -i lo -j ACCEPT ip6tables -A OUTPUT -o lo -j ACCEPT ### # INBOUND TRAFIC # ### # On accepte tout le trafic des paquets déjà établis iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT ip6tables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT # SSH iptables -A INPUT -p tcp --dport 22 -j ACCEPT ip6tables -A INPUT -p tcp --dport 22 -j ACCEPT # ICECAST iptables -A INPUT -p tcp --dport 8000 -j ACCEPT ip6tables -A INPUT -p tcp --dport 8000 -j ACCEPT # On accepte les requetes ICMP iptables -A INPUT -p icmp -j ACCEPT ip6tables -A INPUT -p icmpv6 --icmpv6-type neighbour-solicitation -m hl --hl-eq 255 -j ACCEPT ip6tables -A INPUT -p icmpv6 --icmpv6-type neighbour-advertisement -m hl --hl-eq 255 -j ACCEPT ip6tables -A INPUT -p icmpv6 --icmpv6-type router-advertisement -m hl --hl-eq 255 -j ACCEPT ip6tables -A INPUT -p icmpv6 --icmpv6-type echo-request -j ACCEPT Pour vous aider (on sait jamais), voici la table de routage (route -A inet6) Table de routage IPv6 du noyau Destination Next Hop Flag Met Ref Use If localhost/128 [::] U 256 2 0 lo 2001:41d0:2:5fdd::/64 [::] U 256 2 0 ens18 vss-2-6k.fr.eu/128 [::] U 1024 2 0 ens18 2001:41d0:2:5f00::/56 [::] UAe 256 1 0 ens18 fe80::/64 [::] U 256 1 0 ens18 [::]/0 [::] !n -1 1 0 lo localhost/128 [::] Un 0 5 0 lo 2001:41d0:2:5fdd::199:1/128 [::] Un 0 3 0 ens18 fe80::ff:fe5d:1c39/128 [::] Un 0 3 0 ens18 ff00::/8 [::] U 256 3 0 ens18 [::]/0 [::] !n -1 1 0 lo Merci à vous pour votre aide, et petite précision, je suis pas un "pro" de l'IPv6 ! J'ai donc peut être zappé des points essentiels.
