Mode opératoire — Tailscale : accès distant sans port ouvert

Document autonome. Partie théorique, puis mise en œuvre appliquée au pare-feu pfSense du laboratoire. La méthode vaut pour tout réseau placé derrière un NAT que l’on ne maîtrise pas.

Dernière mise à jour : 02/10/2026 État au 12/11/2026 : la zone VISITEURS (VLAN 50, 10.0.50.0/24) existe depuis le 30/10 ; ce MO décrit les quatre réseaux de départ ; depuis le 12/11, fw-01 annonce les 5 réseaux : 10.0.10.0/24, 10.0.20.0/24, 10.0.30.0/24, 10.0.40.0/24 et 10.0.50.0/24 (VISITEURS), ajouté par Axel dans VPN → Tailscale → Settings → Advertised Routes puis approuvé dans la console (Edit route settings) ; vérifié depuis le poste d’Axel : poste-visiteur (10.0.50.200) joignable sur le port 22 par l’interface Tailscale (captures 271, 272).

Sommaire

1 · Le problème : on ne peut pas ouvrir de port

1.1 La situation de départ

Le laboratoire est hébergé derrière le routeur de l’établissement. Cette machine n’appartient pas au TP : on ne peut ni la configurer, ni y demander une redirection de port.

   Internet                 routeur de l'etablissement           le laboratoire
                            (non administre par le TP)
  ┌────────────┐            ┌──────────────────────┐            ┌─────────────┐
  │ ag-lenovo  │ ─────X────►│  NAT                 │            │  pfSense    │
  │ a distance │  impossible│  aucune redirection  │            │ 10.1.0.197  │
  └────────────┘            └──────────────────────┘            └─────────────┘

Le point de blocage n’est pas le pare-feu du laboratoire — c’est celui d’au-dessus. Tant qu’on raisonne en « ouvrir une porte », on dépend de quelqu’un d’autre.

1.2 Le renversement

Un NAT laisse toujours sortir. Il mémorise la connexion sortante et laisse revenir les réponses : c’est le suivi d’état, exactement le mécanisme utilisé par le pare-feu du laboratoire.

L’idée est donc d’inverser le sens de l’initiative : plutôt que d’attendre une connexion entrante, la machine du laboratoire sort vers un point de rendez-vous, et maintient ce tunnel ouvert.

   ag-lenovo                point de rendez-vous               pfSense
       │                                                          │
       │  ──── connexion SORTANTE ────►  ◄──── connexion SORTANTE │
       │                                                          │
       └══════════ tunnel chiffre, dans les deux sens ════════════┘

   Les DEUX cotes sortent. Aucun des deux n'a besoin d'accepter une entree.

C’est le même principe que celui qui fait fonctionner un appel visio derrière deux box familiales : personne n’ouvre de port, les deux postes sortent vers un serveur qui les met en relation.

2 · Ce qu’est Tailscale

2.1 Deux couches qu’il faut distinguer

C’est la notion centrale, et la source de la plupart des malentendus.

   PLAN DE CONTROLE  (serveurs Tailscale)
   ┌──────────────────────────────────────────────┐
   │  qui es-tu · voici les cles publiques des    │
   │  autres · voici leurs adresses du moment     │
   └───────▲──────────────────────────▲───────────┘
           │ metadonnees              │ metadonnees
           │                          │
   ┌───────┴───────┐          ┌───────┴───────┐
   │   ag-lenovo   │══════════│    pfSense    │
   └───────────────┘ WireGuard└───────────────┘
                     chiffre de bout en bout
                     LES DONNEES NE PASSENT PAS PAR TAILSCALE

Les clés privées ne quittent jamais les machines. Tailscale distribue les clés publiques et joue les entremetteurs ; il ne peut pas déchiffrer le trafic. C’est la réponse à la question « vous faites passer tout votre réseau par une société tierce ? » — non : les métadonnées, oui ; les données, non.

2.2 Le vocabulaire

Pourquoi 100.64.0.0/10 : c’est la plage CGNAT, réservée par la norme aux opérateurs pour leur NAT de grande échelle. Elle n’est ni publique, ni dans les plages privées habituelles (10., 172.16., 192.168.) — donc elle n’entre jamais en conflit avec un réseau local existant. C’est précisément pour cela qu’elle a été choisie.

