MikroTik VPN : jeu de règles propre et auditable pour les split tunnels

Principes : comment les split tunnels échouent en pratique

Le split tunneling n’est pas « une partie du trafic passe par le VPN, le reste sort en direct ». C’est la version brochure. La réalité : vous construisez deux domaines de routage qui se chevauchent sur le même client, puis vous espérez que le DNS, le MTU, le NAT et l’état du pare-feu s’accordent tous sur la définition de « interne ».

Sur MikroTik, votre succès dépend de votre capacité à répondre rapidement à ces questions, avec des preuves :

• Quels paquets doivent entrer dans le tunnel ?
• Où décidez-vous cela (table de routage, mangle, politique IPsec, AllowedIPs WireGuard) ?
• Les paquets de retour empruntent-ils le même chemin (symétrie) et conntrack est-il d’accord ?
• Natez-vous uniquement ce qui doit l’être, et rien de plus ?
• Pouvez-vous prouver tout cela à partir des diffs de configuration et des compteurs ?

Ce que « propre » signifie dans RouterOS

Propre ne signifie pas « peu de règles ». Propre signifie prévisible et auditable. Je veux un jeu de règles où :

• Chaque règle a un commentaire, et le commentaire explique l’intention (pas « vpn rule 3 »).
• Les marques et tables utilisent des noms cohérents : rt-vpn, rm-vpn, addr-vpn-dsts.
• Toutes les décisions de split-tunnel se prennent en un seul endroit évident.
• Le NAT est explicite et ciblé. Si vous devez masquer des adresses, vous le faites pour un ensemble défini de flux.
• Le refus par défaut reste refus par défaut.

Les deux façons dont le split tunneling devient « accidentellement full tunnel »

La dérive des routes est la principale : quelqu’un ajoute une route trop large (comme 0.0.0.0/0) dans la mauvaise table ou pousse des AllowedIPs trop larges, et désormais tout le trafic reboucle via le siège. Les utilisateurs se plaignent de latence ; la direction dit « le VPN est lent » ; vous appelez ça « un bug de politique de routage avec un problème de processus de changement ».

La dérive DNS est l’autre : vous séparez le routage du trafic mais ne séparez pas correctement la résolution de noms. Le client résout des noms internes via un DNS public (échec), ou résout des noms publics via le DNS interne (fonctionne mais fuit la politique interne vers l’internet). Les deux mènent à « ça marche sur mon portable » parce que votre portable a des réponses en cache de la semaine dernière.

Une vérité fiable : le split tunneling est plus facile à maintenir correct quand le tunnel est étroit. Routez seulement les préfixes privés dont vous avez réellement besoin. Si un fournisseur dit « envoyez juste 0/0 », ce n’est pas une exigence technique ; c’est une stratégie de support.

Blague #1 : Le split tunneling, c’est comme laisser votre chat choisir quelles portes sont ouvertes. Il choisira celle qui vous fera le regretter.

Faits et contexte intéressants (pour ne pas répéter l’histoire)

1. Le policy routing précède la marque « SD-WAN » de plusieurs décennies. Les routeurs d’entreprise utilisaient des route maps et des tables multiples bien avant que cela ne devienne un produit par abonnement.
2. Le split tunneling VPN était largement déconseillé au début des années 2000 car des clients compromis pouvaient faire le pont entre les réseaux d’entreprise et l’internet ; les contrôles modernes des endpoints l’ont rendu moins tabou.
3. Le modèle « basé sur les politiques » d’IPsec a façonné les habitudes de nombreux admins : « les sélecteurs de trafic décident de ce qui est chiffré ». WireGuard a renversé le modèle mental avec AllowedIPs agissant à la fois comme route et ACL.
4. Le NAT et IPsec se sont longtemps détestés ; NAT-T (encapsulation UDP) est devenu courant pour survivre au NAT généralisé sur Internet.
5. Le connection tracking est devenu le gouverneur silencieux du comportement du pare-feu à mesure que le filtrage stateful a remplacé les ACL stateless sur les équipements SMB. Quand conntrack ment, tout ment.
6. Le split-horizon DNS est plus ancien que la plupart des plateformes cloud. Ce n’est pas une astuce nouvelle ; nous oublions juste de le concevoir.
7. Les problèmes de MTU sont aussi vieux que le tunneling : l’encapsulation vole des octets au payload, et « ça marche en ping » ne prouve rien pour le trafic réel.
8. MikroTik a popularisé des « fonctionnalités de qualité opérateur à prix hobbyiste », ce qui signifie que votre environnement « petit » peut quand même avoir une complexité de niveau opérateur—sans un contrôle de changement de niveau opérateur.

Conclusion : votre design de split tunnel doit supposer que des gens le modifieront plus tard sous pression. Optimisez pour la résilience, pas pour l’ingéniosité.

Une architecture de référence propre (modèle mental RouterOS)

Nous nous ancrons sur un scénario simple mais réaliste en production :

