Longtemps j'ai disposé de deux lignes vDSL à 90 MB en étant proche du DSLAM. Il y avait un peu de bricolage, la Freebox en bridge sur le WAN1 de l'UDMP et Nerim en NAT entre le WAN2 (secours) de l'UDM Pro et vie le LAN sur un subnet différent sur MPTCP et OTB. Je sais, pas très propre, mais c'est juste un labo... Et c'est pourquoi on va optimiser un peu, d'autant plus qu'entre temps je me retrouve avec une fibre SFR et ma Freebox Révolution migrée elle aussi en fibre.

Versions utilisées, relativement stable par rapport à ces derniers mois :

• UDMP : 1.10.0
• Network : 6.4.47

Swap des ports WAN de l'UDM Pro

Avec l'idée migrer la Freebox Révolution vers une Delta S afin de profiter d'un lien à 8 GB, j'ai commencé par swapper la logique des deux ports Wan de l'UDMP. De base le port 9 en 1 GB (RJ45) correspond à WAN1 et le port 10 en 10 GB (SFP+) à WAN2. On peut se demander ou est leur logique tant il est évident que le lien principal sera plus performant que le lien de secours. Depuis je ne sais plus quelle beta il est possible d'inverser cette logique, mais attention il reste un bug de taille, le nom du provider (probablement lié à l'ASN) ne sera pas mis à jour et on reste avec ceux de base, et ça peut être déroutant. Comme on le voit ci dessous le port WAN1 avec la Freebox remonte OwCloud (anciennement Nerim racheté par BT), alors que le WAN2 est maintenant branché sur du SFR...). Ce bug est connu, mais comme d'autres il ne semble pas être dans les priorités des équipes Unifi qui préfèrent surement se concentrer sur une nouvelle version de l'interface...

Passer mon mélange de subnets en VLAN

C'est logique, il faut juste trouver un peu de temps. Et on va voir que du temps j'en ai perdu.

Pour créer un VLAN sur Unifi c'est dans l'absolu très simple. On crée un nouveau réseau et dans les paramètres avancés on choisit un VLAN ID et éventuellement le subnet et le mode DHCP, mais on peut faire sans et dans certains cas laisser faire l'Auto Scale Network. Ensuite on associe ce réseau à un port du switch. Sauf que j'ai passé des heures à chercher à faire compliqué car ça ne fonctionnait pas. Et finalement je me suis résolut à un reboot et là ça passe tout seul. Allez donc savoir...

Dans mon cas je voulait un VLAN sur un subnet particulier avec DHCP. Mon objectif étant d'y coller la box SFR qui sera branchée sur le WAN2 et sur ce VLAN et ainsi sera utilisable par mon fils pour ses jeux qui disposera ainsi d'une fibre rien que pour lui et sans aucune restrictions (il est grand !) et sans venir perturber la QoS du réseau principal, même si l'impact sera moindre via que fibre qu'il ne l'était en xDSL.

Sur le subnet de ce VLAN, la passerelle par défaut est donc la box SFR, comme c'est le cas sur le WAN2 de l'UDM. Les deux usages cohabitent, et la box de secours sert à quelque chose...

On peu ensuite créer un réseau WI-FI sur ce VLAN ou taguer des ports sur les switch (port profile) pour qu'ils l'utilisent.

On verra plus tard comment créer un VLAN dédié à l'IoT et surtout comment ouvrir ou bloquer le trafic entre les VLAN.

UPnP mon amour !

Toute cette partie fonctionnelle, je me suis aperçu que mon routeur VPN/SDN Zerotier (un Linux dans une VM) avait un peu de mal à sortir. Dans la configuration précédente il sortait en NAT via ma ligne de secours. Dans ma nouvelle configuration il doit sortir via l'UDMP, et le vas échéant profiter du secours. Curieusement j'ai remarqué que le passage en mode secours était lent et qu'au retour certaine destinations n'étaient pas joignables, bizzarement celles situées sur le réseau Free, Online Sacaleway pour être précis, alors que d'autres distants passaient. Et c'est critique.

On lance la commande :

root@zt:~# zerotier-cli peers

Et l'on obtient la liste des clients distants :

1d20dgr3f3 1.6.5  LEAF      -1 RELAY
2533gtdaef 1.6.5  LEAF      -1 RELAY
338fgte636 1.4.6  LEAF      13 DIRECT 7131     2944

