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.
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
NoSpam
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.
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.
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.
JUPIN Alain
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.
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.
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.