• Routeur MikroTik dans une succursale ou un bureau à domicile.
• LAN : 192.168.88.0/24 sur bridge.
• WAN : ether1 avec accès Internet.
• VPN : interface WireGuard wg0 vers un hub (siège ou cloud).
• Réseaux protégés distants : 10.10.0.0/16 et 10.20.30.0/24.
• Objectif split tunnel : seuls ces réseaux distants passent par le VPN ; tout le reste sort localement.

Points de décision : où le trafic est orienté

Sur RouterOS, vous avez plusieurs « leviers ». N’en actionnez pas plusieurs en même temps, sauf si vous aimez les post-mortems.

• Sélection de la table de routage (policy routing RouterOS v7 avec routing rules et tables multiples).
• Marques mangle (routing-mark) alimentant une recherche de route alternative.
• AllowedIPs WireGuard (contrôle ce que le pair acceptera et quelles routes vous pouvez installer).
• Politiques IPsec (les sélecteurs déterminent ce qui est chiffré).
• Règles NAT (peuvent « corriger » des erreurs ; ne comptez pas dessus).

Ma préférence pour un split tunneling auditable sur MikroTik RouterOS v7 :

• Utiliser une table de routage dédiée (par ex. rt-vpn).
• Utiliser une seule règle mangle (ou règle de routage) pour sélectionner cette table pour un ensemble clairement défini de destinations.
• Aligner les AllowedIPs WireGuard sur ces destinations, mais ne pas l’utiliser comme unique contrôle de politique.
• Garder le NAT minimal ; privilégier le routage des préfixes privés de bout en bout quand c’est possible.

Ce que vous devez journaliser et compter

L’audit n’est pas une case à cocher de conformité ; c’est une fonctionnalité de vitesse. Vous voulez des compteurs et des logs qui répondent :

• Matchons-nous la liste « destinations VPN » ?
• Rejetons-nous les entrées inattendues depuis le tunnel ?
• Le NAT s’active-t-il quand il ne devrait pas ?
• La route par défaut est-elle utilisée pour le trafic Internet comme prévu ?

Cela signifie : listes d’adresses, commentaires de règles et journaux temporaires occasionnels que vous supprimez après validation. Le « journaliser tout en permanence » est la façon la plus sûre de vous créer un propre déni de service.

Le jeu de règles propre et auditable (WireGuard + policy routing)

Ceci est un modèle de référence. Adaptez les noms d’interface et les sous-réseaux. L’objectif est la structure : séparer les responsabilités, étiqueter l’intention et centraliser la décision de split.

1) Définir des listes d’adresses : votre contrat de split tunnel

Commencez par une liste d’adresses qui énumère ce qui doit passer par le VPN. Cela devient votre contrat avec le métier : « ces réseaux sont internes ». Tout le reste est externe.

Utilisez un petit nombre de listes :

• addr-vpn-dsts : préfixes de destination qui doivent transiter par le VPN.
• addr-lan : préfixes LAN locaux (optionnel, mais utile).
• addr-mgmt : sources de gestion autorisées à atteindre les services du routeur.

2) Créer une table de routage dédiée et des routes

RouterOS v7 a introduit des tables de routage de première classe. Servez-vous-en. Cela rend la config lisible et réduit les « marques magiques » qui traînent.

Dans rt-vpn, ajoutez des routes pour les réseaux protégés avec la passerelle définie sur l’interface WireGuard (ou l’endpoint du pair si vous faites quelque chose de plus avancé). N’ajoutez pas de route par défaut à moins de vouloir un full tunnel.

3) Policy routing : n’orientez que ce qui doit l’être

Vous pouvez le faire avec un mark-routing mangle ou avec /routing rule. Les deux sont valables. J’aime /routing rule pour la lisibilité quand c’est possible, mais le mangle reste l’outil universel quand vous devez matcher plus d’attributs.

Choix de conception clé : matcher par liste de destinations. Cela rend difficile l’extension accidentelle de la portée via un match basé sur un port plus tard.

4) NAT : seulement si nécessaire, et seulement pour les flux pertinents

Si l’autre côté peut router de retour vers votre LAN, ne faites pas de NAT. Le routage est plus propre, débogable et conserve la pertinence des logs côté distant.

Si vous devez NAT car l’autre côté ne peut pas ajouter de routes ou qu’il y a des sous-réseaux qui se chevauchent, alors NAT uniquement LAN→VPN-dsts. Ne masquez pas tout le trafic sortant par wg0 à moins de vouloir que le côté distant voie chaque utilisateur comme « le routeur ».

5) Pare-feu : liste blanche explicite pour le tunnel

Pour la chaîne input, traitez le routeur comme un serveur : n’autorisez que les services dont vous avez besoin depuis les sources de confiance. Pour la chaîne forward, autorisez established/related, drop invalid, puis autorisez LAN vers destinations VPN, LAN vers Internet, et autorisez VPN vers LAN seulement si c’est nécessaire (souvent ce n’est pas le cas).

Séparez les règles pour le « trafic tunnel » et le « trafic Internet ». En débogage, vous remercierez votre vous du passé.

6) DNS : le split tunnel est à moitié routage, à moitié résolution

Décidez où se résolvent les noms internes. Options :

