Auteur Sujet: Retour d'expérience sur ma stack (mikrotik-Ubiquiti double FAI SFR et Free)  (Lu 4738 fois)

0 Membres et 1 Invité sur ce sujet

doctorrock

  • Abonné Orange Fibre
  • *
  • Messages: 931
  • Draguignan 83
Hello à tous.

Petit retour d'expérience de ma config.

Déja, le petit schéma qui va bien, comme ça on y voit plus clair pour la suite.



Donc voila, après avoir fouillé quelques temps sur le forum, je me suis mis à monter ma propre stack; et maintenant je viens partager mon expérience.
En effet, monter sa propre stack coute de l'argent, et pas qu'un peu (la mienne ici présentée, tout compris, m'a couté 800€) , donc il faut vraiment éviter de se tromper dans ses choix !

Je précise qu'avant tout ça, je tournais déja sur une stack Mikrotik, et que j'ai de bonnes notions générales en réseau , il ne me manquait donc plus qu'à "me lancer" dans la "semi-professionnalisation" de ma stack.

J'ai rien de spécial : un Raspberry Pi pour la supervision et d'autres services, un PC fixe, un PC "serveur" dans une mini ITX, un NAS, du wifi , etc...

Tout d'abord le rack.

J'ai déja bossé en salle serveur, avec des baies et des racks 19" , mais je n'avais pas pour autant pensé aux contraintes de l'achat personnel.
J'ai beaucoup galéré concernant les dimensions. Je possède un tout petit chez-moi , j'ai peu de surface ; pour moi, le rack devait rentrer dans un espace précis : mon meuble TV , et bien s'encastrer dedans.
Voici ce que ca donne :



Le gros problème des racks, c'est qu'ils ont beau faire 19" de large (attention, ils existent aussi en 10"), il s'agit là de la largeur entre les 2 rails. Après, chaque constructeur va construire le caisson métallique autour, et prendre des marges.
Il existe des tonnes de racks qui font 600 de large, mais moi, 600 de large ça passait pas.  Idem pour la profondeur : il me faillait une profondeur précise, et là encore, on trouve beaucoup de racks qui font plus.
La qualité enfin, en lisant les retours sur le Web, on s'aperçoit que c'est très inégal. Certains modèles sont vraiment bof, la porte vitrée mal fixée, les matériaux très limites.

J'ai acheté mon rack chez 4xrack.com , seul ce site proposait les dimensions que je voulais avec de l'aération (très important !)
Retour d'expérience : très bon vendeur. Contact par mail pour me conseiller, livraison efficace, et emballage du rack très professionnel. Bref, je recommande.

J'ai pris avec une étagère de rack (attention encore ici aux tailles, notamment en profondeur) pour poser mes box/modems dessus.
Encore une mise en garde : la plupart des racks (la majorité) ne disposent que d'un rail avant. Si vous souhaitez poser du lourd sur les étagères, il serait judicieux de prendre un rack avec des rails à l'arrière aussi, pour fixer l'étagère en 4 points (mais c'est plus dur à trouver).
Fixée sur 2 points seulement (avant gauche et avant droite), l'étagère ne supporte plus que 25% du poids prévu à l'origine. N'espérez pas poser un petit PC dessus ou un NAS, ça risque de casser (ils sont donc posés à coté chez moi, dans l'autre compartiment du meuble TV).

Enfin, 2 ventilos 12cm , 220V  (pas 12V, ils se branchent direct sur le 220, pas de transfo) fixés sous la plaque du dessus, en extraction. Là aussi : certains racks proposent une rampe toute faite (avec thermostat et régulateur), ce n'était pas mon cas. Je n'ai pas de thermostat, mais j'ai du acheter un régulateur de tension parce que les 2 ventilos à fond, c'est beaucoup trop bruyant. Je les ai donc bêtement branchés sur un variateur de tension 220 , et ça marche nikel (ça reste "manuel")
Selon le matos utilisé, ça peut vite chauffer dans un caisson confiné. Il faut une aération active dans un tel cas, le régulateur me permet de régler pile les ventilos pour qu'ils soient silencieux, mais actifs.



Passons à l'internet

