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 InternetDé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 VPNLa 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.
BGPIl 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
)
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 / applicationsDe 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
), 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]