Construire un backbone routeur/VPN flexible avec VyOS, de zéro à l'édition VPS

Pourquoi VyOS

VyOS est un système d'exploitation réseau open source basé sur Debian qui fournit des fonctions de routage, de pare-feu et de VPN de niveau entreprise sur du matériel standard. Il vous offre une flexibilité que les appliances matérielles traditionnelles limitent souvent, et permet de traiter votre routeur comme n'importe quel autre composant versionné et reproductible de votre infrastructure.

Ce que nous allons construire

Un système de routage complet qui comprend :

Une instance VyOS à domicile, même derrière un NAT ou un CGNAT.
Une instance VyOS sur un VPS avec une IP publique réelle.
Un tunnel entre les deux via WireGuard.
Plusieurs sous-réseaux internes derrière le routeur domestique.
Le routage du VPS vers tous les sous-réseaux internes.
La possibilité d'évoluer plus tard vers du routage dynamique.

Le résultat est un chemin stable et prévisible entre votre environnement cloud et votre labo à domicile, sans dépendre d'un port forwarding peu fiable ni exposer de surfaces inutiles.

Adressage et conception

Une conception pratique ressemble à ceci :

Réseaux internes à domicile sous 10.42.0.0/16
Sous-réseaux individuels comme 10.42.0.0/24 et 10.42.1.0/24
Un tunnel WireGuard point à point tel que 172.24.32.0/31
Une IP publique sur le VPS plus la passerelle assignée par le fournisseur
Route par défaut sur le routeur domestique via le WAN local
Route par défaut sur le VPS via la passerelle du datacenter

La topologie est volontairement simple. Le tunnel devient le backbone, et le VPS fait office de point de contrôle accessible depuis l'extérieur.

Configuration du routeur domestique (VyOS derrière NAT)

set interfaces ethernet eth0 address '10.21.21.10/24'
set interfaces ethernet eth0 description 'WAN'

set interfaces ethernet eth1 address '10.42.0.1/24'
set interfaces ethernet eth1 description 'LAB1'

set interfaces ethernet eth2 address '10.42.1.1/24'
set interfaces ethernet eth2 description 'LAB2'

set nat source rule 10 description 'Outgoing NAT'
set nat source rule 10 outbound-interface 'eth0'
set nat source rule 10 source address '10.42.0.0/16'
set nat source rule 10 translation address 'masquerade'

set interfaces wireguard wg0 address '172.24.32.1/31'
set interfaces wireguard wg0 description 'home-to-vps'
set interfaces wireguard wg0 peer VPS allowed-ips '172.24.32.0/31,10.42.0.0/16'
set interfaces wireguard wg0 peer VPS persistent-keepalive '15'
set interfaces wireguard wg0 peer VPS port '8765'
set interfaces wireguard wg0 peer VPS pubkey '<VPS_PUBLIC_KEY>'
set interfaces wireguard wg0 private-key '<HOME_PRIVATE_KEY>'

set protocols static route 0.0.0.0/0 next-hop '10.21.21.1'

set system host-name 'vyos-home-edge'
set service ssh port '22'

commit
save

Configuration du routeur VPS (VyOS avec IP publique)

set interfaces ethernet eth0 address '<VPS_PUBLIC_IP>/23'

set interfaces wireguard wg0 address '172.24.32.0/31'
set interfaces wireguard wg0 description 'vps-to-home'
set interfaces wireguard wg0 peer Home allowed-ips '172.24.32.0/31,10.42.0.0/16'
set interfaces wireguard wg0 peer Home pubkey '<HOME_PUBLIC_KEY>'
set interfaces wireguard wg0 port '8765'

set protocols static route 0.0.0.0/0 next-hop '<VPS_PROVIDER_GATEWAY>'

set system host-name 'vyos-vps'
set service ssh port '22'

commit
save

Une fois les deux extrémités configurées et le handshake WireGuard réussi, vous disposez d'un backbone privé fonctionnel entre votre labo à domicile et le cloud.

Générer des clés WireGuard avec les commandes PKI intégrées

Vous pouvez créer des paires de clés directement avec la commande generate pki wireguard key-pair. Cette méthode renvoie la clé privée et la clé publique en une seule étape et évite le pipage manuel ou les fichiers intermédiaires inutiles qu'exigerait quelque chose comme wg genkey