Au départ, je pars d'une connexion SFR, sur support cablé (DOCSIS) depuis migration Numéricable. La connexion et le matos "LaBox" fonctionnent très bien, et tournent à 100Mbps - 5Mbps
Puis j'ai toujours voulu essayer de jouer avec 2 connexions. Je me suis donc abonnée à Free via leur promo vente-privee : une box avec accès ADSL , pour 2€/mois. C'est un prix ridicule ; je me suis donc abonné. Evidemment, ca reste de l'ADSL et ma ligne n'est pas fameuse : je l'ai mesurée à 13Mbps - 1Mbps
Mais c'est largement suffisant pour mes besoins ! (que je vais expliquer après).

Au final, j'ai donc 2 FAIs, et 2 connexions à Internet, une SFR/NC à 100Mbps, et une "de secours" Free à 13Mbps.

Présentons maintenant la stack :


Je reçois la TV par le câble, la TNT.  J'ai une offre SFR de TV, LaBox me fournit donc la TV, même si cette partie ne m'interesse que peu (je ne suis pas consommateur de TV).
Ma connexion Free, en théorie, devrait me passer de la TV que je devrais pouvoir récupérer dans un VLAN , mais j'ai quelques soucis sur ce point (en gros, j'ai branché une seule fois la FreeBox TV, elle s'est mise à jour, et depuis, elle ne s'allume plus... Je ne peux pas donc valider d'éventuelles CGV, ou "voir" ce qu'il se passe ; mais qu'importe ...)



Le routage :



Comme j'ai dit, j'étais déja chez Mikrotik avant.  En fait, un pote et moi sommes (avons été) ingénieurs réseau dans une boite IT (sur de la prod Web). Le matos, on connaît pas mal, et on voulait tester un outsider hors des sentiers professionnels battus (Cisco, Juniper). En 2012, on s'achète pour nos besoins persos le produit d'appel de chez Mikrotik, le RB2011UiAS-IN