2.3 Direct ou relayé

Deux nœuds essaient toujours de se parler directement. Le plan de contrôle leur communique mutuellement leurs adresses publiques et leurs ports, et chacun envoie un paquet vers l’autre au même moment : chaque NAT voit alors partir une connexion sortante, et accepte la réponse.

Le repli sur 443 est ce qui rend Tailscale utilisable partout. Même un réseau qui ne laisse sortir que le web laisse passer le tunnel. C’est une qualité du point de vue de l’utilisateur — et, du point de vue de l’administrateur du réseau traversé, un contournement qu’il faut savoir nommer.

3 · Ce que Tailscale ne fait pas

Un mode opératoire qui n’énonce que les bénéfices produit un faux sentiment de sécurité.

La phrase à retenir, et à savoir défendre à l’oral. Tailscale ne supprime pas la surface d’attaque, il la déplace vers un compte. Qui prend le contrôle du compte du tailnet obtient l’accès que ce compte possède. Toute la sécurité du laboratoire repose alors sur cette authentification — c’est le sujet du §12.

4 · Les trois façons de l’installer

4.1 Le choix de topologie

Topologie retenue : B — subnet router.

4.2 Et surtout : sur quelle machine ?

C’est la décision structurante de cette étape. Deux candidats existaient : le bastion srv-docker (10.0.30.12) et le pare-feu pfSense.

   SUR LE BASTION                          SUR LE PARE-FEU
   ──────────────                          ───────────────
   tailnet                                 tailnet
      │                                       │
      ▼                                       ▼
   srv-docker  ── SNAT ──► tout             pfSense ──► VLAN 10
   10.0.30.12   le trafic semble                    ──► VLAN 20
                venir de .12                        ──► VLAN 30
                                                    ──► VLAN 40
   le pare-feu ne distingue plus           chaque flux garde son
   l'origine reelle                        adresse source d'origine

Le principe général : placer le point d’entrée VPN sur le routeur, pas derrière lui. Derrière le routeur, le VPN doit masquer les adresses pour que les réponses lui reviennent — et ce masquage détruit l’information dont le pare-feu a besoin pour filtrer.

Pourquoi pfSense n’a besoin d’aucun réglage supplémentaire pour router : c’est déjà un routeur, le réacheminement de paquets y est actif par construction. Sur un Linux utilisé comme subnet router, il aurait fallu l’activer explicitement :

echo 'net.ipv4.ip_forward = 1' | sudo tee /etc/sysctl.d/99-tailscale.conf
sudo sysctl -p /etc/sysctl.d/99-tailscale.conf
sudo tailscale up --advertise-routes=10.0.10.0/24,10.0.20.0/24

C’est l’oubli classique : les routes apparaissent dans la console, elles sont approuvées, et rien ne passe, parce que le noyau refuse de faire transiter un paquet qui ne lui est pas destiné.

5 · Préparer le tailnet

5.1 Une identité = un tailnet

C’est le piège d’entrée, et il coûte du temps.

Se connecter avec un compte déjà utilisé ne crée pas un nouveau réseau — il ramène sur celui qui existe déjà. Un compte Google personnel déjà employé pour un tailnet domestique replacerait le pare-feu du laboratoire dans le réseau de la maison.

Un tailnet dédié au BTS a donc été créé, avec une identité distincte du réseau personnel.

L’alternative aurait été un seul tailnet avec des tags et des ACL : plus souple — les deux réseaux visibles en même temps — mais il faut écrire une politique. Le compte séparé garantit l’isolation par construction, au prix d’une bascule de profil (tailscale switch).

Si une erreur 403 — session expired apparaît à la création du compte : le navigateur porte encore les cookies du tailnet précédent. Fenêtre de navigation privée, ou vider les cookies du site.

5.2 La clé d’authentification

Enrôler pfSense suppose de prouver son identité. Sur une machine sans navigateur — ou que l’on administre à distance — on ne peut pas suivre le lien d’authentification habituel : on génère donc une clé pré-authentifiée.