La commande s'exécute depuis le mode opérationnel.

generate pki wireguard key-pair

Une sortie typique ressemble à ceci :

Private key: 0NLc86fck3qtkBA133fh6K8sGckgQzHR2rBypr+LgHk=
Public key:  H6iVTlr44l6Z+DaGKD3aYr7QZXjG1rpdUYhbm2NjnQQ=

Vous collez la clé privée directement dans la configuration de l'interface.

set interfaces wireguard wg0 private-key '0NLc86fck3qtkBA133fh6K8sGckgQzHR2rBypr+LgHk='

La clé publique est partagée avec le routeur pair, et il est sûr de la transmettre puisqu'elle ne révèle aucune information sensible.

Configuration du serveur DHCP pour les sous-réseaux internes

Par rapport aux anciennes versions de VyOS, la 1.5 apporte un modèle de service DHCP largement revu, abandonnant l'ancienne implémentation ISC DHCP au profit d'un backend basé sur Kea. La structure de configuration est plus claire et permet des options par sous-réseau sans répétition excessive. Si votre routeur domestique dessert plusieurs réseaux internes, chaque VLAN ou interface physique peut exécuter son propre pool DHCP avec des plages de bail, des paramètres DNS et des attributions de passerelle indépendants.

L'exemple ci-dessous crée des pools DHCP pour deux réseaux internes, 10.42.0.0/24 et 10.42.1.0/24, correspondant à la topologie précédente. Chaque pool définit la passerelle par défaut, les serveurs DNS et une plage d'adresses dynamique. VyOS lie automatiquement un pool DHCP à l'interface qui contient le réseau correspondant.

# Enable the DHCP service
set service dhcp-server shared-network-name LAB1 subnet 10.42.0.0/24 default-router '10.42.0.1'
set service dhcp-server shared-network-name LAB1 subnet 10.42.0.0/24 dns-server '10.42.0.1'
set service dhcp-server shared-network-name LAB1 subnet 10.42.0.0/24 lease '86400'
set service dhcp-server shared-network-name LAB1 subnet 10.42.0.0/24 range 1 start '10.42.0.100'
set service dhcp-server shared-network-name LAB1 subnet 10.42.0.0/24 range 1 stop '10.42.0.200'

set service dhcp-server shared-network-name LAB2 subnet 10.42.1.0/24 default-router '10.42.1.1'
set service dhcp-server shared-network-name LAB2 subnet 10.42.1.0/24 dns-server '10.42.1.1'
set service dhcp-server shared-network-name LAB2 subnet 10.42.1.0/24 lease '86400'
set service dhcp-server shared-network-name LAB2 subnet 10.42.1.0/24 range 1 start '10.42.1.100'
set service dhcp-server shared-network-name LAB2 subnet 10.42.1.0/24 range 1 stop '10.42.1.200'

commit
save

Si vous avez besoin d'options DHCP supplémentaires telles que des serveurs NTP, des paramètres de démarrage PXE ou des listes de recherche de domaine, VyOS 1.5 les autorise au niveau du sous-réseau. Par exemple :

set service dhcp-server shared-network-name LAB1 subnet 10.42.0.0/24 ntp-server '10.42.0.1'
set service dhcp-server shared-network-name LAB1 subnet 10.42.0.0/24 domain-name 'lab.internal'

Des réservations statiques peuvent également être configurées afin que des adresses MAC spécifiques reçoivent des attributions IP déterministes. C'est utile pour les serveurs, les hyperviseurs ou les appareils embarqués qui exigent un adressage cohérent.

set service dhcp-server shared-network-name LAB1 subnet 10.42.0.0/24 static-mapping web01 ip-address '10.42.0.10'
set service dhcp-server shared-network-name LAB1 subnet 10.42.0.0/24 static-mapping web01 mac-address 'aa:bb:cc:dd:ee:ff'

VyOS reconfigure automatiquement Kea à chaque commit, et les baux sont suivis dans les fichiers d'état habituels sous /run/kea. Pour les réseaux plus grands, vous pouvez intégrer Kea à un backend de base de données, mais pour la plupart des environnements domestiques ou de labo, la configuration intégrée suffit et reste fiable.

