Liste de contrôle de préparation à l’IPv6 pour un serveur domestique auto-hébergé

L’approche sûre consiste à traiter une revue de préparation au double empilement, qui vérifie séparément l’adressage, le filtrage, le DNS, l’identité de l’application et l’accessibilité externe, comme une suite de contrôles observables plutôt que comme une commande unique.

Sur un serveur domestique auto-hébergé et un routeur en double empilement, le risque concret est que l’activation d’IPv6 crée une voie sortante fonctionnelle alors que le DNS, le filtrage entrant et le comportement de l’application à distance restent invérifiés. Notez l’identité actuelle et le point de récupération, commencez par le test discriminant le moins intrusif, interprétez les résultats positifs et négatifs avant de modifier une autre variable, et arrêtez-vous si le stockage devient instable ou si la seule copie récupérable devait être exposée. Le processus ci-dessous ne se termine qu’une fois que la charge de travail d’origine fonctionne ou que les éléments recueillis atteignent une limite nécessitant une escalade.

Inventorier les adresses, les préfixes et les liaisons de services

Notez le préfixe délégué par le FAI, les préfixes du réseau local du routeur, les adresses globales et locales au lien du serveur, les durées de validité des adresses, la route par défaut, les résolveurs DNS, ainsi que l’utilisation éventuelle d’adresses temporaires ou stables. Déterminez quelle adresse restera adaptée à un serveur lors des renouvellements, plutôt que de publier une adresse client temporaire.

Inspectez séparément les sockets à l’écoute en IPv4 et en IPv6. Un service lié à :: peut accepter l’IPv6 sur des interfaces qui n’étaient jamais accessibles via la redirection de ports IPv4, tandis qu’une liaison limitée à IPv4 peut faire passer une route IPv6 saine pour une défaillance de l’application.

Utilisez le processus d’évaluation de l’exposition de ZimaSpace dans la vérification de l’exposition du serveur domestique comme contrôle de sécurité complémentaire. Ne publiez pas d’enregistrements AAAA et n’ouvrez pas de règles entrantes tant que chaque processus à l’écoute, chaque route de proxy, chaque nom de certificat et chaque limite d’authentification n’a pas de responsable.

Vérifier la parité des pare-feu du routeur et de l’hôte

Examinez les règles entrantes avec état sur le routeur, l’hôte, l’hyperviseur et la couche de publication des conteneurs. Commencez par refuser les connexions entrantes non sollicitées, puis créez des exceptions précises concernant uniquement la source, la destination, le protocole et le port pour les services qui doivent être publics ou accessibles depuis un préfixe VPN de confiance.

L’adressage global n’implique pas une accessibilité globale. L’Internet Society limite du pare-feu IPv6 avec état indique qu’un pare-feu IPv6 peut autoriser les communications sortantes tout en filtrant le trafic entrant non sollicité, une fonction que de nombreux utilisateurs attribuent à tort au NAT lui-même.

Effectuez les tests depuis un réseau IPv6 externe, et non depuis le même réseau local. Confirmez que le HTTPS prévu fonctionne et que les ports d’administration, de base de données, SMB et inutilisés restent fermés ou filtrés ; répétez le test avec l’adresse du serveur et toute adresse de proxy publique.

Valider le DNS, TLS, le routage et la taille des paquets

Interrogez les enregistrements A et AAAA depuis des clients internes, externes et VPN, puis notez quelle adresse l’application utilise réellement. Vérifiez que la destination AAAA présente le bon certificat et achemine le nom d’hôte vers la même identité d’application qu’en IPv4.

Testez des requêtes ordinaires et un transfert plus volumineux sur IPv6. Les messages ICMPv6 « Packet Too Big » font partie du fonctionnement du chemin ; un blocage trop large d’ICMPv6 peut donc créer un trou noir de MTU du chemin même lorsque les petites pages se chargent. Autorisez le trafic de contrôle requis au lieu de considérer tout ICMP comme facultatif.

Comparez les journaux et le comportement selon la famille d’adresses. Si IPv6 échoue alors qu’IPv4 fonctionne, laissez l’enregistrement AAAA non publié ou réduisez sa portée jusqu’à ce que les éléments de routage, de pare-feu, de DNS et de proxy permettent d’identifier la différence.

Featured

ZimaCube 2 NAS personnel Cloud à domicile

ZimaCube2

$799.00 - $2,499.00

Buy Now

Effectuer des tests de défaillance et de persistance avant la mise en production

Redémarrez la connexion du routeur ou renouvelez le préfixe pendant une fenêtre de maintenance, puis vérifiez que l’adressage du serveur, le DNS dynamique s’il est utilisé, les objets du pare-feu et les liaisons du proxy se mettent à jour comme prévu. Redémarrez le serveur et vérifiez que les règles sont chargées avant le démarrage des services publics.

Testez la perte d’IPv6 alors qu’IPv4 reste disponible, puis la perte d’IPv4 alors qu’IPv6 reste disponible. Les clients doivent basculer de manière prévisible ou révéler clairement une dépendance ; l’étiquette « double empilement » n’est pas utile si une famille atteint silencieusement un autre service ou une adresse obsolète.

Déclarez la préparation acquise uniquement lorsque les services prévus fonctionnent extérieurement via IPv6, que les ports non prévus restent bloqués, que le DNS et TLS concordent et qu’un changement de préfixe ne permet pas de contourner la politique. En cas de divergence des résultats, annulez d’abord la publication de l’enregistrement AAAA, puis conservez les éléments relatifs aux paquets et au pare-feu afin de corriger le problème.