Admin console → Settings → Keys → Generate auth key

Une clé tskey-auth-… est un secret de même niveau qu’un mot de passe d’administration. Elle ne se colle ni dans un document, ni dans un dépôt Git, ni dans un message. Une fois le nœud enrôlé, elle est consommée : on peut la révoquer dans la console.

6 · Installer et configurer le paquet sur pfSense

6.1 Installation

System → Package Manager → Available Packages → rechercher Tailscale → Install

Le menu VPN → Tailscale apparaît une fois l’installation terminée.

6.2 Onglet Authentication

Le champ Login Server existe parce que Tailscale peut fonctionner avec un plan de contrôle auto-hébergé (headscale, une réimplémentation libre). On garde ici le serveur officiel : c’est la valeur par défaut.

6.3 Onglet Settings

Les routes annoncées :

Pourquoi quatre lignes plutôt qu’un 10.0.0.0/16 global : annoncer exactement ce que l’on veut rendre joignable. Un /16 engloberait aussi les réseaux non créés — ce que l’on n’a pas décidé d’exposer, on ne l’annonce pas. Et chaque ligne porte sa description, donc la console reste lisible.

Ce que cette page ne fait pas : annoncer une route ne la rend pas utilisable. Il reste deux conditions, dans la console (§7) et sur le poste (§8). C’est la cause la plus fréquente de « ça ne marche pas ».

7 · Côté console d’administration

7.1 Approuver les routes

Admin console → Machines → le nœud pfSense → Edit route settings → approuver les quatre réseaux.

Pourquoi cette validation existe. Un nœud peut prétendre router n’importe quel réseau. Sans approbation, n’importe quelle machine enrôlée pourrait s’auto-déclarer routeur de 192.168.1.0/24 et intercepter le trafic que les autres destinent à ce réseau. L’approbation transforme une déclaration en autorisation : elle doit venir de l’administrateur du tailnet, pas du nœud lui-même.

Les routes approuvées s’affichent alors en clair sous le nœud dans la liste des machines.

7.2 Désactiver l’expiration de clé

Sur le nœud pfSense → Disable key expiry

C’est une panne différée de six mois. Elle arrive au pire moment, et rien dans le symptôme ne désigne la cause : le laboratoire fonctionne, le tunnel n’existe plus. Sur un nœud d’infrastructure permanent, l’expiration se désactive le jour de l’enrôlement.

Noter que c’est un arbitrage assumé : une clé qui n’expire pas est une clé qu’il faut révoquer à la main le jour où la machine sort du périmètre.

8 · Côté poste de travail

Installation du client, puis connexion au tailnet du BTS — en vérifiant bien le profil actif si le poste appartient déjà à un autre tailnet (tailscale switch).

8.1 Le réglage que tout le monde oublie

Cocher « Use Tailscale subnets ».

Menu du client → Preferences → Use Tailscale subnets

Pourquoi ce n’est pas activé par défaut. Accepter les routes d’un subnet router modifie la table de routage du poste. Si un nœud annonçait 192.168.1.0/24 et que le poste est chez lui sur ce réseau, son imprimante deviendrait inaccessible. Tailscale demande donc un consentement explicite : j’accepte que d’autres machines influencent mon routage.

8.2 Vérifier sans rien supposer

PS> tailscale status
100.84.62.27  sio2527-pfsense-axel  freebsd  active; direct 10.1.0.197:41641, tx 572 rx 156

PS> ping 10.0.30.12
Reponse de 10.0.30.12 : octets=32 temps=12 ms
Paquets : envoyes = 2, recus = 2, perdus = 0 (0% de perte)

PS> ssh [email protected]
Linux SRV-WEB 6.12.107+deb13-amd64

Validation — Le poste de travail joint l’intégralité du laboratoire : SSH direct, interfaces web, interface d’administration de pfSense — sans rebond, sans tunnel manuel, et sans aucun port ouvert sur le réseau de l’établissement.

9 · La règle de pare-feu

9.1 Une interface sans règle ne laisse rien passer