Routage dynamique entre le domicile et le VPS

Les routes statiques fonctionnent bien pour des réseaux petits ou fixes, mais deviennent une charge de maintenance à mesure que votre environnement grandit. Si vous prévoyez d'ajouter des sous-réseaux supplémentaires, davantage de points de terminaison de tunnel, ou une connectivité multisite, le routage dynamique permet aux routeurs de partager automatiquement les informations d'accessibilité. VyOS 1.5 prend en charge plusieurs protocoles de routage dynamique avec FRR comme backend. Dans cette topologie, les deux choix les plus pertinents sont BGP et OSPF.

Le routage dynamique ne remplace ni votre tunnel WireGuard ni l'adressage point à point. Il automatise simplement ce que vous définissiez auparavant manuellement. Le tunnel continue de transporter le trafic, mais les préfixes sont désormais appris plutôt que configurés statiquement.

Utiliser BGP pour l'échange de préfixes

BGP convient bien aux situations où vous contrôlez plusieurs domaines de routage ou où les réseaux sont répartis sur des sites géographiquement distincts. Un routeur domestique annonçant des sous-réseaux de labo à un routeur VPS s'inscrit parfaitement dans ce modèle. BGP est également agnostique quant au transport sous-jacent, donc l'exécuter sur WireGuard est simple.

L'exemple ci-dessous utilise des numéros de système autonome privés. Chaque routeur utilise un loopback comme identifiant de routeur BGP. Le routeur domestique origine les sous-réseaux internes sous 10.42.0.0/16, et le VPS les apprend automatiquement.

Configuration du routeur domestique

set interfaces loopback lo address '10.255.255.1/32'

set protocols bgp 65010 neighbor 172.24.32.0 remote-as '65020'
set protocols bgp 65010 neighbor 172.24.32.0 update-source 'wg0'

set protocols bgp 65010 network '10.42.0.0/24'
set protocols bgp 65010 network '10.42.1.0/24'

set protocols bgp 65010 parameters router-id '10.255.255.1'

commit
save

Configuration du routeur VPS

set interfaces loopback lo address '10.255.255.2/32'

set protocols bgp 65020 neighbor 172.24.32.1 remote-as '65010'
set protocols bgp 65020 neighbor 172.24.32.1 update-source 'wg0'

set protocols bgp 65020 parameters router-id '10.255.255.2'

commit
save

Après le commit, chaque routeur installe les préfixes appris dans sa table de routage. Tout nouveau sous-réseau ajouté côté domicile peut être annoncé simplement en ajoutant une autre instruction network dans BGP, sans toucher à la configuration du VPS.

Filtrage des routes et évolutions futures

Même dans des domaines de routage privés, il est recommandé de contrôler quels préfixes sont échangés. VyOS prend en charge les route maps, les prefix lists et les communities pour filtrer ou étiqueter les routes. Pour une topologie à deux sites, le filtrage est facultatif, mais dès que des routeurs supplémentaires ou des sauts intermédiaires s'ajoutent, ces outils apportent stabilité et contrôle.

Les prefix lists peuvent par exemple servir à empêcher l'annonce accidentelle de plages internes que vous ne voulez pas exposer via le tunnel.

Utiliser OSPF pour des environnements multi-sous-réseaux plus simples

Si les deux routeurs participent à un seul domaine de routage partagé et que vous souhaitez une découverte automatique des voisins, OSPF est une alternative plus simple. OSPF exige que les interfaces soient joignables au niveau de la couche 3, ce que satisfait le réseau de liaison WireGuard. OSPF convient bien aux environnements de labo où la simplicité prime sur une politique de routage stricte.

Configuration OSPF du routeur domestique

set protocols ospf parameters router-id '10.255.255.1'

set protocols ospf area 0 network '172.24.32.0/31'
set protocols ospf area 0 network '10.42.0.0/24'
set protocols ospf area 0 network '10.42.1.0/24'

commit
save

Configuration OSPF du routeur VPS

set protocols ospf parameters router-id '10.255.255.2'

set protocols ospf area 0 network '172.24.32.0/31'

commit
save