• Les clients utilisent des serveurs DNS internes accessibles via le VPN pour des zones spécifiques (meilleur choix).
• Le routeur fait du transfert conditionnel (fonctionne, mais ajoute une partie mobile).
• Les clients utilisent un DNS public et vous acceptez que les noms internes ne se résolvent pas (généralement inacceptable).

Quoi que vous choisissiez, documentez-le comme partie du contrat de split tunnel. Sinon votre « incident réseau » est en fait un « décalage d’attentes DNS ».

Squelette de configuration concret (conceptuel, non collé)

Je ne vais pas coller mille lignes d’export car les environnements de production ne sont pas des démos copiables. Le but est le modèle :

• La liste d’adresses définit les destinations protégées.
• La table de routage contient uniquement ces routes.
• La règle de routage ou le marquage mangle sélectionne cette table uniquement pour ces destinations.
• Le NAT est limité à LAN→destinations protégées si nécessaire.
• Le pare-feu est explicite sur les flux autorisés et journalise seulement l’inattendu.

Blague #2 : Le NAT, c’est comme du ruban adhésif—génial quand il faut, inquiétant quand ça devient l’architecture.

Notes pour le split tunneling IPsec/IKEv2

WireGuard est assez simple pour que la plupart des bugs de split tunnel soient auto-infligés. IPsec ajoute plus de pièces mobiles : durées de phase 1/2, sélecteurs, propositions, NAT-T et le classique « il est up mais rien ne passe ».

IPsec basé sur politique vs IPsec basé sur route sur MikroTik

En IPsec basé sur politique, les sélecteurs de politique (src/dst subnets) décident ce qui est chiffré. Si votre split tunnel requiert seulement quelques destinations, cela peut être propre—jusqu’à ce que quelqu’un ajoute une politique plus large « temporairement » et oublie de l’enlever.

L’IPsec basé sur route (via VTI) tend à mieux s’aligner avec le design « table de routage dédiée » parce que vous pouvez router des préfixes dans l’interface VTI comme n’importe quelle autre interface, puis appliquer le policy routing de la même manière.

L’astuce d’audit avec IPsec

Faites en sorte que les sélecteurs correspondent à votre contrat de liste d’adresses. Si votre liste dit 10.10.0.0/16 et 10.20.30.0/24, vos politiques IPsec doivent le refléter. Si ce n’est pas le cas, vous ne faites pas du split tunneling ; vous faites « ce que le dernier ingénieur a touché ».

Tâches pratiques : 12+ commandes, sorties et décisions

Ces tâches supposent que vous avez un accès CLI au MikroTik (via SSH) et une machine Linux sur le LAN pour générer du trafic de test. Les commandes sont réalistes ; les sorties représentatives. Le but : exécuter une commande, l’interpréter, prendre une décision.

Tâche 1 : Confirmer que l’interface WireGuard est active et a l’adresse attendue

cr0x@server:~$ ssh admin@192.168.88.1 /interface/wireguard/print
Flags: X - disabled, R - running 
 0  R name="wg0" mtu=1420 listen-port=13231 private-key="<hidden>" public-key="<hidden>"

Ce que cela signifie : R indique que l’interface est en cours d’exécution. Le MTU est important ; 1420 est une valeur sûre courante pour WireGuard sur des WAN typiques.

Décision : S’il n’est pas en fonctionnement, corrigez cela avant de poursuivre le routage. Si le MTU est 1500 et que les utilisateurs signalent « certains sites fonctionnent, gros téléchargements échouent », suspectez le MTU.

Tâche 2 : Vérifier le handshake du pair et les compteurs de bytes

cr0x@server:~$ ssh admin@192.168.88.1 /interface/wireguard/peers/print detail
 0 interface=wg0 public-key="<hubkey>" endpoint-address=203.0.113.10 endpoint-port=51820 
   allowed-address=10.10.0.0/16,10.20.30.0/24 persistent-keepalive=25s
   last-handshake=1m12s rx=128.4MiB tx=64.2MiB

Ce que cela signifie : Un handshake récent et des rx/tx croissants indiquent que le tunnel est vivant.

Décision : Si le handshake est vide ou ancien, corrigez la reachabilité (WAN, NAT, pare-feu des deux côtés) avant de toucher aux règles de split.

Tâche 3 : Lister les listes d’adresses et confirmer le contrat de split tunnel

cr0x@server:~$ ssh admin@192.168.88.1 /ip/firewall/address-list/print where list="addr-vpn-dsts"
Flags: X - disabled, D - dynamic 
 0   list=addr-vpn-dsts address=10.10.0.0/16 comment="HQ private networks"
 1   list=addr-vpn-dsts address=10.20.30.0/24 comment="Finance app subnet"

Ce que cela signifie : Le routeur a un ensemble explicite de destinations pour le chemin VPN.

Décision : Si cette liste manque, est obsolète ou contient 0.0.0.0/0, stoppez. Vous n’avez pas de split tunneling ; vous avez des impressions.

Tâche 4 : Confirmer que la table de routage dédiée existe