On a été bluffé. Pour 120€, on avait un matos de folie, qui fait .... tout. Tout ce que du matos pro (dont nous avions l'habitude) peut faire. Évidemment, à ce prix là, il ne faut pas s'attendre à soutenir des milliers de connexions sur du Gbps, mais ne serait-ce que la licence hyper avantageuse de l'OS (RouterOS) et la simplicité de configuration : on a été séduit.

Aujourd'hui donc, je change ce petit routeur SOHO par du matériel plus costaud, mais je reste chez Mikrotik. J'ai l'expérience, et pour du SOHO c'est clairement un vrai challengeur de Cisco notamment point de vue licence et tarif.

Attention par contre, le modèle que j'ai pris est en 1U avec refroidissement actif. Et à 1200Mhz le CPU, même à 0% de load, les ventilos sont allumés et font du bruit.
Pour le moment, je l'ai downclocké pour faire tomber la vitesse ventilo parce que sinon, c'est assez hardcore (mais c'est normal). On ne peut malheureusement pas jouer beaucoup sur le mode "manuel" des ventilos chez Mikrotik, en fait, on peut rien faire sauf baisser la fréquence du CPU (que je remonterai dès que j'en aurais l'utilité).

Je ne vais pas détailler toute la conf ici, il y en a une grosse tartine. Éventuellement je répondrai sur ce topic si nécessaire ^^
Simplement, mes 2 connexions Internet me permettent de faire de l'ECMP , en gros, j'ai une route par défaut 0.0.0.0/0 avec 2 passerelles, et le routeur se charge de dispatcher les connexions sortantes sur les 2 connexions WAN. Je peux bien sûr prendre la main la dessus, et utiliser par exemple la connexion SFR en priorité , puis basculer sur Free lorsqu'elle sature au delà de xx% .

Je gère aussi de l'entrant. Je fais passer les services entrants par Free s'ils sont peu gourmands, par SFR sinon. Pour ça, je possède 2 sous-domaines pour m'atteindre clairement distincts : sfr.xxxx  et free.xxxxx  , comme ça, je sais quel accès je donne.

Si quelqu'un en face avait aussi 2 portes d'entrée (ou de sortie, selon comment on regarde), on aurait pu s'amuser à s'annoncer des routes avec OSPF, en faire tomber une, et constater la convergence rapide via OSPF. Pour le moment, je m'amuse seulement avec des potes ayant une seule route d'entrée. On est donc en VPN et on s'échange nos routes internes via BGP , c'est tout.
On pourrait s'amuser avec un relai exterieur aussi. Bref, c'est pas les possibilités qui manquent avec ce genre de stack ^^

Le switch :

Je voulais tester de l'Ubiquiti. Je connaissais de nom, mais jamais eu d'expérience. Merci le forum qui m'a montré que pas mal de gens utilisaient cette marque (en routage surtout). Donc, je me suis dit pourquoi pas.

J'ai donc pris un ES24-Lite.


Pas grand chose à redire. Il fait le boulot. Ah si, j'ai hésité avec la gamme du dessus qui font Poe.
2 points m'ont fait basculer : le prix déja. Le Poe coute presque 2 fois le prix. Certes, j'ai une borne Wifi poe, et mon routeur Mikrotik peut aussi être alimenté en poe ; mais pour un prix qui double ... Ca fait quand même mal.
Autre point, d'après les retours (forum), le modèle Poe chauffe beaucoup, et sa ventilation active est très bruyante, même lorsque le poe ne fonctionne pas. De quoi me casser les oreilles et rajouter du bruit à celui déja présent du routeur...

Bref, je suis resté sur un modèle simple et sobre, sans poe, mais qui néanmoins gère tout ce dont on est en droit d'attendre d'un switch SOHO. Il est même capable de router en L3 (je n'utilise pas bien entendu), il gère le mirroring, l'IGMP Snooping, et bla bla bla...
Surtout : il a un refroidissement passif : pas de ventilos dans le switch  :)

Le wifi

Le wifi est supporté par une borne TP-Link EAP120.



C'est pas de la borne Meraki, mais ça coute bien moins cher, ça n'a pas besoin de contrôleur, c'est pas "moche" et ça supporte le POE, les VLANs, le 802.1X pur du Wifi N à 300Mbps.
Bref, ça me va.

La borne diffuse 2 SSIDs , un privé qui est relié sur mon réseau local interne, un autre SSID que je donne aux gens qui passent chez moi, qui est routé sur un VLAN particulier qui utilise uniquement la connexion Free en sortie, et ne peut accéder à aucune machine du réseau local interne.

Anonyme

  • Invité
Merci pour ce retour d'expérience.
Il me semble avoir vu beaucoup interrogations sur ce type de configuration double WAN
Pour du SOHO je n'ai pas le sentiment d'avoir vu de réponses bien satisfaisantes. (sans entrer dans des besoins pro d'implèmentation ospf/bgp)

Peut-être pourrais tu présenter l'aspect technique pour nos lecteurs ayant ce type de besoins ?

doctorrock

  • Abonné Orange Fibre
  • *
  • Messages: 931
  • Draguignan 83
Hello.

Ben j'ai déja présenté comment je l'utilisais , vous voulez savoir quoi d'autre ?

PS : Si la fibre (la vraie) , arrive chez moi dans l'année (c'est fort probable) , je vais me retrouver avec non plus 2 mais 3 FAIs, et 3 IP de sortie  :D

Anonyme

  • Invité
Peut être présenter l'implèmentation de sortie sur différentes IP publiques. :)

doctorrock

  • Abonné Orange Fibre
  • *
  • Messages: 931
  • Draguignan 83
J'ai présenté comment j'ai fais techniquement.

Une route par défaut 0.0.0.0/0 , avec comme passerelles mes 2 passerelles de sortie.

3 A S  ;;; SFR
        0.0.0.0/0                          79.95.12.1                   2
4   S  ;;; FREE
        0.0.0.0/0                          81.56.115.254             3
5 X S  ;;; ECMP
        0.0.0.0/0                          81.56.115.254             1
                                                 79.95.12.1       

C'est très simple à mettre en place. La balance se fait un peu comme du LACP : un couple ip-src:port-src / ip-dst:port-dst est garanti de prendre toujours le même chemin.
Un simple modulo est effectué pour le hash.

Ca peut poser des problèmes lorsque la table de routage principale se met à jour : la connexion peut alors passer d'une passerelle à une autre, mais les cas sont rares.
Aussi, ça va poser des problèmes sur les connexions "related", comme pour le cas de FTP.  Mes ces cas sont marginaux (me concernant), et peuvent être détournés avec des règles insérées à la main dans la table de routage.

Hugues

  • AS2027 MilkyWan
  • Modérateur
  • *
  • Messages: 12 425
  • Lyon (69) / St-Bernard (01)
    • Twitter
Le souci, c'est que ce genre de conf est basée sur du NAT, dès que tu veux faire de l'IPv6 ou de l'IPv4 sans NAT, faut commencer à jouer avec BGP et OSPF (et je ferais surement un post quand j'aurais réussi à mettre ça en prod chez moi)

doctorrock

  • Abonné Orange Fibre
  • *
  • Messages: 931
  • Draguignan 83
Gros oubli de ma part en effet : je suis full IPV4 (donc NATé sur mes 2 IP de sortie).

Justement, j'aimerai jouer plus avec BGP et OSPF, pour le moment, je m'amuse avec uniquement en VPN avec d'autres Mikrotik, une simple annonce BGP.
Mais Free propose de l'IPV6 , je vais devoir tester ça prochainement ;-)

Hugues

  • AS2027 MilkyWan
  • Modérateur
  • *
  • Messages: 12 425
  • Lyon (69) / St-Bernard (01)
    • Twitter
Ben si tu veux le faire avec deux connexions, deux choix :

nat66, mais ça ne marche qu'en sortant
bgp/ospf et un serveur dédié/routeur relié aux deux routeurs :)