OSPF découvre les voisins via la liaison WireGuard et échange des LSA décrivant chaque sous-réseau interne. Tout nouveau réseau ajouté au routeur domestique s'intègre simplement en l'ajoutant à la configuration de la zone OSPF.

Choisir entre BGP et OSPF

Les deux protocoles permettent le routage dynamique, mais répondent à des besoins opérationnels légèrement différents.

BGP offre un contrôle précis sur ce que vous annoncez et acceptez, ce qui devient important dès que le réseau dépasse deux sites.
OSPF fournit un routage à état de liens simple au sein d'un domaine partagé et demande souvent moins de configuration initiale.
BGP est préférable lorsque votre VPS sert de point d'agrégation central pour plusieurs sites distants.
OSPF est idéal quand vous voulez une découverte automatique avec un minimum de gestion de politique.

Ces options restent compatibles avec la topologie WireGuard sous-jacente, et les deux approches suppriment le besoin de routes statiques par sous-réseau sur le VPS. Si vous le souhaitez, je peux ajouter des exemples de route maps, de prefix lists, ou d'exécution simultanée des deux protocoles dans des VRF segmentés.

Routage statique, l'approche simple

Si vous préférez la prévisibilité et n'anticipez pas de nombreux changements de sous-réseaux internes, les routes statiques sont la méthode la plus simple.

set protocols static route 10.42.0.0/24 next-hop 172.24.32.1
set protocols static route 10.42.1.0/24 next-hop 172.24.32.1
commit
save

Cela garantit que le VPS sait où envoyer le trafic pour chaque réseau interne.

Routage dynamique pour les topologies plus grandes

Si vous prévoyez d'ajouter plusieurs routeurs ou de faire évoluer l'architecture, le routage dynamique comme BGP devient utile. VyOS peut annoncer les sous-réseaux depuis votre routeur domestique jusqu'au VPS, supprimant le besoin d'ajouts de routes manuels. Ce n'est pas nécessaire pour l'installation simple, mais cela devient précieux à mesure que votre topologie grandit.

Pourquoi cette architecture fonctionne bien

Ce modèle offre plusieurs avantages :

Il contourne le CGNAT et le port forwarding peu fiable grâce à un tunnel stable.
Tout le trafic sortant peut optionnellement passer par le VPS, centralisant le filtrage ou la surveillance.
Il prend en charge proprement plusieurs sous-réseaux domestiques isolés.
VyOS vous donne un contrôle total sans vous enfermer dans du matériel propriétaire.
Vous pouvez évoluer vers le routage dynamique, VRRP, des points de terminaison VPN supplémentaires ou une connectivité multisite sans redessiner les fondations.

Points de vigilance à garder en tête

Les routes statiques doivent être mises à jour manuellement à chaque nouveau sous-réseau.
Dans ce modèle, WireGuard fonctionne mieux lorsque les connexions sont initiées depuis le côté domicile, car le VPS dispose d'un point de terminaison public fixe.
La sécurité est volontairement minimale dans ce guide. En production, vous devriez ajouter des politiques de pare-feu, restreindre l'accès à l'administration, et auditer les services.
Les réseaux privés ne traversent jamais l'Internet public, donc le tunnel doit toujours être actif pour que le routage fonctionne.

Étapes suivantes possibles

Vous pouvez prolonger ce tutoriel vers une colonne vertébrale d'infrastructure plus complète. Certaines extensions naturelles incluent :

Introduire BGP pour l'annonce automatique des sous-réseaux.
Ajouter des groupes de pare-feu, du routage basé sur des politiques, et de la segmentation.
Prendre en charge les clients WireGuard « road warrior », ce qu'un plan de contrôle VPN maillé facilite grandement.
Utiliser cloud init pour déployer les images VyOS de façon programmatique.
Ajouter de la redondance avec VRRP.

Conclusion

En combinant VyOS sur un routeur domestique avec VyOS sur un VPS public et en les reliant par un tunnel, vous obtenez un backbone flexible qui fonctionne indépendamment du NAT, des restrictions du FAI ou de la complexité du labo. Ce modèle passe à l'échelle, s'automatise facilement, et vous donne un contrôle total sur la façon dont vos réseaux internes et externes communiquent.