cr0x@server:~$ ssh admin@192.168.88.1 /routing/table/print
Flags: D - dynamic, X - disabled 
 0 name="main" fib
 1 name="rt-vpn" fib

Ce que cela signifie : rt-vpn est une table FIB réelle.

Décision : Si vous ne la voyez pas, créez-la. Si vous voyez cinq tables au nom similaire, vous avez des problèmes de gouvernance, pas un problème technique.

Tâche 5 : Vérifier les routes dans la table VPN

cr0x@server:~$ ssh admin@192.168.88.1 /ip/route/print where routing-table="rt-vpn"
Flags: D - dynamic, X - disabled, A - active, c - connect, s - static 
 0 A s dst-address=10.10.0.0/16 gateway=wg0 distance=1 scope=30 target-scope=10 comment="via WG to HQ"
 1 A s dst-address=10.20.30.0/24 gateway=wg0 distance=1 scope=30 target-scope=10 comment="via WG to finance"

Ce que cela signifie : La table VPN route uniquement les réseaux privés attendus, et ils sont actifs.

Décision : S’il y a une route par défaut dans rt-vpn, vous n’êtes qu’à une règle de routage d’un full tunnel. Supprimez-la sauf si c’est intentionnel.

Tâche 6 : Confirmer que la décision de policy routing existe (routing rule)

cr0x@server:~$ ssh admin@192.168.88.1 /routing/rule/print detail
 0 action=lookup-only-in-table dst-address=10.10.0.0/16 table=rt-vpn comment="Split tunnel: HQ"
 1 action=lookup-only-in-table dst-address=10.20.30.0/24 table=rt-vpn comment="Split tunnel: Finance"

Ce que cela signifie : Seuls ces préfixes de destination consultent rt-vpn. lookup-only-in-table empêche le fallback vers main, ce qui rend les pannes bruyantes (bon) plutôt qu’étranges (mauvais).

Décision : Si les règles utilisent lookup au lieu de lookup-only-in-table, vous risquez de faire sortir du trafic sur le WAN quand le VPN est down. Choisissez délibérément.

Tâche 7 : Inspecter les règles NAT et s’assurer qu’elles sont ciblées

cr0x@server:~$ ssh admin@192.168.88.1 /ip/firewall/nat/print
Flags: X - disabled, I - invalid, D - dynamic 
 0   chain=srcnat action=masquerade out-interface=ether1 comment="WAN internet NAT"
 1   chain=srcnat action=masquerade out-interface=wg0 src-address=192.168.88.0/24 dst-address-list=addr-vpn-dsts comment="NAT only LAN to VPN dsts"

Ce que cela signifie : Il y a un masquerade WAN normal, et un masquerade VPN qui ne se déclenche que pour LAN → destinations protégées.

Décision : Si vous voyez un out-interface=wg0 masquerade global sans restriction de dst, vous cachez probablement des erreurs de conception et brisez les pistes d’audit côté distant.

Tâche 8 : Vérifier les compteurs de la chaîne forward pour les flux VPN

cr0x@server:~$ ssh admin@192.168.88.1 /ip/firewall/filter/print stats where chain="forward"
Flags: X - disabled, I - invalid, D - dynamic 
 0   chain=forward action=accept connection-state=established,related comment="Allow established/related" packets=784221 bytes=812.5MiB
 1   chain=forward action=drop connection-state=invalid comment="Drop invalid" packets=23 bytes=1904
 2   chain=forward action=accept in-interface=bridge dst-address-list=addr-vpn-dsts out-interface=wg0 comment="LAN to VPN destinations" packets=18214 bytes=21.6MiB
 3   chain=forward action=accept in-interface=bridge out-interface=ether1 comment="LAN to internet" packets=512001 bytes=601.2MiB
 4   chain=forward action=drop comment="Drop the rest" packets=411 bytes=32244

Ce que cela signifie : La règle split VPN correspond et laisse passer le trafic. Que « Drop the rest » soit petit est sain.

Décision : Si le compteur de la règle VPN reste à zéro alors que des utilisateurs se plaignent, votre décision de routage ne sélectionne pas le chemin attendu (ou le DNS pointe ailleurs).

Tâche 9 : Utiliser Torch pour voir si le trafic vers un subnet protégé sort par wg0

cr0x@server:~$ ssh admin@192.168.88.1 /tool/torch interface=wg0 src-address=192.168.88.50 dst-address=10.10.20.15
#   SRC-ADDRESS         DST-ADDRESS         PROTOCOL  PORT  TX      RX
0   192.168.88.50       10.10.20.15         tcp       443   1.2Mbps  3.8Mbps

Ce que cela signifie : Vous avez du trafic en direct correspondant à l’attente du split tunnel.

Décision : Si le trafic apparaît sur ether1 à la place, vos règles/marks de routage sont erronées ou la destination n’est pas dans votre liste d’adresses.

Tâche 10 : Exécuter un test de lookup de route pour une destination

cr0x@server:~$ ssh admin@192.168.88.1 /ip/route/check dst-address=10.10.20.15
 0 interface=wg0 gateway=wg0 distance=1 routing-table=rt-vpn