doctorrock

  • Abonné Orange Fibre
  • *
  • Messages: 931
  • Draguignan 83
Retour d'expérience sur ma stack (mikrotik-Ubiquiti double FAI SFR et Free)
« Réponse #8 le: 17 janvier 2018 à 14:59:26 »
Salut à tous , je reviens compléter mon retour en détaillant un peu ce que j'ai fait de cette stack (voir message 1) , qui a un peu changé depuis , mais ça n'a que peu d'importance pour la suite. (donc : relire message 1 du topic si nécessaire pour s'impreigner).

La stack reste la même : 2 FAI , full IPV4 , le débit SFR a monté depuis à 150/20 ; sympa.
Free est en IP fixe, mais celle de SFR est "susceptible à changement" (ceux qui connaissent SFR savent de quoi je parle).

Je vais donc détailler ce que je fais de ces 2 connexions dans un pur but de partager et donner des idées aux gens éventuellement.

Je nommerai pas la suite mes 2 WANs ,  FAI1 et FAI2. 
  • FAI1 : SFR fibre/coax 150M/20M , ping 15ms , très stable. IP "non fixe"
  • FAI2 : Free ADSL 13M/1M, ping 65ms, très instable. IP fixe

Le routage, l'accès Internet

Déja, je ne fais pas/plus d'ECMP (relire quelques topics plus hauts) , car certaines appli comme les jeux vidéos ouvrent plusieurs connexions vers des serveurs. Et là , je ne peux pas garantir que toutes ces connexions utiliserons FAI1 ou FAI2 en sticky en sortie (sauf à vraiment me prendre la tête, pour finalement pas grand chose).
Aussi, comme les 2 connexions sont très asymétriques entre elles (150M,15ms/10M,60ms) , ca ne sert pas à grand chose de faire de l'ECMP (une requête sur 2 qui rame , en gros).

En fait, j'utilise FAI1 principalement en sortie, et FAI2 en entrée.
J'héberge quelques services webs persos, et je gère aussi mes propres zones DNS (avec Bind), donc j'ai un peu d'entrée -- absolument pas critique -- je la fais entrer par FAI2 du coup.

FAI1 sert pour la sortie principale (surf, etc...), mais aussi pour certaines entrées plus critiques qui nécessitent un ping bas (serveurs de jeu) et une connexion stable.

FAI2 peut aussi servir en sortie, en fait , il a une route avec une plus grande distance, j'ai donc un fail-over en sortie avec 2 passerelles. Je sors par FAI1 , et si FAI1 tombe, FAI2 prends le relai.
Les passerelles sont pinguées par le routeur pour vérifier, dès qu'elles tombent , la route tombe.

Voici la conf en table de routage main pour les passerelles :

/ip route print where dst-address="0.0.0.0/0" and !routing-mark     
Flags: X - disabled, A - active, D - dynamic,
C - connect, S - static, r - rip, b - bgp, o - ospf, m - mme,
B - blackhole, U - unreachable, P - prohibit
 #      DST-ADDRESS        PREF-SRC        GATEWAY            DISTANCE
 0 A S  ;;; SFR
        0.0.0.0/0                          79.95.12.1                2
 1   S  ;;; FREE
        0.0.0.0/0                          81.56.115.254             3
 2 X S  ;;; ECMP
        0.0.0.0/0                          79.95.12.1                1
                                           81.56.115.254 

Le route ECMP est toujours là, mais désactivée (comme indiqué).

Ce système sympathique comporte par contre des règles de routage un peu touchy.
Par exemple, mes entrées passent par FAI2 , mais ma passerelle de sortie principale est FAI1 , comme je suis en IPV4 NATé en sortie , on ne peut pas router asymétriquement (on va leaker une IP de sortie en plus).