Si DIRECT veut dire que tout va bien, RELAY indique que le distant est injoignable directement, que le trafic va transiter par les serveurs Zerotier. Et que quand le trafic passe, ce qui n'est pas toujours le cas, cela va induire une latence aléatoirement plus importante, au minimum 35 ms. là ou en direct on passera à 12 ms. Et justement, au delà de remplir les poches des Telcos, l'un des objectifs de la fibre est de réduire la latence (même si avec le l'IPV4 encapsulée dans de l'IPV6 on en perd un peu, mais c'est un autre problème et il faudra se pencher sur du full IPV6).

Après moultes recherches j'ai trouvé que 

1. Que l'UDMP bloquait peut être certains ports en sortie, même si on désactive toute la partie sécurité et que tout est autorisé sur le firewall (pas clair !)
2. Qu'il est possible de configurer des ports UDP secondaires sur un client (en plus du port UDP natif 9993.

On commence donc par configurer un port secondaire (on ne touche surtout pas au primary (voir ce fil vers la fin) sur le client qui me sert de routeur ZT en créant un fichier local.conf dans le bon répertoire (détails ici) :

{
  "settings": {
    "secondaryPort": 21234
  }
}

Mais visiblement ça ne suffit pas et il va falloir activer l'UPnP pour que tout passe en direct avec un minimum de latence :

Je ne suis pas fan de l'UPnP/NAT-PMP car ce protocole d'automatisation ouvre par définition les ports à la demandes des applications. Applications qui sur un réseau peuvent êtres malveillantes. Pourtant à la maison ce service est très utilisé et quasiment indispensable. Par contre hors de question d'utiliser cette méthode en entreprise ou une règle WAN_LOCAL avec la destination UDP 9993 devrait faire l'affaire (pas clair et à creuser). (ici pour pfsense avec ACL en prime, ce qui va aider en entreprise).

ZT Failover ?

Alors là on rentre dans le coté obscur. Tant qu'à avoir deux fibres autant qu'elles servent à quelque chose. Visiblement l'UPnP de l'UDM Pro est archi buggé. Je me suis donc dit que j'allais faire le failover directement dans le routeur Zerotier. J'ai donc ajouté une carte réseau virtuelle à ma VM ZT qui me sert au routage Lan to Lan (ici et là pour monter ça) sur le VLAN 110 qui correspond à la box SFR. Les deux interfaces ont une passerelle par défaut avec le même poids. 

Ensuite on édite le fichier local.conf et on ajoute et on ajoute ces paramètres : 

{
  "settings":
  {
    "defaultBondingPolicy": "active-backup",
    "peerSpecificBonds":
    {
      "f6dd3a2db3":"active-backup",
      "1d20ff53f3":"balance-xor",
      "a92cbsd6fa":"broadcast"
    }
  }
}

Pour comprendre les différentes possibilités on ne trouve pas beaucoup d'information si ce ne sont deux docs officielles ici et là ! A croire que ce sujet intéresse peu. Attention, j'ai eu pas mal de difficultés en éditant avec Nano ce fichier avec un copié / collé. Peut être une question de formatage qui m'aurait échappé. Par contre je n'ai pas réussit à associer dans ces paramètres le port secondaire.

Toujours est-il que si je débranche un interface l'autre prend le relais en mode active-backup avec une légère interruption que quelque secondes ou encore plus rapidement en mode broadcast. Mais ce dernier mode semble déconseillé car il génère pas mal de garbage...

Design

Si j'étais un cador en Visio ou d'autres outils en ligne comme draw.io ou autres, je pourrais vous faire un joli dessin, mais ce n'est pas le cas. Donc :

• WAN1 : Freebox en mode bridge (je voulais tester la Freebox Pro mais elle n'a pas ce mode).
• WAN2: Secours en NAT sur une box SFR. NAT également accessible sur les ports tagués en VLAN 110 sur un subnet dédié et isolé. Cela permet à mon fils de jouer et faire ses bricolages sans impact sur la sécurité du LAN principal.
• VPN vers les sites distants accessible depuis le LAN principal. On verra plus tard comment profiter des fonctionnalités Multipath / Bonding de Zerotier qui vont nous permettre d'utiliser le lien de secours sans passer par celui de l'UDM.

Vieilleries...

Et dans tout ça que devient mon installation openMPTCP ? L'objectif de cette installation était d'agréger plusieurs lignes afin de fiabiliser et d'augmenter le débit disponible. Si la question du débit se pose en en xDSL elle ne se pose plus avec une fibre. Quant à la fiabilité il faudrait pour que ça ait du sens disposer d'un VPS puissant avec un lien 10 GB. Et encore on aurait malgré tout une latence dégradée. 

Mais je vais tout de même tenter la chose pour le sport. Pour ca il faut que je crée sur mon ESXi une nouvelle interface sur le VLAN 110 afin d'accéder au NAT de la ligne de secours et éventuellement le modem 4G. L'objectif n'est pas la performance, je ne toucherait donc rien coté VPS, mais juste d'éviter le lag qui se produit quand l'UDMP passe sur le lien de secours. Mais ça reste très rare et je ne sais pas si le jeu en vaut la chandelle. Peyt être pour l'IoT.