Ce que cela signifie : Le routeur enverrait cette destination via wg0 en utilisant rt-vpn.

Décision : Si ça rapporte routing-table=main ou interface ether1, la politique de split n’est pas appliquée pour cette destination.

Tâche 11 : Confirmer que conntrack ne fixe pas les flux sur le mauvais chemin

cr0x@server:~$ ssh admin@192.168.88.1 /ip/firewall/connection/print where dst-address~"10.10."
Flags: S - seen-reply, A - assured, C - confirmed 
 0 SAC protocol=tcp src-address=192.168.88.50:50122 dst-address=10.10.20.15:443 timeout=23h59m
     reply-src-address=10.10.20.15:443 reply-dst-address=192.168.88.50:50122

Ce que cela signifie : Une connexion active existe. Conntrack est stateful ; une fois un flux établi, changer la politique de routage peut ne pas le déplacer.

Décision : Si vous avez changé le policy routing et que le comportement n’a pas changé, supprimez les connexions spécifiques ou attendez les timeouts. Ne redémarrez pas en premier recours.

Tâche 12 : Valider le MTU avec une taille de payload réelle (depuis un hôte Linux)

cr0x@server:~$ ping -M do -s 1372 10.10.20.15 -c 3
PING 10.10.20.15 (10.10.20.15) 1372(1400) bytes of data.
1380 bytes from 10.10.20.15: icmp_seq=1 ttl=61 time=42.1 ms
1380 bytes from 10.10.20.15: icmp_seq=2 ttl=61 time=41.7 ms
1380 bytes from 10.10.20.15: icmp_seq=3 ttl=61 time=41.9 ms

--- 10.10.20.15 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms

Ce que cela signifie : Le PMTUD supporte au moins ce payload sans fragmentation. Pour les tunnels, testez avec DF set car la fragmentation peut masquer de vrais problèmes.

Décision : Si cela échoue mais que les petits pings fonctionnent, baissez le MTU de WireGuard et/ou investiguez le MTU du chemin WAN et le filtrage ICMP.

Tâche 13 : Vérifier la saturation CPU lors d’une charge VPN (côté routeur)

cr0x@server:~$ ssh admin@192.168.88.1 /system/resource/print
                   uptime: 12d3h2m
                  version: 7.13.5 (stable)
               free-memory: 412.3MiB
              total-memory: 512.0MiB
                       cpu: ARM
                 cpu-count: 4
             cpu-frequency: 1400MHz
                  cpu-load: 86%

Ce que cela signifie : Un CPU à 86% suggère que vous êtes à la limite, surtout si les pics atteignent 100% et que des queues se forment.

Décision : Si le CPU est élevé durant les plaintes, mesurez le débit et envisagez les limites d’accélération matérielle, les interactions FastTrack, ou une mise à niveau matérielle.

Tâche 14 : Vérifier que FastTrack ne contourne pas les décisions mangle/routing

cr0x@server:~$ ssh admin@192.168.88.1 /ip/firewall/filter/print where action~"fasttrack"
Flags: X - disabled, I - invalid, D - dynamic 
 5   chain=forward action=fasttrack-connection connection-state=established,related comment="FastTrack (may bypass policy routing)"

Ce que cela signifie : FastTrack peut court-circuiter des parties du chemin firewall/mangle. Selon votre design, cela peut causer des incohérences de split tunnel.

Décision : Si vous comptez sur des marques mangle pour le routage, vous devrez souvent désactiver FastTrack ou prévoir des exceptions afin que le trafic marqué VPN ne soit pas fasttracké.

Playbook de diagnostic rapide

Vous n’obtenez pas de points supplémentaires pour un débogage approfondi quand l’incident est évident. Voici l’ordre qui trouve le goulot d’étranglement rapidement.

Première étape : prouver si le tunnel est vivant

• Vérifiez le timestamp du handshake WireGuard et les compteurs de bytes.
• Si le handshake manque : c’est la reachabilité sous-jacente, le NAT, ou le pare-feu. Arrêtez-vous là.
• Si le handshake est correct : passez au routage/politique.

Deuxième étape : prouver la sélection de routage pour une destination en échec

• Choisissez une IP interne connue comme « interne ».
• Exécutez route check / lookup et confirmez qu’elle sélectionne wg0 et rt-vpn.
• Si elle sélectionne le WAN : votre contrat de split tunnel (liste d’adresses / règles de routage) est incorrect.

Troisième étape : prouver que le pare-feu le permet (et que le NAT ne fait pas d’astuce)

• Regardez les compteurs de la chaîne forward pour la règle LAN→VPN.
• Vérifiez les compteurs NAT pour la règle de masquerade VPN (si présente).
• Utilisez Torch sur wg0 pour confirmer que le trafic sort réellement.

Quatrième étape : si routage/pare-feu semblent corrects, testez MTU et DNS

• MTU : ping DF avec une taille de payload réaliste ; baissez le MTU si nécessaire.
• DNS : confirmez que le client résout le nom interne en IP interne, pas en front public.