J'ai donc utilisé des règles et des tables de routages distinctes pour avoir des connexions en entrée sticky : si on rentre chez moi (sur mon LAN) par FAI2 , on doit ressortir par FAI2 , et inversement.
Voici les règles :

/ip firewall mangle print detail                               
Flags: X - disabled, I - invalid, D - dynamic
(...)
 2    ;;; dst-nat
      chain=forward action=mark-connection new-connection-mark=From_Wan_Free passthrough=no
      connection-nat-state=dstnat connection-mark=no-mark in-interface=combo1-wan-free log=no
      log-prefix=""

 3    chain=forward action=mark-connection new-connection-mark=From_Wan_SFR passthrough=no
      connection-nat-state=dstnat connection-mark=no-mark in-interface=ether1-wan-sfr log=no
      log-prefix=""

 4    ;;; dst-nat back
      chain=prerouting action=mark-routing new-routing-mark=to_Wan_Free passthrough=no
      src-address=192.168.0.0/16 connection-mark=From_Wan_Free log=no log-prefix=""

 5    chain=prerouting action=mark-routing new-routing-mark=to_Wan_SFR passthrough=no
      src-address=192.168.0.0/16 connection-mark=From_Wan_SFR log=no log-prefix=""
(...)

Ici, l'astuce est dans le "connection-nat-state=dstnat" , ca signifie "Pour tout paquet qui a été destination-natté" , donc en gros, pour tout paquet qui entre par un WAN, et à qui j'ai donné une règle dst-nat pour le diriger sur le réseau interne.
Ca permet d'éviter de matcher tous les paquets en forward, sans pour autant commencer à indiquer les ip-src et ip-dst.
Donc c'est très simple : Pour tout paquet qui rentre par un WAN, et qui va trouver destination (dst-nat), et qui n'a pas déja été vu (no-mark), marque le en fonction du WAN d'entrée. Ensuite, en prerouting, si une machine du réseau interne s'apprête à répondre à un des ces paquets, il aura été marqué (connection-mark) : donc je le dirige vers une table de routage spécifique (routing-mark).

J'ai donc 3 tables de routage : "main" , "to_WAN_SFR" (FAI1) et "to_WAN_Free" (FAI2).

Il m'est donc possible d'envoyer du trafic spécifiquement par FAI1 ou FAI2 , j'ai donc pensé à réutiliser ces tables de routage pour me monter 2 VLANs distincts en plus du VLAN 0 (non taggué, qui utilise la table main).

Les VLANs

  • VLAN0 , untagged : le LAN actuel qui utilise la table main, 192.168.0.0/24
  • VLAN100 qui sera sticky FAI2 en sortie , 192.168.1.0/28
  • VLAN200 sui sera sticky FAI1 en sortie. 192.168.2.0/28
Ces 2 VLANs vont être distribués en internes sur 2 SSID de Wifi différents, ainsi que sur le switch au besoin.
Lorsqu'un invité se pointe chez moi, je lui donne donc l'un ou l'autre des SSID pour le diriger vers Internet via FAI1 ou FAI2 selon mon humeur.

Les 2 VLANs ont des tables de routages minimalistes : ils ne peuvent pas accéder à tout mon réseau privé interne (untaggued) , et ne peuvent communiquer entre eux.
Il est bien entendu possible de ne pas router 0.0.0.0 , ou plutot à notre niveau , de blackholer des IPs ou des ranges.

J'ai donc ceci niveau routage pour les VLANs :

> /ip route print where routing-mark="to_Wan_SFR"                             
Flags: X - disabled, A - active, D - dynamic, C - connect, S - static, r - rip, b - bgp, o - ospf, m - mme, B - blackhole, U - unreachable, P - prohibit
 #      DST-ADDRESS        PREF-SRC        GATEWAY            DISTANCE
 0 A S  0.0.0.0/0                          79.95.12.1                1
 1 A S  192.168.2.0/28     192.168.2.14    vlan200                   1

> /ip route print where routing-mark="to_Wan_Free"   
Flags: X - disabled, A - active, D - dynamic, C - connect, S - static, r - rip, b - bgp, o - ospf, m - mme, B - blackhole, U - unreachable, P - prohibit
 #      DST-ADDRESS        PREF-SRC        GATEWAY            DISTANCE
 0 A S  0.0.0.0/0                          81.56.115.254             1
 1 A S  192.168.1.0/28     192.168.1.14    vlan100                   1