Le paquet crée une interface tailscale0 et la place dans un groupe pf nommé Tailscale. Un onglet dédié apparaît alors dans Firewall → Rules, sans qu’il faille assigner l’interface.

Ne pas chercher tailscale0 dans Interface Assignments — il n’y figure pas, et ce n’est pas un défaut. Le groupe pf suffit à pfSense pour créer l’onglet. L’interface existe bel et bien :

ifconfig tailscale0
tailscale0: flags=1008043<UP,BROADCAST,RUNNING,MULTICAST,LOWER_UP> mtu 1280
        inet 100.84.62.27 netmask 0xffffffff
        groups: tun Tailscale

La ligne groups: est la réponse : elle indique comment pf référence cette interface.

mtu 1280 est normal pour WireGuard, qui réduit la taille utile des trames pour loger son encapsulation.

À la création, l’onglet affiche « No rules are configured for this interface ». Rien ne passe — c’est le comportement par défaut de pfSense sur toute interface.

9.2 La règle

Firewall → Rules → onglet Tailscale → Add

9.3 Pourquoi any en source, et non la plage 100.64.0.0/10

Le réflexe serait de restreindre la source à la plage CGNAT. Trois raisons de ne pas le faire :

La bonne granularité n’est pas toujours la plus fine. Une règle inutilement étroite donne l’illusion du contrôle tout en créant des pannes difficiles à diagnostiquer. Ici, la restriction utile se configure dans la console Tailscale, pas dans le pare-feu — voir §12.3.

Décision à assumer, pas à masquer. Cette règle fait du tailnet une zone de confiance disposant d’un accès complet au laboratoire. C’est l’objectif recherché, et c’est une entrée de plus dans la matrice de flux, au même titre que le WAN.

9.4 Le sens de lecture

   interface USERS                     interface tailscale0
   ───────────────                     ────────────────────
   les regles de l'onglet USERS        les regles de l'onglet Tailscale
   s'appliquent aux paquets qui        s'appliquent aux paquets qui
   ARRIVENT par USERS                  ARRIVENT par le tunnel

Les règles pfSense s’appliquent en entrée d’interface. Un paquet venu du tunnel n’est jamais évalué par les règles des onglets VLAN : il entre par tailscale0, et c’est cet onglet-là, et lui seul, qui décide. C’est pour cela que le tunnel traverse la segmentation sans la contredire techniquement — et c’est aussi pour cela qu’il faut le documenter comme une voie à part entière.

10 · Le DNS

10.1 Pourquoi Accept DNS reste décoché sur pfSense

Tailscale pousse sa propre configuration DNS aux nœuds qui l’acceptent. Sur un poste client, c’est pratique. Sur le résolveur du laboratoire, c’est destructeur :

   Accept DNS COCHE sur pfSense
   ────────────────────────────
   pfSense adopte les DNS de Tailscale
      └──► sa propre configuration de resolution est ECRASEE
             └──► les machines du laboratoire interrogent pfSense
                    └──► qui interroge desormais autre chose que prevu

Un nœud qui est lui-même serveur DNS ne doit pas accepter la configuration DNS d’un tiers. La règle vaut au-delà de Tailscale : elle vaut pour tout client DHCP, tout agent VPN, toute configuration automatique.

10.2 Ce que MagicDNS résout — et ce qu’il ne résout pas

MagicDNS ne connaît que les nœuds du tailnet. Les machines situées derrière un subnet router lui sont invisibles — il ne voit qu’une route, pas les noms.

La conséquence concrète : le poste distant atteint 10.0.10.5 sans problème, mais ne sait pas que ce nom existe.

Tailscale donne la connectivité réseau, pas le DNS du réseau joint. Les deux sont des services distincts, et c’est exactement le genre de confusion qui fait conclure à tort « le VPN ne marche pas » alors que ping 10.0.10.5 répond.

10.3 Le DNS fractionné — la réponse propre

Statut : procédure établie, non encore appliquée. Elle est décrite ici pour être exécutée telle quelle, et vérifiée au moment de l’application.