Cinquième étape : n’attaquez la performance qu’après

• Vérifiez la charge CPU du routeur pendant la fenêtre d’incident.
• Cherchez une perte de paquets sur le WAN, ou des symptômes de bufferbloat.
• Confirmez que vous ne vous êtes pas fasttracké hors du policy routing.

Note opérationnelle : si le tunnel est up mais que « certaines applis » échouent, MTU et DNS battent « règles pare-feu mystiques » neuf fois sur dix.

Erreurs courantes : symptôme → cause racine → correction

1) Symptom : Le VPN est actif, mais les subnets internes sont inaccessibles

Cause racine : Des routes existent dans la table main mais le policy routing envoie le trafic vers une table sans ces routes (ou inversement).

Correction : Mettez les routes des subnets protégés dans rt-vpn et assurez-vous que les routing rules sélectionnent rt-vpn pour ces destinations. Validez avec /ip/route/check.

2) Symptom : Tout passe par le VPN (full tunnel accidentel)

Cause racine : Route par défaut (0.0.0.0/0) présente dans la table VPN, ou AllowedIPs WireGuard inclut 0.0.0.0/0 et vous avez installé une route large.

Correction : Retirez la route par défaut de rt-vpn. Resserrez les AllowedIPs aux préfixes protégés. Auditez régulièrement les tables de routage.

3) Symptom : Certaines connexions fonctionnent, d’autres bloquent (surtout gros transferts)

Cause racine : Problèmes MTU/PMTUD ; ICMP bloqué ; surcharge d’encapsulation non prise en compte.

Correction : Réduisez le MTU du tunnel (ex. 1420 ou moins), et testez avec des pings DF. Ne devinez pas ; mesurez.

4) Symptom : Les noms internes ne se résolvent pas, mais les IP internes répondent

Cause racine : DNS non split ; les clients utilisent encore un DNS public pour des zones internes.

Correction : Fournissez un DNS interne accessible via le VPN, ou mettez en place un transfert conditionnel. Documentez les zones et les résolveurs attendus.

5) Symptom : Après un changement, le comportement ne reflète pas les nouvelles règles pendant des heures

Cause racine : Le connection tracking fixe les flux établis ; les changements s’appliquent seulement aux nouvelles connexions.

Correction : Effacez les entrées conntrack ciblées pour les flux affectés ou attendez. Évitez le « reboot pour appliquer le routage ».

6) Symptom : Le trafic VPN fuit vers l’internet quand le tunnel est down

Cause racine : Le policy routing utilise lookup avec fallback sur main ; quand la route VPN est absente, il bascule sur le WAN.

Correction : Utilisez lookup-only-in-table pour les destinations protégées afin d’éviter le fallback. Optionnellement, ajoutez des drops explicites LAN→destinations protégées quand le VPN est down, pour sécuriser en mode fermé.

7) Symptom : Le policy routing fonctionne jusqu’à l’activation de FastTrack

Cause racine : FastTrack contourne des parties du traitement firewall/mangle.

Correction : Désactivez FastTrack, ou exonérez les connexions liées au VPN du FastTrack (conception prudente et validation des compteurs requises).

8) Symptom : Le côté distant voit tous les clients comme l’IP WG du MikroTik

Cause racine : Masquerade trop large sur wg0.

Correction : Retirez le NAT global ; si le NAT est nécessaire, limitez-le aux sources LAN et à la liste de destinations protégées uniquement.

Trois mini-récits d’entreprise issus du terrain

Incident causé par une mauvaise hypothèse : « AllowedIPs est la politique de routage »

Une entreprise de taille moyenne a déployé WireGuard pour supporter un nouvel outil d’analytique interne. Ils avaient un hub en datacenter et des dizaines de petits sites sur MikroTik. L’objectif était split tunnel : seul 10.60.0.0/16 devait aller vers le datacenter ; tout le reste devait sortir en direct.

L’ingénieur configurant les branches a supposé que la liste allowed-address de WireGuard « forcerait » ces routes et isolerait le reste. Sur certains routeurs, ils avaient aussi une route statique résiduelle vers l’ancien gateway IPsec du datacenter, qui restait silencieuse dans main. Ce n’était pas évident car le tunnel montait toujours et le routeur avait plusieurs façons d’atteindre les mêmes préfixes.

Puis un support « serviable » du fournisseur a recommandé d’ajouter 0.0.0.0/0 aux AllowedIPs « pour la fiabilité ». Du jour au lendemain, la navigation depuis plusieurs branches a commencé à reboucler vers le datacenter, saturant un lien dimensionné pour les applis internes, pas pour le streaming et les mises à jour OS.

La cause racine n’était pas WireGuard ; c’était la gouvernance et une hypothèse : que AllowedIPs est un système de politique complet. Ce n’est pas le cas. C’est une pièce du puzzle et ne remplace pas des tables de routage explicites, une intention dans le pare-feu et des contrôles d’audit.