Sans oublier la NAT de sortie ;-)

> /ip firewall nat print where chain="srcnat"
Flags: X - disabled, I - invalid, D - dynamic
 0    ;;; Internet NAT for private network
      chain=srcnat action=masquerade src-address=192.168.0.0/24 out-interface-list=ALL-WAN log=no
      log-prefix=""

 1    ;;; Internet NAT for VLAN200
      chain=srcnat action=masquerade src-address=192.168.1.0/28 out-interface-list=ALL-WAN log=no
      log-prefix=""

 2    ;;; Internet NAT for VLAN100
      chain=srcnat action=masquerade src-address=192.168.2.0/28 out-interface-list=ALL-WAN log=no
      log-prefix=""

ALL-WAN est une interface virtuelle dont je reparlerai plus tard.

Au niveau du switch, il faut évidemment assigner les VLANs sur le port qui portera la borne wifi.
Je pourrai aussi faire passer les VLANs sur les ports du LAN, ca me permettrait de lier certaines machines qui smokeping l'Internet à FAI1 ou FAI2 spécifiquement du coup (aujourd'hui, je smokeping par la table main.)

La dessus, on peut mettre de la QOS sur les VLANs aussi (autre idée, je n'en ai pas besoin pour le moment), ou au routage directement (faire passer en sortie le surf par FAI2 et le reste par FAI1 par exemple)

Le Firewall (FW)

Au niveau du Firewall, je ne vais pas trop donner de détails (un peu confidentiels tout de même) , mais il faut grouper les interfaces WAN dans une liste d'interfaces, si on ne veut pas faire de bétises par oubli (genre j'ajoute une règle en entrée sur FAI1 et j'oublie pour FAI2).
J'ai donc fait un entonnoir en encapsulant mes 2 WANs dans une interface virtuelle appelée "ALL-WAN" :

> /interface list member print
Flags: X - disabled, D - dynamic
 #   LIST                           INTERFACE                                                                                                                   
 0   ALL-WAN                     combo1-wan-free                                                                                                             
 1   ALL-WAN                     ether1-wan-sfr               

Puis, je rapatrie leur trafic en entrée dans une règle FW spéciale :

> /ip firewall filter print       
Flags: X - disabled, I - invalid, D - dynamic
(...)
 8    ;;; INPUT_WAN
      chain=input action=jump jump-target=INPUT_WAN in-interface-list=ALL-WAN log=no log-prefix=""
(...)

De là, je peux la traiter, par exemple :

> /ip firewall filter print where chain="INPUT_WAN"
Flags: X - disabled, I - invalid, D - dynamic
 0    ;;; Reject Definitive Banned IP
      chain=INPUT_WAN action=reject reject-with=icmp-admin-prohibited src-address-list=Banned log=no log-prefix=""

 1 X  ;;; Accept Trusted Sources
      chain=INPUT_WAN action=accept src-address-list=truste_sources log=no log-prefix=""
(...)

L'interface virtuelle ALL-WAN peut servir partout, y compris en sortie pour la src-NAT (pratique car là encore un oubli peut vite coûter 10min de debug)

Par exemple, ALL-WAN me sert à filtrer les ranges privés pour ne pas les leaker sur l'Internet.

> /ip firewall filter print detail where chain="forward"
Flags: X - disabled, I - invalid, D - dynamic

(...)
7    ;;; Private ranges
      chain=forward action=reject reject-with=icmp-net-prohibited dst-address-list=priv-addr out-interface-list=ALL-WAN log=no log-prefix=""
(...)

Les VPN

La partie intéréssante commence. J'ai 2 sorties, et donc du fail over. Si je me connecte en VPN à d'autres infras (de confiance donc), je vais pouvoir échanger du trafic dessus de manière totalement transparente et avec un fail over au top : si un FAI tombe, tous les réseaux devront converger via l'autre FAI.
Je suis actuellement en VPN avec annonces de réseaux dynamiques (BGP) avec 3 peers, mais je ne détaille la conf qu'avec un seul d'entre eux, il suffit alors de répliquer. Chaque peer déclare son AS (dans un private range évidemment) et on monte BGP la dessus.

Pour le VPN, le plus simple est que je sois le serveur, et j'annonce mes 2 IPs (FAI1 et FAI2 donc) à mes peers qui se connectent sur les 2. Ca simplifie de mon coté.
Une de mes IP est fixe, l'autre l'est presque, donc c'est jouable, mais sans IPSec.
On part donc pour du OVPN avec certificats :

> /interface ovpn-server server print
                     enabled: yes
                        port: 1194
                        mode: ip
                     netmask: 32
                 mac-address: FE:44:DD:49:57:1B
                     max-mtu: 1500
           keepalive-timeout: 60
             default-profile: my_profile
                 certificate: server
  require-client-certificate: yes
                        auth: sha1
                      cipher: aes128,aes256

Je vous passe la génération de certificats etc...

> /ppp secret print detail
Flags: X - disabled
(...)
 7   name="XXXXXX" service=ovpn caller-id="" password="XXXXXX" profile=VPN-interco local-address=172.16.1.1 remote-address=172.16.1.6 routes="" limit-bytes-in=0 limit-bytes-out=0 last-logged-out=jan/12/2018 15:58:27

 8   name="XXXXXXX" service=ovpn caller-id="" password="XXXXXX" profile=VPN-interco local-address=172.16.10.1 remote-address=172.16.10.2 routes="" limit-bytes-in=0 limit-bytes-out=0 last-logged-out=jan/17/2018 03:19:06
(...)
 

Les 2 IPs d'interco sont donc 172.16.1.1-172.16.1.6  et 172.16.10.1-172.16.10.2

Attention là encore au routage, il y a la même astuce que pour le forward, mais à répliquer en input cette fois.
Si une connexion VPN (en input donc) entre par FAI1 , elle doit ressortir par FAI1 , et inversement.
Les règles :

> /ip firewall mangle print
Flags: X - disabled, I - invalid, D - dynamic
(...)
6    ;;; I/O
      chain=input action=mark-connection new-connection-mark=From_Wan_Free passthrough=no connection-mark=no-mark in-interface=combo1-wan-free log=no log-prefix=""

 7    chain=input action=mark-connection new-connection-mark=From_Wan_SFR passthrough=no connection-mark=no-mark in-interface=ether1-wan-sfr log=no log-prefix=""

 8    chain=output action=mark-routing new-routing-mark=to_Wan_Free passthrough=no connection-mark=From_Wan_Free log=no log-prefix=""

 9    chain=output action=mark-routing new-routing-mark=to_Wan_SFR passthrough=no connection-mark=From_Wan_SFR log=no log-prefix=""
(...)

Aussi, il faut s'assurer que le VPN puisse passer niveau firewall.

BGP

Il ne reste plus qu'à monter les 2 sessions BGP sur les 2 IPs d'interco VPN, et le tour est joué.
Je prends l'AS 64514 et mon peer 64513 :

Je déclare mon instance :

> /routing bgp instance print
Flags: * - default, X - disabled
 0 *  name="default" as=64514 router-id=0.0.0.0 redistribute-connected=no redistribute-static=no redistribute-rip=no redistribute-ospf=no redistribute-other-bgp=no out-filter=out client-to-client-reflection=yes ignore-as-path-len=no routing-table=""

Je filtre mes annonces en sortie, pour ne pas lui annoncer tous mes réseaux.
Je ne lui annonce que mon LAN, inutile de leaker mon petit monde :

> /routing filter print detail
Flags: X - disabled
(...)
 4   chain=out prefix=192.168.0.0/24 prefix-length=24 bgp-communities="" invert-match=no action=accept set-route-comment="julien-lan" set-bgp-prepend-path=""
(...)
 9   chain=out invert-match=no action=discard set-bgp-prepend-path=""

Je déclare ensuite mon peer (qui fait de même) et BGP oblige, je mets un filtre en entrée pour le réseau qu'il m'annonce : 192.168.42.0/23

> /routing filter print detail
Flags: X - disabled
(...)
 2   chain=remi-in prefix=192.168.42.0/23 prefix-length=23-32 invert-match=no action=accept set-bgp-prepend-path=""

 3   chain=remi-in invert-match=no action=discard set-bgp-prepend-path=""
(...)

>  /routing bgp peer print  detail
Flags: X - disabled, E - established
 0 E name="remi-by-sfr" instance=default remote-address=172.16.1.6 remote-as=64513 tcp-md5-key="" nexthop-choice=default multihop=no route-reflect=no hold-time=3m ttl=default in-filter=remi-in-sfr out-filter="" address-families=ip
     default-originate=never remove-private-as=no as-override=no passive=no use-bfd=no
(...)
 3 E name="remi-by-free" instance=default remote-address=172.16.10.2 remote-as=64513 tcp-md5-key="" nexthop-choice=default multihop=no route-reflect=no hold-time=3m ttl=default in-filter=remi-in out-filter="" address-families=ip
     default-originate=never remove-private-as=no as-override=no passive=no use-bfd=no


Et voilà ! session up.

Nos 2 réseaux sont interconnectés sur 2 VPNs différents qui fail over (chez moi uniquement ;-)).
A ce sujet, du coup, j'ai réduit la distance de l'annonce pour favoriser FAI1. Pour ce faire, j'ai utilisé la règle BGP suivante :

