Online.net permet depuis peu de réserver des « IP failover » consécutives sous forme d’un bloc /27.
Avec l’arrivée de l’internet à 100 ou 200Mbits chez le particulier via FTTH, il peut parfois être intéressant d’avoir un serveur chez soi où on peut faire des trucs exotiques qui ne seraient pas faisables ou en tout cas très couteux à faire en datacenter. Mais le problème, c’est qu’avec ce type de connexion, on est systématiquement derrière une box et donc sans IP publique.
Pire, certains opérateurs portant le nom d’un agrume vous forcent à changer d’IP toutes les 24H, ce qui est juste intolérable pour un usage sérieux. (mais j’imagine que c’est fait exprès histoire de vendre les contrats « pro ».)
Voici donc un tuto pour avoir son bloc /27 sur son petit switch à la maison.
1°) Routage ou bridge ?
La question a une certaine importance et, après étude, la réponse est qu’il faut clairement faire du routage même si l’infrastructure est plus compliquée à mettre en place.
Le bridge aurait certainement été la méthode la plus simple pour démarrer mais elle pose des tas de limitations que je vais énumérer tout de suite histoire de bien vous convaincre qu’il faut faire du routage. Tout d’abord, avec un ethernet bridge, on va faire passer dans le tunnel tout le traffic de merde des voisin (dont les broadcast et les requetes ARP, mDNS, NDP, DHCP et toutes ces choses qui font du traffic inutile) Il suffit qu’il y ait quelques machines « sales » dans le réseau de online.net (et y’en a) pour se faire polluer le tunnel avec tout un tas de paquets qui sont à minima inutiles sinon potentiellement néfastes. C’est vrai que si on dispose de 100 ou 200Mbps et c’est confort, mais c’est finalement peu vis à vis du réseau qu’il y a à l’autre bout.
Ensuite, avec un ethernet bridge, il va falloir montrer patte blanche en prenant bien garde à ne diffuser QUE les couples ip/mac autorisées. Ca signifie en particulier que si on et qu’on est pas hyper rigoureux sur le segment réseau ou tout simplement qu’on omet de maquiller la mac des machines physiques en mac « virtuelles », il y a moyen de se faire accuser de spoofing et de se faire désactiver son port réseau. C’est moche! Très moche! Mais l’hébergeur aura raison de le faire.
Enfin, coté performances, en encapsulant dans le tunnel des paquets ethernet plutot que des paquets IP on ajoute à chaque paquet un header de 18 octets, ce qui revient à réduire la MTU d’autant. En pratique, ça signifie un peu d’overhead (+2%) mais surtout une augmentation de la fragmentation et du nombre de paquets donc une dégradation des performances en particulier en ce qui concerne les latences.
Vous voyez bien qu’il faut faire du routage !
2°) Le lien VPN
Comme on va s’interconnecter à l’aide d’une liaison grand public et probablement via une box d’opérateur qui fait du NAT (et certainement un peu de magie noire genre Qos), il y a de fortes chances pour que les protocoles de tunelling « simples » comme GRE ou éventuellement IPSEC ne passent pas ou très mal. Par ailleurs l’IP publique ce cette connexion est susceptible de changer, ce qui signifie qu’on sera contraint d’adopter un fonctionnement en mode client-serveur et non d’égal à égal.
L’idéal est donc de travailler avec une couche transport client-serveur réputée pour bien traverser le nat à savoir les incontournables TCP et UDP. Si l’opérateur respecte le principe de neutralité de l’internet (gare au troll velu) il faut préférer UDP qui a l’avantage d’être un protocole non-connecté qui laisse aux connexions transportées le soin de gérer elle-mêmes la perte de paquets de la façon qui leur est le plus appropriée. Par contre, si il y a des « protections » halacon du genre limitation du nombre de paquets UDP, alors on peut être amené à utiliser TCP, qui, quoique théoriquement moins adapté, peut dans certains cas se révéler plus performant.
L’outil libre adapté pour ça est OPENVPN
3°) le réseau /27
L’idéal pour être tranquille est de créer un réseau « standard » où il n’y a pas de choses exotiques, même si ça bouffe 3IP.
Ca veut dire qu’on réserve à minima 1 IP de « réseau », 1 IP de « broadcast » et une IP « gateway » pour chaque segment exporté. Comme les IPv4 sont une denrée de plus en plus rare, on aura donc sérieusement intéret à ne pas multiplier inutilement les segments.
( un /27 ou deux /28 mais c’est très discuttable pour les /29 et au dela il faut revenir au bridging.)
Je choisis de respecter les conventions en affectant systématiquement pour passerelle la dernière IP du réseau.
Par exemple, pour le réseau
L’ip de réseau est
L’ip de broadcast est
L’ip de passerelle est
Par la suite j’emploierai
pour désigner une machine quelconque du réseau
c’est à dire avec N tel que
4°) Configuration de la passerelle.
J’utilise une machine x86 sous debian7 avec 2 cartes réseau.
-
sera l’interface dite « internet » c’est à dire celle qui permet se connecter au net via un lien ADSL ou FTTH.
sera laissée en mode dhcp (ou une configuration statique de votre choix, pourvu qu’elle permette d’accéder au net, directement ou via du NAT).
-
sera l’interface dite « prod » c’est à dire celle où sera présent votre réseau public en /27.
sera configurée en static avec les valeurs suivantes dans /etc/network/interfaces :
auto eth1
iface eth1 inet static
network X.Y.Z.T
address X.Y.Z.T+30
netmask 255.255.255.224
broadcast X.Y.Z.T+31
on pourra éventuellement configurer un DHCP sur ce réseau mais ça ne me semble pas une excellente chose que de configurer ainsi un réseau public.
Le risque d’y connecter accidentellement une machine insuffisamment firewallée me semble trop important.
Configurer OPENVPN en mode client pour qu’il établisse un tunnel IP avec le serveur.
On choisira pour ce tunnel une plage d’adresses IP privées « improbable » comme par exemple
Soyez inventif, plus c’est bâtard et moins il y a de risque de tomber plus tard sur un cas à la con du style plage employée ailleurs dans votre réseau ou ses ramifications.
Une fois que les 2 machines se ping l’une l’autre sur le réseau privé
, il va falloir expliquer à votre passerelle que son ip principale est X.Y.Z.T+30 et que sa route par défaut n’est plus de passer par votre FAI-box mais est par le serveur qui est à l’autre bout du VPN (sauf évidemment lorsqu’il s’agit de communiquer avec le dit serveur $IPGATEWAYVPN pour établir le dit VPN).
pour cela on commence par repérer la passerelle par défaut que le dhcp nous a donné
ip route list | grep default
ce qui dans mon cas retourne
default via 192.168.20.253 dev eth0
On duplique alors cette route en la rendant spécifique au serveur.
ip route add $IPGATEWAYVPN via 192.168.20.253 dev eth0
et on supprime la route par defaut
ip route del default via 192.168.20.253 dev eth0
que l’on recrée pour passer via le tunnel.
ip route add default via 10.234.147.178 dev tun0 src X.Y.Z.T+30
Tada !
désormais tout le trafic passe par le tunnel sauf ce qui sert à l’établir.
J’attire l’attention sur l’option src de la dernière ligne qui permet de communiquer avec l’extérieur en utilisant l’IP (publique) qui sert normalement à eth1. Sinon, les connexions seraient établies en utilisant par défaut l’ip de tun0 qui se trouve ne pas être globalement routable.
5°) La ruse.
Mais pourquoi ça ne marche toujours pas ?
Parce que les routeurs de online.net s’attendent à ce que vous fassiez des machines virtuelles ou des alias et donc que les machines du réseau X.Y.Z.T/27 soient directement bridgées sur l’interface de votre serveur. Soit avec une mac virtuelle soit avec la mac de la dedibox elle-même.
Sauf que justement, la dedibox ne considère pas que ces IP lui soient locales puisqu’elle n’est qu’une passerelle pour les atteindre. Du coup lorsque le routeur demande en ARP quelle est la mac de X.Y.Z.N, il ne reçoit aucune réponse et drop le trafic.
L’astuce consiste donc à dire au routeur que la mac de notre dedibox porte bien ces ip (même si c’est pas vrai) et qu’il peut nous envoyer leur traffic. En pratique ces paquets seront routés via le tunnel mais ça, le routeur de online n’a pas à le savoir, c’est notre problème… De sont point de vue, ces paquets vont bien à notre dedibox et c’est tout ce qui compte.
Pour cela, nous avons 2 possibilités :
- tenter de répondre aux requetes ARP du routeur (dur dur)
- ou prendre les devant et le lui dire avant qu’il n’éprouve le besoin de demander.
Je choisis la seconde solution. L’outil nécessaire pour faire les réponses ARP gratuites est arping (Attention, celui founi par le paquet iputils-arping)
Le cache arp du routeur est de 30 minutes.
Du coup, en renouvelant toutes le 5 minutes, on est tranquiles.
(Article en chantier, la suite plus tard…)
