Le blog de Genma
Vous êtes ici : Accueil » Yunohost » Autohébergement - IPv6 - Le soucis du NAT

Autohébergement - IPv6 - Le soucis du NAT

D 2 mai 2016     H 09:00     A Genma     C 7 messages   Logo Tipee

TAGS : Free, Freebox, Freemobile Auto-hébergement Raspberry Pi Planet Libre Yunohost IPv6

Ce billet est un premier billet d’une série qui aura pour titre Autohébergement - IPv6

Depuis que je me suis mis à l’autohébergement, j’apprends de plus en plus de choses (certe je le fais déjà avant et depuis longtemps vu que je suis autodidacte). Je sais depuis longtemps que la Freebox est un routeur qui fait du NAT (pour savoir ce qu’est le NAT). Je lisais régulièrement les critiques de Stéphane Bortzmeyer sur le NAT, la pénurie d’IPV4, la nécessité d’IPV6, sans réussir à définir simplement le pourquoi du soucis du NAT.

Et c’est via la conférence de Stéphane Bortzmeyer (toujours lui) sur L’internet des objets support de conférence disponible ici http://www.bortzmeyer.org/files/objets-esclaves-SHOW.pdf que j’ai pu "enfin" comprendre la problèmatique du NAT (et mettre de mots dessus).

Si une des machines est en dehors du réseau local, il faut un rendez-vous Avec la pénurie d’adresses IPv4, quasiment tout le monde est derrière un routeur NAT : pas de connexions entrantes

Avec un NAT et IPv4, je ne peux pas avoir plusieurs serveurs webs facilement qui écoutent sur le ports 80-443. Je dois changer les ports d’écoutes si je veux avoir plusieurs serveurs.

Formulé autrement, derrière un NAT, les machines du réseau locales peuvent parler sans soucis à un serveur extérieur. Mais les machines derrière la Freebox ne sont donc pas directement connectés à Internet (sauf si on les mets en DMZ, mais c’est une autre histoire). Donc, depuis l’extérieur, comment je peux parler facilement à mes machines locales ? Si je veux plusieurs serveurs webs ? Je peux faire une solution qui consistera en lancer le VPN de la Freebox pour arriver derrière le NAT sur le réseau local. C’est une solution. Mais elle ne me plait pas car elle ne me permet qu’à moi d’accéder à mes machine sde mon réseau. Mais si je veux plusieurs serveurs webs qui écoutent chacun sur les ports 80-443 par exemple, la seule solution est de se passer du NAT et donc d’être en IPv6, là où la notion de NAT n’existe plus, vu que chaque machine a alors une IPv6 publique (et non plus une IPv4 publique partagée, appartenant à la Freebox et nécessitant des redirections de ports).

J’ai donc très sérieusement commencé à m’intéresser à IPV6 et bien que geek, linuxien, et technophile, ça n’a pas été une mince affaire. D’où la série de billet à venir ces prochaines semaines initiée par celui-ci.

7 Messages

  • Pour quoi ne pas utiliser le reverse proxy d’NGINX ?
    Par contre tu pourras rediriger que le http(s).
    Perso mon serveur YUNO est en DMZ et c’est lui qui gère l’accès http(s) aux autres machines auxquelles je veux avoir accès depuis l’extérieur


  • Pour avoir plusieurs serveurs web avec ipv4, il y a une solution : avoir un reverse proxy en amont vers lequel toutes les requêtes sur port 80/443 vont taper, qui redirige vers les ipv4 internes (voire les ipv6, c’est ce que je fais), en fonction du fqdn du serveur recherché par exemple. C’est franchement crade et ça illustre bien à quel degré de bricolage on en est arrivé avec ipv4, mais ça marche.


  • Hate de voir la suite, c’est effectivement un problème que de très très nombreux auto-hebergés ont a solutionner, ce sera aussi mon cas un jour ou l’autre.


  • "en fonction du fqdn du serveur recherché par exemple. C’est franchement crade et ça illustre bien à quel degré de bricolage on en est arrivé avec ipv4, mais ça marche."
    Je comprend pas très bien pourquoi la solution du reverse-proxy est "moche" ou "crade" à tes yeux, mais c’est exactement la solution retenue par TLS pour pouvoir utiliser plus d’un certificats SSL sur la même ip : "sni" pour Server Name Indication.
    En faisant du load-balancing web, par exemple, tes certificats ne sont pas sur tes X VMs, mais seulement sur le RP, donc une VM tombe/pb/etc... tu restores assez facilement ta VM, exemple parmis tant d’autres, Let’s Encrypt n’a besoin d’un client que sur le reverse pour gérer les certificats de X serveurs/ndd derrière etc... (du coup sa soulève le problème de centraliser ces certs sur une seule machine, forcément)
    Le principe est logique et clair, la mise en place est souvent le problème, que ca ne convienne pas tout à fait, c’est différent non ?


  • Bonne introduction à l’IPv6 encore trop méconnu, je suis impatient de voir la suite des billets traitant ce sujet.


  • Je pratique le "télémaison" (terme que j’ai découvert sur ton site) depuis près de 4 ans. J’ai chez moi un nas (synology) qui heberge mes sites web qui son plus des outils (shaarli, dokuwiki, ...) et un raspberry pi (reverse proxy NGINX qui distribut les différents sous domaine vers les site ad hoc). Bref tous ce petit monde est derrière une freebox v6 qui gère l’ipv4 et v6.

    Le soucis avec l’ipv6... c’est que partout ou j’ai l’occasion de travailler (presta), il n’y a pas d’IPV6, les grands compte on une forte tendance à être leur propre FAI et ne considère pas IPV6 comme un bon investissement. Du coup, l’ipv6 ne me sert a rien sauf avoir besoin de coller un pare-feu sur toute mes machines. Et comme ipv4 est le seul à passer faut en plus que je me cogne les règles de routages sur ma box, pour que je puisse parler à tous le petit monde qui ce trouve derrière ma box.

    Autre point, freemobile n’est pas non plus en ipv6... pour le coup rien ne passe non plus de se coté là.

    Pour faire simple, j’ai accès à ipv6 de chez moi à chez moi. La grosse loose de l’ipv6 (j’attend depuis 2ans mais je ne vois pas grand chose bouger) c’est que ça ne fonctionne que depuis un particulier vers un autre particulier.

    En sécurité, tu parle de surface d’attaque... avec ipv4 et le nat, tu as 1 machine qui constitue un point faible. Avec ipv6 chaque machine de ton réseau dispo en ipv6 est vulnérable ce qui nous fait une surface N fois plus grande pour N machine en ipv6. Donc avec ipv4 tu peu former un goulot d’étranglement (cf. chokepoint sur wikipedia) et ça s’est bien =).

    Ce qui fait que pour les services web un reverse proxy c’est très bien. Reste alors le problème de connexion ssh, personnellement, je redirige les flux de type NNdernier nombre de l’ip (pour la machine 192.168.0.2 on aura 2202 ou 22002 au choix) après tu peux toujours profiter de ton reverse proxy comme machine de rebond vers ton lan... voir utiliser un vpn.


  • A l’IPV6 le mythe suprême, sur le papier c’est bien, en pratique dans une structure importante, on va attendre un peu d’avoir des ressources financières et humaines pour gérer 2 réseaux...