> /routing filter print detail
Flags: X - disabled
 1   chain=remi-in-sfr invert-match=no action=jump jump-target=remi-in set-distance=19 set-bgp-prepend-path=""

Ainsi, lorsque les 2 routes sont UP, le trafic passe par FAI1, si FAI1 tombe, FAI2 prend le relai (mais c'est plus souvent FAI2 qui tombe :D)

Voyons la table de routage BGP de mon coté :
> /ip route print where bgp
Flags: X - disabled, A - active, D - dynamic,
C - connect, S - static, r - rip, b - bgp, o - ospf, m - mme,
B - blackhole, U - unreachable, P - prohibit
 #      DST-ADDRESS        PREF-SRC        GATEWAY            DISTANCE
 1 ADb  192.168.42.0/24                    172.16.1.6               19
 2 ADb  192.168.43.0/24                    172.16.1.6               19
 1 ADb  192.168.42.0/24                    172.16.10.2             20
 2 ADb  192.168.43.0/24                    172.16.10.2             20

Au top !

Voila, chacun gère ses règles FW après, mais évidemment on échange pas du trafic avec un peer en qui on n'a pas confiance : j'ai accès à tout le réseau annoncé, et lui aussi. Nos tables de routages permettent aussi d'accéder à d'autres réseaux , non annoncés.

Conclusions / applications

De là , ben les applications concrètes sont la sauvegarde par exemple : nos NAS sont synchronisés en partie, et tout reste privé entre nous, porté par l'interco VPN chiffrée.
Chacun peut consulter la conf du routeur de l'autre (pratique d'avoir accès à la partie d'en face des fois), et se connecter aux machines. Des zones DNS sont répliquées pour qu'on adresse nos machines par noms , et voila ; les possibilités sont infinies.
Lorsqu'on se rencontre et qu'on va chez l'autre, on retrouve notre stack intacte , mais distante.

A répliquer pour monter sa petite infra ^^


Prochainement donc, Orange fibre qui arrive. J'ai la date : Q1 2018. Donc ben un retour d'XP futur mais je vous rassure : je ne vais pas garder les 3 FAIs actifs , je vous laisse deviner celui qui va sauter ,-)


