Trafic à sens unique après désactivation du SNAT de sous-réseau Tailscale

Désactivez le NAT source sur un routeur de sous-réseau Tailscale : le tunnel continue de fonctionner tandis que les connexions qui le traversent s'arrêtent. Les requêtes arrivent à destination avec l'adresse overlay propre au client distant, ce qui est précisément l'objectif du changement, et les réponses ont désormais besoin d'un chemin que le LAN n'a jamais eu à connaître. Sans ce chemin, les paquets arrivent, les réponses repartent par la passerelle ordinaire, et la panne se présente comme un problème de pare-feu qu'aucune règle de pare-feu n'explique. Le tunnel est sain ; le segment de retour manque.

Ce que le SNAT dissimulait

Lorsque le SNAT est activé, le routeur réécrit l'adresse source en sa propre adresse LAN avant de transmettre vers le sous-réseau, si bien que la destination répond à un hôte dont elle sait déjà comment l'atteindre et que rien d'autre n'a besoin d'être configuré. Le désactiver préserve la source d'origine, et la destination voit alors une adresse dans la plage overlay plutôt qu'un voisin sur son propre câble. Cette adresse est réelle et routable à travers le tailnet, et elle est injoignable depuis le LAN via la passerelle par défaut. Le commutateur documenté est --snat-subnet-routes=false, appliqué au routeur de sous-réseau Linux lui-même.

C'est un réglage permanent et non un commutateur par paquet, donc le chemin de retour doit exister pour chaque réseau de destination que ce routeur dessert. C'est ce qui fait du changement une décision de déploiement plutôt qu'une case à cocher. Tout ce que ce routeur dessert hérite de l'exigence au même moment.

Où le chemin de retour peut résider

Trois emplacements sont courants, et ils diffèrent par leur portée, non par leur justesse. Une route statique sur l'hôte de destination est la plus directe et la moins extensible, car chaque appareil a besoin de sa propre copie. Une table de routage dans le VPC ou le routeur du site couvre tout un réseau d'un coup, et une option DHCP transportant des routes statiques sans classe atteint automatiquement les clients mais échoue silencieusement sur les appareils qui l'ignorent.

ip route add 100.64.0.0/10 via 192.168.1.10
ip route get 100.64.0.5

Quel que soit l'emplacement choisi, le saut suivant est l'adresse LAN du routeur et jamais son adresse tailnet. Un hôte du LAN ne peut pas atteindre l'overlay avant de posséder cette route, donc un saut suivant à l'intérieur de l'overlay est circulaire et n'envoie le paquet nulle part. Cette seule erreur explique la plupart des configurations qui semblent correctes et échouent quand même, et elle survit à toute vérification qui ne lit que la table du routeur lui-même. Notez l'emplacement utilisé, sinon la personne suivante testera le mauvais.

Lire la panne comme un trafic à sens unique

Le symptôme est plus facile à reconnaître que la cause : le service répond sur le routeur lui-même et reste muet depuis un client distant. Une capture sur la destination montre des requêtes qui arrivent et des réponses qui partent, ce qui ressemble à un succès jusqu'à ce que l'on remarque où vont ces réponses. Elles partent vers la passerelle par défaut, ce qui signifie que le segment entrant a fonctionné et que le segment de retour non.

Capturez plutôt sur le routeur, car il voit les deux directions d'un même échange et indique si une réponse est jamais arrivée. Si la réponse apparaît sur la destination mais jamais sur le routeur, la route manque ou est fausse du côté destination. Si elle apparaît sur le routeur et s'y arrête, le problème se situe plus loin et relève d'une autre investigation.

sudo tcpdump -ni any host 100.64.0.5
ip route get 100.64.0.5

L'adresse réelle vaut-elle une route

Conserver le SNAT reste la réponse la plus simple dès que le réseau de destination ne peut pas être reconfiguré, et le coût est que chaque client ressemble au routeur dans les journaux et la politique de la destination. Le désactiver se justifie lorsqu'une application a besoin de l'adresse source réelle ou que la politique réseau doit distinguer des clients qui partagent un routeur. Les deux raisons sont légitimes et aucune n'est gratuite. Le bénéfice doit valoir la maintenance d'une route sur chaque réseau de destination, plus la revue du pare-feu décrite ci-dessous.

Pour un petit LAN, l'échange paie généralement, tandis que pour une multitude d'appareils qui ne peuvent pas prendre de route statique, il ne paie généralement pas. Consignez la décision et la raison à côté de la configuration du routeur, afin que l'administrateur suivant sache quel comportement est délibéré. Un défaut que personne n'a écrit ne se distingue pas d'un oubli.

Pare-feu, journalisation et le double rôle

Chaque règle qui correspondait à l'adresse LAN du routeur correspond désormais à une source différente, y compris les règles d'autorisation et tout champ de journal qui enregistrait le routeur comme client. Lisez ces règles avant le premier test plutôt qu'après le premier échec, car une règle n'autorisant que l'adresse du routeur bloque purement et simplement la nouvelle source. Restreignez le remplacement aux clients et ports qui en ont besoin, puis confirmez qu'il n'admet pas discrètement tout le tailnet.

sudo nft list ruleset | grep -n '100\.64'
sudo iptables-save | grep -n '100\.64'

Un nœud servant à la fois de nœud de sortie et de routeur de sous-réseau est une combinaison documentée qui peut perdre le trafic montant une fois le SNAT de sous-réseau désactivé. Séparer ces rôles sur des nœuds différents supprime cette réserve et donne à chaque route et politique de pare-feu un seul propriétaire. Si les rôles doivent rester ensemble, attendez-vous à ce comportement et testez-le avant d'accuser un client. Conservez la route, le réglage du commutateur et l'attribution des rôles dans une seule note, car ils se lisent ensemble lorsque la connexion suivante échoue.