La correction a été peu glamour : supprimer 0/0, définir une liste d’adresses contrat, créer rt-vpn, et ajouter des routing rules pour seuls les préfixes protégés. Ils ont aussi ajouté un point de checklist avant changement : « grep des routes par défaut dans les tables non-main ». Personne n’a célébré, mais les graphiques ont arrêté de crier.

Optimisation qui a mal tourné : FastTrack pour « performance gratuite »

Une autre organisation avait un design split tunnel sensé mais commençait à atteindre les limites CPU sur de petits routeurs ARM. Quelqu’un a remarqué que FastTrack réduisait le CPU en contournant des parties du pare-feu pour les connexions établies. Ils l’ont activé globalement dans la chaîne forward et ont vu une amélioration immédiate des tests de vitesse Internet.

Deux semaines plus tard, des tickets sont arrivés : le CRM accessible via VPN fonctionnait quelques minutes, puis les sessions tombaient ou se connectaient aléatoirement depuis une mauvaise IP source. Les utilisateurs disaient « le VPN est instable ». Une fois cette étiquette posée, tout problème devenait automatiquement « la faute du VPN ».

L’équipe SRE a comparé les compteurs et a vu quelque chose d’étrange : la règle « LAN to VPN destinations » s’incrémente à peine, pourtant Torch montrait des rafales occasionnelles de trafic CRM sur le WAN. FastTrack avait effectivement court-circuité le chemin de traitement qui appliquait la décision de routage pour certains flux établis.

Ils ont résolu en désactivant FastTrack pour le trafic susceptible d’être soumis au policy routing. Pas globalement, pas en héros—juste assez pour préserver la cohérence. Le CPU est monté, mais les routeurs ont arrêté de mentir. Ils ont ensuite résolu le problème de performance correctement : meilleur choix matériel et réglage des queues, plutôt que de compter sur un contournement magique.

Pratique ennuyeuse mais correcte qui a sauvé la mise : vérification des changements par compteurs

Chez un prestataire financier (du genre qui a des fenêtres de changement et des gens qui aiment les tableurs), une équipe a standardisé leurs configs MikroTik. Chaque règle split tunnel avait un commentaire, et chaque règle importante avait des compteurs revus pendant la validation. Ils conservaient aussi un simple snapshot « avant/après » : tables de routage, routing rules, règles NAT et stats filter.

Un vendredi, un nouveau subnet a été ajouté au siège pour un service de facturation : 10.77.40.0/24. Un ingénieur réseau a ajouté la route côté hub et mis à jour les AllowedIPs WireGuard. Il a oublié de mettre à jour la liste d’adresses contrat et les routing rules des branches.

Le lundi matin, le symptôme était propre et limité : seule l’application de facturation échouait ; le reste fonctionnait. Parce que l’équipe avait la pratique de vérifier les compteurs de règles, le diagnostic a pris quelques minutes : les compteurs « LAN to VPN destinations » n’augmentaient pas quand les utilisateurs atteignaient les IPs de facturation. Cela a immédiatement pointé « destination non dans le contrat », pas « tunnel down ».

La correction a été une ligne dans la liste d’adresses et une route dans rt-vpn. Pas de downtime, pas de reboot d’urgence, pas de doigt pointé. Leur pratique « ennuyeuse »—traiter les compteurs comme signal de première classe—a transformé un incident en changement de routine. Voilà à quoi ressemble la maturité : moins d’adrénaline, plus de réparations contrôlées.

Listes de contrôle / plan étape par étape

Plan de construction (greenfield ou nettoyage)

1. Définir le contrat de split tunnel : lister les préfixes distants qui doivent transiter par le VPN, et seulement ceux-ci.
2. Créer la liste d’adresses addr-vpn-dsts avec ces préfixes et des commentaires pour la propriété / le contexte.
3. Créer une table de routage dédiée rt-vpn.
4. Ajouter des routes dans rt-vpn pour chaque préfixe protégé via wg0 (ou VTI pour IPsec).
5. Ajouter des routing rules pour chaque préfixe protégé : action lookup-only-in-table → rt-vpn.
6. Chaîne forward du pare-feu : accept established/related ; drop invalid ; allow explicite LAN→VPN-dsts ; allow LAN→WAN ; default drop.
7. NAT : n’ajoutez le masquerade LAN→VPN-dsts que si le côté distant ne peut pas router proprement.
8. Décision DNS : assurez-vous que les zones internes se résolvent via un DNS interne accessible par le VPN ; documentez-le.
9. Désactiver ou scoper FastTrack si cela interfère avec le policy routing.
10. Validation : testez une IP par préfixe protégé ; vérifiez les compteurs ; confirmez l’absence de routes par défaut involontaires.

Plan de changement (ajouter un nouveau subnet protégé)

1. Ajouter le préfixe à addr-vpn-dsts avec un commentaire nommant le propriétaire de l’appli/service.
2. Ajouter une route dans rt-vpn pour ce préfixe.
3. Ajouter une routing rule pour ce préfixe pointant vers rt-vpn.
4. Confirmer que les AllowedIPs WireGuard incluent ce préfixe (et ne sont pas plus larges que nécessaire).
5. Tester la reachabilité, puis surveiller les compteurs forward/NAT pour les incréments attendus.
6. Si DNS impliqué (nouveau hostname interne), vérifier le comportement du résolveur depuis un client.

