Clients en aval derrière un VPN amont : route ou NAT ?

Une passerelle fait tourner WireGuard pour vos propres appareils et un client OpenVPN vers le réseau de quelqu'un d'autre. Le transfert entre les deux interfaces internes fonctionne, et il est facile de conclure que le sous-réseau en aval fait désormais partie du service amont. Ce n'est pas le cas. Une route tirée par le client indique à votre passerelle où envoyer les requêtes ; elle ne dit rien de la manière dont le réseau distant renvoie le trafic vers des appareils dont il n'a jamais entendu parler. Choisissez un modèle de retour que l'amont prend réellement en charge avant d'ajouter une seule règle.

Décidez du modèle de retour avant de toucher au routage

Dans ce parcours, les clients en aval utilisent 10.90.0.0/24, l'adresse de tunnel amont attribuée à la passerelle est 10.80.0.6, et la ressource distante approuvée est 172.20.0.30. Deux modèles correspondent à cette forme : conserver la source en aval et obtenir que le côté distant la route, ou traduire la source vers l'adresse de tunnel de la passerelle elle-même. Tout ce qui suit cette décision est mécanique, et la décision elle-même exige le propriétaire du service. L'une des lignes ci-dessus est un accord de routage avec le côté distant ; l'autre est un changement de politique local que vous pouvez faire seul. Confondre les deux, c'est ce qui transforme un changement de dix minutes en négociation.

preserved:  10.90.0.23 -> 172.20.0.30
translated: 10.80.0.6  -> 172.20.0.30

Choisissez une ligne et tenez-vous-y. Les lignes sont des alternatives, pas des étapes, et les mélanger produit une conception que personne ne peut expliquer en revue.

Conservation de la source par routage

Le côté distant reçoit une requête depuis une adresse en aval, il a donc besoin d'une route prise en charge et de la propriété du peer pour ce sous-réseau, plus d'une autorisation de l'accepter. Ce sont des réglages distants, et aucune route Linux locale ne les crée. Demandez-les explicitement, par écrit, avec le préfixe et le peer de tunnel qui le portera, et attendez-vous à ce que la réponse dépende du fait que le service prend en charge ou non des arrangements site à site.

Si la réponse est oui, la configuration locale est mince : transfert activé, les allowed-ips du peer WireGuard couvrant la plage en aval, et une politique de pare-feu qui autorise le franchissement dans les deux sens.

Traduction de source délibérée

Si le service ne renvoie le trafic que vers l'adresse du client connecté, traduisez la source vers cette adresse à la sortie et conservez l'état conntrack qui l'inverse pour les réponses. Limitez la règle aux sources en aval prévues, aux destinations distantes prévues et à l'interface amont. Une règle qui traduit tout ce qui sort de chaque interface est une politique bien plus large que cette exigence, et elle vous surprendra plus tard.

IPv6 a besoin de sa propre conception ; copier une ligne de masquerade IPv4 n'est pas une architecture. Testez le chemin traduit avec une connexion neuve plutôt qu'une connexion en cache.

Le chemin de données local doit encore fonctionner

La traduction ne supprime pas le travail local : la passerelle a encore besoin d'une route vers les destinations en aval, de la bonne propriété de source du peer WireGuard, du transfert activé et d'une politique de pare-feu étroite entre interfaces. Une requête générée sur la passerelle elle-même n'exerce aucune de ces permissions, et c'est pourquoi les tests locaux sur la passerelle passent alors que les appareils en aval échouent encore.

Testez depuis un véritable appareil en aval, pas depuis la passerelle. L'adresse source est tout l'intérêt de l'exercice.

Une source signifie une identité de session

Le service distant voit la session authentifiée de la passerelle et son adresse traduite, pas une authentification indépendante pour chaque appareil en aval. Gardez explicites les permissions par appareil et les identités applicatives, et confirmez avec le propriétaire du service qu'une passerelle agissant pour plusieurs appareils est bien autorisée. La traduction n'est pas un moyen de contourner une exigence d'enrôlement par appareil ; si le service exige que chaque appareil s'enrôle, utilisez ce modèle ou négociez un arrangement site à site.

Inscrivez cette confirmation dans le runbook à côté de la règle, car le prochain relecteur demandera si la conception a été approuvée ou simplement pratique.

Définissez l'état déconnecté, puis testez trois requêtes

Décidez de ce qui se passe lorsque le tunnel amont tombe. Le trafic distant autorisé ne doit pas suivre silencieusement un repli WAN ordinaire là où c'est interdit, donc la politique de pare-feu qui autorise le franchissement doit aussi échouer en mode fermé. Testez ensuite trois cas depuis un véritable appareil en aval : une requête autorisée qui fonctionne, une requête non autorisée qui échoue, et une panne amont qui arrête celle qui est autorisée.

Consignez le retour arrière sur une ligne par règle, afin que le changement puisse être annulé sans reconstruire l'intention.