Bonjour,
Je fais appel à votre expertise aujourd’hui pour confirmer ou corriger ce que je comprends de l’accès à distance au réseau local.
Objectif : primaire permettre l’accès au NAS de l’extérieur. Secondaire : permettre d’héberger d’autres fonctionnalités accessibles de l’extérieur.
 
Matériel à disposition :  
box internet salt
Nas qnap (ts 431 kx)
Switch ubiquiti flex 10gbe  
Raspberry Pi
Pas d’ip fixe ipv4 mais stack ipv6 fonctionnelle
 
Vu le track record de qnap je ne veux pas passer par leurs solutions pour exposer le NAS au monde, je pensais le mettre derrière un vpn mais voilà, la box ne permet d’héberger le serveur VPN qu’avec l’option adresse fixe ipv4
 
L’idée est de le faire autant pour l’aspect pratique que pour le sport en ipv6.
 
Dans ma compréhension des choses, je peux héberger un serveur vpn sur le raspberry et y accéder depuis l’extérieur grâce à son adresse ipv6 à défaut de l’ipv4 qui n’est pas exploitable à cause du double nat. A partir de là suivant la configuration je peux taper sur les différents services et appareils hébergés sur le réseau.
Question : c’est juste ou je me trompe ?  
 
Comment faire ça de manière sûre ? Si je n’expose pas le NAS au monde entier c’est pour ne pas donner accès par une autre porte aux scripts kiddies et autre plaisantins.  
Question 2 : Est-ce qu’un appareil réseau type ubiquiti Cloud Gateway Fiber ou autre permettrait d’avoir une solution sure clé en main ?
 
Merci à ceux qui pourront confirmer ou infirmer ce que je pense, bon dimanche.
 
Édit : NAT -> double NAT

 
Quel est le problème avec le NAT ? Tu ne peux pas faire un port forwarding ?
Ensuite oui tu peux héberger un service en IPv6, par contre ton range IPv6 est bien fixe ? Car sinon c'est le même problème qu'en IPv4.
Et bien sûr, service hébergé en IPv6 only = service joignable seulement depuis les connexions internet IPv6.
 
 

 
je ne connais pas la solution ubiquiti. Je pense que chaque solution est à étudier au cas par cas, sans oublier aussi que la sécurité tient autant à la solution choisie qu'à l'implémentation qu'on en fait (suivi des bonnes pratiques, des mises à jour software, veille sécu sur les failles découvertes etc).

 
Hello,
Merci pour ta réponse, pardon je suis derrière un cgNAT ou double NAT (j’édite) donc un NAT que je ne contrôle pas, pas possible de faire un déclenchement de port et choses habituelles sur une connexion habituelle.
 
Si mon range ipv6 n’est pas fixe, est-ce qu’un équivalent du DNS dynamique existe ?  
Il faut que je monitore l’adresse IPv6 quelques temps pour confirmer si c’est fixe ou non c’est juste ?

 
Tu as vérifié que les connexions entrantes vers ton IPv6 arrivent jusqu'à toi, qu'elles ne sont pas également bloquées au niveau de l'opérateur ?  
 

 
Oui rien ne t'empêche d'avoir un nom DNS que tu mets à jour automatiquement quand ton IP change.
 

 
Oui et en tentant de te déconnecter/reconnecter aussi peut-être.

 
Quel est le meilleur moyen de vérifier ?
 
J’ai installé WireGuard sur le raspberry pi, il marche en local mais je n’ai pas osé désactiver le firewall sur la box encore, d’où ma question sur la sécurité dans mon message initial.  
Je déconnecte tout de la box sauf le raspi, je vire le firewall et j’essaye de me connecter en WireGuard ? Il y a une solution plus simple au cas où le WireGuard est mal configuré à base de netcat ou de ping ou autre outil ?
 
De temps en temps dans le log du firewall du nas j’ai des connections refusées en ipv4, je ne sais pas comment c’est possible.

tu peux tenter un ping depuis l'extérieur vers une IPv6 actuellement attribuée à une de tes machines sur le LAN. La machine doit être configurée pour répondre au ping bien sûr. Tu peux aussi lancer un wireshark/tcpdump dessus pour avoir une vue plus bas niveau des paquets qui arrivent dessus, pour avoir moins de chance d'être perturbé par un éventuel filtrage sur la machine elle même.

au lieu du ping depuis l'extérieur tu peux aussi tester un telnet sur n'importe quel port pour valider la connectivité TCP. S'il n'y a pas de service en écoute sur ce port tu devrais recevoir un connection refused ou même peut-être rien, mais le plus important c'est de voir que le TCP SYN est bien arrivé à destination, avec wireshark/tcpdump.