L’objectif : que le poste distant interroge pfSense pour *.sio.internal et uniquement pour ça, en conservant son DNS habituel pour tout le reste.

   ag-lenovo
      │
      ├── *.sio.internal  ──►  100.84.62.27  (pfSense sur le tailnet)
      │                              └──► Host Override → 10.0.10.5
      │
      └── tout le reste   ──►  DNS habituel de la machine

Deux côtés à configurer, dans cet ordre.

① Côté pfSense — autoriser le tailnet à interroger le résolveur

C’est l’étape que l’on oublie. Par défaut, le résolveur de pfSense n’accepte les requêtes que des réseaux directement connectés. La plage Tailscale n’en fait pas partie : les requêtes seraient refusées sans explication.

Services → DNS Resolver → Access Lists → Add

Vérifier également, dans General Settings, que Network Interfaces vaut All — sinon le résolveur n’écoute pas du côté du tunnel.

② Côté Tailscale — déclarer le résolveur fractionné

Admin console → DNS → Nameservers → Add nameserver → Custom

Pourquoi « restrict to search domain » est indispensable. Sans cette case, tout le trafic DNS de tous les nœuds du tailnet partirait vers pfSense — et chaque nœud perdrait la résolution de noms dès que le laboratoire serait éteint. Le DNS fractionné dit : « pour ce domaine-là, ce serveur-là ; pour le reste, ne change rien ».

Vérification :

Resolve-DnsName www.sio.internal

→ doit répondre 10.0.10.5.

Le dépannage immédiat, si le besoin est ponctuel : une ligne dans le fichier hosts du poste, ou curl --resolve www.sio.internal:443:10.0.10.5 … le temps d’une commande. Utile, mais à ne pas confondre avec la solution — l’une se répète sur chaque poste, l’autre non.

11 · Diagnostic

11.1 tailscale status, la commande qui tranche

Une seule ligne répond à la question la plus coûteuse en temps : « le paquet n’arrive pas, ou il arrive et il est refusé ? »

PS> tailscale status
100.84.62.27  sio2527-pfsense-axel  freebsd  active; direct 10.1.0.197:41641, tx 572 rx 156
                                    ▲▲▲▲▲▲   ▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲▲   ▲▲▲▲▲▲▲▲▲▲▲▲
                                      ①              ②                      ③

rx non nul est la preuve décisive. Si le réseau était en cause, le compteur de réception resterait à 0. Des octets reviennent : le tunnel fonctionne, donc le blocage est au-delà — dans le pare-feu, le routage ou le service visé. C’est exactement ce qui a permis d’écarter l’hypothèse réseau et de conclure à la règle de pare-feu manquante.

C’est l’équivalent, pour le tunnel, de la colonne States de pfSense.

11.2 Les autres commandes utiles

Sur pfSense, ces commandes se lancent depuis Diagnostics → Command Prompt ou en SSH.

11.3 Tableau de panne

L’ordre de diagnostic qui fait gagner du temps, pour « le tunnel est monté mais rien ne répond » : tunnel → routes → pare-feu → service. Chaque étape a sa preuve propre (tailscale status, la console, le journal du pare-feu, un test local sur la machine cible), et on ne passe à la suivante qu’après avoir validé la précédente.

12 · Ce que le tunnel coûte en sécurité

12.1 Énoncer le compromis

Le tunnel donne au tailnet un accès complet aux quatre VLAN, sans passer par le filtrage inter-VLAN. La question en découle naturellement : « votre segmentation est-elle contournable ? »

La réponse honnête est oui — par le tailnet, et c’est un choix documenté.

Un accès hors-bande n’est pas une faille — c’est une catégorie reconnue. Ce qui serait une faille, c’est de ne pas l’identifier comme tel, de ne pas en restreindre le périmètre, et de ne pas le faire figurer dans la matrice de flux.

12.2 Les trois mesures qui conditionnent la validité de l’argument

La sécurité de tout le laboratoire repose désormais sur le compte du tailnet. Trois mesures, toutes gratuites :

Sans le point 2, quiconque obtiendrait l’identité pourrait inscrire une machine dans le tailnet et hériter aussitôt d’un accès complet aux quatre VLAN. L’approbation manuelle transforme un secret unique en double condition : il faut l’identité et l’action de l’administrateur.