Plan de rollback (parce que vous êtes un adulte)

1. Désactiver d’abord la nouvelle(s) routing rule(s) (revertit rapidement l’orientation du trafic).
2. Retirer/désactiver la/les nouvelle(s) route(s) rt-vpn.
3. Supprimer l’entrée de la liste d’adresses.
4. Effacer les entrées conntrack ciblées si des clients restent bloqués sur d’anciens chemins.
5. Capturer l’état : tables de routage, stats de règles, et info de handshake pour le postmortem.

Une idée paraphrasée à garder : « Tout échoue, tout le temps ; construisez des systèmes qui s’y attendent. » — Werner Vogels (idée paraphrasée)

FAQ

1) Dois-je implémenter le split tunneling avec des marques mangle ou des routing rules ?

Si les routing rules de RouterOS v7 couvrent vos besoins de matching, utilisez-les : elles sont plus lisibles et plus faciles à auditer. Utilisez le mangle quand vous devez matcher des attributs plus complexes (ports, DSCP, sous-réseaux utilisateurs), mais gardez-le minimal.

2) Où doit résider la « vérité » des destinations de split tunnel ?

À un seul endroit : une liste d’adresses contrat (ou une liste de préfixes strictement gérée). Ensuite, les routing rules et AllowedIPs doivent s’aligner dessus. Si vous dupliquez la logique en cinq endroits, vous finirez par diverger.

3) Ai-je besoin de NAT sur le VPN ?

Pas si vous pouvez router proprement de bout en bout. Le NAT sert quand vous ne pouvez pas : sous-réseaux qui se chevauchent, le côté distant ne peut pas ajouter de routes, ou restrictions fournisseur. Si vous devez NATer, limitez-le aux LAN→destinations protégées seulement.

4) Pourquoi ça fonctionne pour des IPs mais pas pour des noms d’hôtes ?

Parce que le DNS ne fait pas partie du routage. Votre tunnel peut être parfait et la résolution de noms peut être fausse. Résolvez les zones internes via un DNS interne accessible par le VPN, ou utilisez le transfert conditionnel.

5) Pourquoi l’activation de FastTrack a-t-elle cassé le split tunneling ?

FastTrack peut contourner des parties du traitement firewall/mangle. Si votre décision de routage dépend de ces étapes, FastTrack peut faire sauter le chemin de politique. Désactivez-le ou exonérez le trafic lié au VPN.

6) Comment empêcher la « fuite vers le WAN » quand le VPN est down ?

Utilisez lookup-only-in-table pour les destinations protégées afin d’éviter le fallback. Vous pouvez aussi ajouter un drop en forward pour LAN→destinations protégées quand la table VPN n’a pas de route active, pour échouer fermé.

7) Comment déboguer « certains utilisateurs affectés, pas tous » ?

Vérifiez si les utilisateurs affectés sont sur un sous-réseau/VLAN différent, utilisent des résolveurs DNS différents ou ont du DNS en cache. Ensuite, vérifiez conntrack : les sessions existantes ne suivront pas les nouvelles décisions de routage.

8) Dois-je jamais inclure 0.0.0.0/0 dans AllowedIPs sur les branches ?

Seulement si vous faites volontairement un full tunnel, et que vous l’avez conçu (capacité, supervision, politique de sécurité). Si votre objectif est split tunnel, 0/0 est un piège avec un contrat de support.

9) Quelle est la manière la plus propre d’auditer les changements au fil du temps ?

Utilisez des commentaires de règles cohérents, gardez le contrat de split tunnel dans des listes d’adresses, et revoyez périodiquement : tables de routage, routing rules, règles NAT et compteurs de filtre. Les audits doivent être assez rapides pour que vous les fassiez réellement.

Conclusion : prochaines étapes pratiques

Si votre configuration de split tunnel MikroTik vous semble fragile, c’est généralement parce que la politique est éparpillée : un peu dans AllowedIPs, un peu dans le mangle, un peu dans un NAT « temporaire », et un peu dans la mémoire de quelqu’un. Ramenez tout à un contrat et une table.

Faites ceci ensuite, dans l’ordre :

1. Créez (ou nettoyez) addr-vpn-dsts pour qu’elle contienne uniquement ce qui doit passer par le VPN.
2. Assurez-vous que rt-vpn contient uniquement des routes pour ces préfixes—pas de route par défaut sauf si vous le souhaitez.
3. Utilisez des routing rules (lookup-only-in-table) pour orienter uniquement ces destinations dans rt-vpn.
4. Auditez le NAT sur wg0 ; supprimez le masquerade global sauf si vous pouvez le justifier auprès de votre futur vous.
5. Exécutez le playbook de diagnostic rapide une fois en période saine et enregistrez les sorties et compteurs attendus.

Le split tunneling peut être propre. Mais il ne se fera pas par accident. Rendez la politique explicite, maintenez-la étroite, et laissez vos compteurs vous dire la vérité.