Une stack multi FAI (aussi appelée "multi-home") offre beaucoup d'avantages, pour un prix vraiment maitrisé (même l'EDF hein : c'est pas la prod de Amazon qui tourne chez moi !).
A l'heure où j'écris, on a du red-by-sfr à 10/15€ mois pour 100M, du Free en vente privée à 2€/mois (même avec une qualité moindre, ça reste une patte dans le réseau) , pis plein d'autres offres à coté que je ne vais nullement détailler ici.
Avoir au moins un fail over, c'est déja cool , c'est-à-dire être garanti d'être connecté H24 (même si un des FAI tombe en fait).

Le troll (poilu)

Plutot que de payer pour un service cloud public quelconque, qui va avaler vos données et vos logs de connexions et faire on ne sait-quoi avec, il vaut mieux à mon gout investir dans du matériel réseau et des connexions FAIs (je parle pas d'un LIR hein :D), et faire ses petites sauces en interne sur VPN chiffré, avec ses potes. Monter son infra privée en gros.
J'ai horreur de toutes ces solutions "cloud" qui te permettent de balancer tes données tu ne sais même pas où, ni rien en fait. Ou encore ces solutions VPN dont vous ne connaissez pas le endpoint :-D (qui peut donc déchiffrer tout le trafic à sa guise).
Vous donnez la clé de votre maison à un gars dans la rue vous ? Même s'il vous dit qu'il ne rentrera pas chez vous ?  ;-)
[End Of Troll]
« Modifié: 17 janvier 2018 à 21:10:29 par doctorrock »