12.3 L’évolution canonique : filtrer dans le tailnet

Trois niveaux de restriction sont possibles. Le troisième est la version canonique.

Le principe de l’option C. Le tailnet possède une politique d’accès — un fichier au format JSON commenté, éditable dans Admin console → Access Controls. Par défaut, elle autorise tout :

{
  "acls": [
    { "action": "accept", "src": ["*"], "dst": ["*:*"] },
  ],
}

Une politique restrictive s’appuierait sur des tags — des étiquettes posées sur les nœuds, qui remplacent le raisonnement par adresse IP :

{
  "tagOwners": {
    "tag:lab-routeur": ["autogroup:admin"],
    "tag:poste-admin": ["autogroup:admin"],
  },

  // les routes du laboratoire sont approuvees d'office
  // pour tout noeud portant le tag du routeur
  "autoApprovers": {
    "routes": { "10.0.0.0/16": ["tag:lab-routeur"] },
  },

  "acls": [
    {
      "action": "accept",
      "src":    ["tag:poste-admin"],
      "dst":    ["10.0.30.0/24:22,443", "10.0.40.1:443"],
    },
  ],
}

Esquisse à éprouver, pas à copier les yeux fermés. Une politique d’accès se teste avec un second accès ouvert — ici la console de l’hyperviseur — car une erreur de syntaxe ou de périmètre peut couper le tunnel que l’on est en train d’utiliser pour la corriger.

Ce que l’option C change vraiment. En A et B, le paquet traverse le tunnel puis est filtré à l’arrivée. En C, il n’entre jamais dans le tunnel : le filtrage a lieu à la source, dans le plan de contrôle. C’est la différence entre fermer une porte et ne pas donner la clé.

13 · Pièges et checklists

13.1 Les dix pièges

Les pièges 2, 3 et 4 produisent exactement le même symptôme — le nœud répond en 100.x, rien ne répond en 10.0.x.x. Il faut donc les vérifier dans l’ordre, et non au hasard : console (route approuvée ?), poste (subnets acceptés ?), pare-feu (règle présente ?).

13.2 Checklist — mise en service d’un subnet router

• Tailnet dédié, sur une identité qui ne sert à rien d’autre
• Clé d’authentification non réutilisable, et révoquée après usage
• Le nœud est le routeur, pas une machine derrière lui
• Réacheminement de paquets actif (implicite sur pfSense, à activer sur Linux)
• Routes annoncées : exactement les réseaux à exposer, chacune décrite
• Accept DNS décoché si le nœud est lui-même serveur DNS
• Routes approuvées dans la console
• Expiration de clé désactivée sur le nœud
• Use Tailscale subnets coché sur le poste
• Règle de pare-feu créée sur l’onglet dédié, en IPv4+IPv6
• Validation faite depuis l’extérieur du réseau, pas seulement sur place

13.3 Checklist — sécurité du tailnet

• Double authentification active sur l’identité
• Device approval activé
• Liste des machines revue — aucun nœud inconnu ni obsolète
• Aucune clé d’authentification valide qui traîne
• L’accès par le tunnel figure dans la matrice de flux, comme toute autre voie d’entrée
• La question « que peut faire quelqu’un qui obtient ce compte ? » a une réponse écrite

13.4 Checklist — avant de dire « Tailscale ne marche pas »

• tailscale status : le nœud est-il active ?
• tx et rx sont-ils tous les deux non nuls ?
• Si oui → le tunnel fonctionne, chercher au-delà
• La cible répond-elle depuis une machine du même VLAN ?
• Le journal du pare-feu montre-t-il le paquet, et sur quelle interface ?
• Le service visé écoute-t-il vraiment ? (ss -tlnp sur la cible)

Le réflexe à garder. Tailscale rend l’accès distant si simple qu’on oublie ce qu’il est : une voie d’entrée de plein droit dans l’infrastructure, qui ne doit rien au pare-feu. Elle mérite donc le même traitement que le WAN — figurer au schéma, figurer à la matrice de flux, et avoir un responsable identifié. Un accès que l’on ne documente pas est un accès que l’on ne révoque pas.