Re: Souci IPv6

Le 17-09-2023, Pascal Hambourg <pascal@plouf.fr.eu.org> a écrit :

Bonjour,
>
Le 08/09/2023 à 11:30, JKB a écrit :

 
Je viens de changer de FAI après une série de déboires dus au rachat
de Nerim par Keyyo.

>
Lequel, si ce n'est pas indiscret, car je commence aussi à me poser la
question.

Le_s_quels_s_.

Liste non exhaustive :
- coupure de mon compte partenaire en quatre (l'un pour les accès
  avec TVA, l'autre pour les accès sans TVA, le troisième pour la
  téléphonie et le quatrième à la suite d'une erreur interne).
  Problème : j'avais donc quatre numéros de client et je ne
  recevais que les factures pour un seul. Comme ces types ont
  extirpé des archives Nerim un compte d'une entreprise _fermée
  depuis 1996_ mais que je gardais ouvert en raison d'une erreur de
  ma banque (un NNE), je virais sur ce compte le montant des
  factures qui ne correspondait _jamais_ à ce qui était prélevé ;
- liens résiliés par erreur (parce que sur le lot, j'ai eu deux
  liens payés durant six mois par des tiers). Le premier ne s'en est
  pas rendu compte, le second a demandé une résiliation que personne
  n'a voulu arrêter. J'ai donc perdu au passage l'IPv6 parce que si
  Nerim fournissait l'IPv6, Keyyo s'en tamponne ;
- techniquement : depuis le rachat, je n'ai eu que des merdes. La
  téléphonie échouait en appel entrant à peu près une fois sur dix.
  Les dégroupages (dans mon cas, FT et Nerim) sont passés sur du
  Bouygues sans me demander mon accord. J'ai eu des instabilités
  délirantes en ADSL (Paris intra-muros) mais je devais être content
  puisque le débit est passé en IP de 18 à 19 Mbps (sic le service
  technique !). À l'autre bout de la France, je suis passé de 9 Mbps
  à 3,5 Mbps à la suite d'un dégroupage sauvage de FT à Bouygues. Et
  encore, avec des problèmes de pertes de paquets (20% en moyenne).

J'ai résilié tous les accès le 30 juin dernier par courrier
recommandé (rupture unilatérale des contrats par manque de leur
obligation de moyens, il y a un article du code civil). Ils n'en ont
rien eu à faire et j'ai eu des nouvelles du service recouvrement (le seul
truc qui fonctionne à peu près chez eux). Parmi ce qu'ils me
demandaient figuraient des factures des trois autres numéros de
clients que je leur ai demandé par LRAR depuis mars 2023 sans
obtenir de réponse. Eh oui, parce que malgré mes relances, je n'ai
_jamais_ eu ces factures.

Chose exceptionnelle, le recouvrement s'adressait à ma société
actuelle (alors que les factures émises l'étaient à une autre société,
fermée depuis 7 ans). J'ai donc appelé le N°2 de la boîte pour lui
demander s'il par hasard Keyyo ne me prendrait pas pour une bille.
Je lui ai indiqué qu'on était assez proche de ce qu'on pourrait
appeler en étant malveillant une fausse facture (puisque le tiers
mis en demeure n'était pas le destinataire des factures et que seul
le fisc a ce pouvoir en France).

J'ai eu un retour écrit comme quoi le recouvrement a été annulé et le
compte soldé.

Bref, depuis la disparition de Nerim, techniquement, tout est la
ramasse (dans mon cas), le service s'est dégradé (puisque le service
technique est ouvert de 9h00 à 18h00 du lundi au vendredi contre
24h/24 chez Nerim même pour l'ADSL de base) tant techniquement que
commercialement.

Les emmerdes ont commencées trois mois après le rachat. J'ai mis du
temps à les quitter parce que j'avais une infra complète et que ça
m'obligeait à tout revoir (y compris déménager une salle serveur).

Je dois rajouter que parmi tous les dinosaures Nerim, je fus l'un
des derniers à quitter le navire.

J'ai donc utilisé un sous-réseau en /64 (et non/56) côté passerelle.
Les autres /64 sont utilisés côté DMZ/LAN.

>
Toujours utiliser des /64, c'est la seule taille qui marche avec
l'autoconf. Avec une route reject/unreachable pour le préfixe complet
afin de ne pas créer de boucle de routage.

La question est de savoir comment on met en place cette route sous
NetBSD. Je n'ai pas trouvé dans la doc.

Dans le fichier /etc/network/interfaces, j'ai une déclaration IPv6
statique :
 
iface wan0 inet6 static
         address PREFIX:a00::2
         netmask 64

>
Note : la notation moderne "address PREFIX:a00::2/64" est supportée.
>

Mais les machines du LAN n'ont pas d'accès. Si je lance un ping sur
par exemple www.google.fr, je vois passer côté WAN de la machine
NetBSD les paquets à destination de www.google.fr. Mais aucun
retour.
 
Je suppose que le problème est que j'ai un /64 sur le WAN du NetBSD
et un /56 côté passerelle du FAI (ce qui est corrigé côté Linux par
le réseau /56 en unreachable). Comment corriger ce problème ?

>
J'arrive après la bataille, mais faire une capture de trafic côté WAN
pour vérifier s'il y a des requêtes ICMPv6 "Neighbor Solicitation"
(équivalentes des requêtes ARP) pour les adresses IPv6 du LAN. Dans ce
cas le routeur amont est mal configuré, il devrait router le préfixe du
LAN via l'adresse WAN du NetBSD.
>
Contournement possible (hack) : mettre en place un proxy-ND sur le
NetBSD qui va répondre à la place des machines du LAN. Ou bien faire du
NAT IPv6, mais si c'est pour en arriver là, on se demande à quoi l'IPv6
a servi...

Le problème a été résolu, c'était un souci côté fournisseur d'accès.

JKB

--
Si votre demande me parvient en code 29, je vous titiouillerai volontiers
une réponse.