Ajoutez un VPN de site à côté du routeur du FAI sans couper les appels

La plupart des petits sites ont déjà une boîte qui fait l’internet, le DHCP et la ligne vocale, et cette boîte ne fera pas le tunnel du site. Ajouter une seconde passerelle pour la voie privée fonctionne, à condition de décider qui possède chaque route avant de toucher un câble. Le vrai risque n’est pas le tunnel, c’est de changer en silence l’équipement qui garde les téléphones enregistrés. Faites les cinq vérifications dans l’ordre et arrêtez-vous là où l’une échoue.

Notez les rôles qui fonctionnent déjà

Relevez la passerelle par défaut, le serveur DHCP, le résolveur et l’équipement qui porte l’enregistrement vocal de l’opérateur. Ici le routeur du FAI est 10.50.0.1, la nouvelle passerelle sera 10.50.0.2 et le site distant 10.60.0.0/24. Rien dans ce plan ne change les trois premiers rôles, et c’est précisément le but. Vérifiez ensuite que la seconde boîte peut réellement terminer le tunnel : protocole, débit attendu, et si elle reçoit des mises à jour de micrologiciel ou de paquets. Un équipement avec un logo VPN et sans voie de mise à jour est une charge, pas un ajout.

Si vous ne pouvez pas dire qui possède le service vocal, arrêtez. Changer le routeur qui porte un enregistrement sans plan de retour transforme un projet VPN en panne téléphonique.

Donnez à la nouvelle passerelle une adresse et une tâche

Réservez son adresse LAN hors du pool DHCP pour qu’elle ne bouge pas après un redémarrage, et ne lui donnez pas de route par défaut propre sauf si vous voulez en faire un chemin internet. Sa tâche est de tenir le tunnel et de répondre pour les préfixes distants. Sur les hôtes du LAN qui doivent joindre le site distant, prouvez quelle route ils prennent maintenant et laquelle vous voulez après le changement ; les deux mêmes commandes avant et après sont la preuve la moins chère.

ip route get 10.60.0.55
ip neigh show 10.50.0.2
traceroute -n 10.60.0.55

Si la recherche renvoie le routeur du FAI et que le traceroute meurt à la frontière internet, l’hôte n’a pas encore de route distante, ce qui est attendu. Si elle renvoie quelque chose d’inattendu, réglez-le d’abord, car chaque étape suivante suppose cette base.

Choisissez qui possède la route du préfixe distant

L’option A est le routeur du FAI : il garde une route statique pour 10.60.0.0/24 vers la passerelle, et chaque hôte suit sa passerelle par défaut comme avant. L’option B est par hôte : seules les machines qui ont besoin du site distant reçoivent une route explicite via 10.50.0.2, tout le reste reste intact. A est plus propre pour beaucoup d’hôtes, mais exige souvent que le routeur de l’opérateur accepte une route statique, ce que certains refusent. B ne demande aucune coopération de l’opérateur mais vous laisse maintenir la configuration des hôtes, donc convient à un petit ensemble de machines approuvées.

Dans les deux cas, la direction de retour doit exister. Si une réponse distante arrive à la passerelle et que celle-ci la transmet directement à un hôte du LAN, le trafic contourne l’état du pare-feu que le routeur du FAI tenait sur le chemin aller. Quand la passerelle n’est pas le routeur par défaut du LAN, cette asymétrie est une décision de conception, pas un défaut à ignorer.

ip route add 10.60.0.0/24 via 10.50.0.2 dev eth0
ip route get 10.60.0.55 from 10.50.0.77

Rendez l’entrée permanente via le propriétaire de la configuration de l’hôte, pas via un script de connexion. Une route qui n’existe qu’après une connexion échouera la première fois que la machine redémarre pour une raison sans rapport.

Prévoyez un point d’entrée joignable

La passerelle a besoin d’une adresse que le site distant peut atteindre. Derrière le routeur du FAI, cela veut dire une redirection de port ou une entrée DMZ, et les deux dépendent de la livraison réelle du trafic par l’opérateur. Une redirection locale ne surmonte pas le NAT opérateur côté fournisseur. Si l’opérateur ne donne pas de point joignable, inversez le sens : laissez les deux sites initier vers un concentrateur que vous contrôlez. C’est une conception valable, mais elle ajoute une troisième dépendance pour l’acheminement, la confiance et la disponibilité, et le DNS dynamique ne la remplace pas.

Confirmez la redirection par une capture sur la passerelle, pas par un site qui scanne les ports. Les scanners annoncent le port fermé tant que l’écouteur n’est pas lié, et une redirection qui ne livre jamais de trafic ressemble de l’extérieur à un port fermé.

Acceptez le service privé et la ligne vocale ensemble

Testez le fonctionnement prévu depuis un hôte du LAN, avec un DNS privé et les identifiants de l’application elle-même. Un tunnel routé ne fait pas ressembler la navigation distante à un segment Ethernet local, donc la découverte et la résolution de noms demandent leurs propres dispositions.

curl -sS -o /dev/null -w '%{http_code}\n' https://files.example.net
ping -c 3 10.60.0.55

Confirmez ensuite que l’accès internet ordinaire fonctionne toujours depuis le même hôte et que les téléphones sont toujours enregistrés ; ces deux contrôles attrapent un changement accidentel de la route par défaut, la façon la plus courante dont ce projet casse quelque chose qu’il ne voulait pas toucher. Terminez par une note de reprise écrite : quel équipement porte quel rôle, les adresses réservées, et comment retirer la route du préfixe distant en une étape. Une voie privée que l’on peut retirer proprement vaut plus qu’une qui marche seulement aujourd’hui.