Un client VPN sur votre serveur web casse-t-il ses réponses ?

Le site se charge depuis un portable sur le même réseau et expire depuis partout ailleurs, et l'hôte exécute aussi un client VPN pour son propre trafic sortant. Cette combinaison produit une défaillance précise : la connexion entrante arrive, la réponse part par le mauvais chemin, et le client à l'extérieur ne voit jamais de réponse. Les deux moitiés apparaissent dans la même capture de paquets, donc l'ordre des événements est la partie qui vaut la lecture.

Une règle de routage basée sur la source corrige souvent le symptôme. Elle exempte aussi généralement plus de trafic que le site qui l'a motivée, et c'est la partie qui vaut la peine d'être comprise avant d'enregistrer la règle.

Le symptôme : il répond localement et pas de l'extérieur

À l'intérieur du réseau, la réponse n'a pas besoin de traverser le tunnel, donc la page se charge et le service semble sain. De l'extérieur, la requête atteint l'hôte et la réponse est routée dans le VPN, où l'extrémité distante n'a aucune raison de l'accepter. Le navigateur voit un délai d'attente plutôt qu'un refus, ce qui est la signature d'un chemin à sens unique et non d'un port fermé.

Confirmez la forme avant de changer le routage : l'écouteur est actif, la requête locale réussit et la requête externe ne produit aucune réponse. Ces trois observations pointent ensemble vers le chemin de retour et non vers la configuration du serveur web. Une asymétrie aussi nette est plus utile que n'importe quelle ligne de journal, car elle écarte l'écouteur avant même que vous lisiez un seul message d'erreur.

Gardez un chemin d'administration indépendant ouvert pendant que vous travaillez. Une règle qui casse votre propre session SSH transforme une correction de dix minutes en visite physique.

Ce qu'un sélecteur de source fait réellement correspondre

Dans le routage par politique de Linux, une règle comme from 192.168.50.2 fait correspondre les paquets dont la source est cette adresse. Elle ne code pas le fait que le paquet poursuit une conversation entrée par le routeur domestique, et elle ne sait pas quel processus l'a créé. L'adresse de cet exemple est illustrative ; remplacez-la par l'adresse que votre hôte utilise réellement. Traitez la ligne comme une affirmation sur des adresses et rien de plus.

Si la table sélectionnée fournit une route par défaut ordinaire, chaque paquet portant cette source peut prendre la même exception. Un autre service lié à la même adresse en hérite, et une application qui se lie délibérément à cette adresse en hérite aussi. La référence des règles de politique énumère source, destination, protocole, port, marque et priorité comme des sélecteurs distincts, ce qui rappelle que la source seule est le plus grossier disponible.

La priorité décide du résultat. Les recherches s'exécutent dans l'ordre et la première table qui produit un résultat peut terminer la recherche, donc une règle placée trop tôt peut masquer une route plus spécifique qu'une table ultérieure aurait fournie. Lisez toute la liste ordonnée plutôt que la seule ligne que vous avez ajoutée. Une règle qui ne correspond jamais ne coûte rien, tandis qu'une règle qui correspond trop tôt modifie silencieusement tout ce qui se trouve derrière.

Vérifiez le chemin de retour et le trafic que vous n'aviez pas prévu

Lisez les règles et les tables, puis demandez au noyau quel chemin prendrait une paire source-destination donnée. Tester depuis l'hôte lui-même n'est pas la même chose que tester depuis l'extérieur, alors faites les deux.

ip rule show
ip route show table 100
ip route get 203.0.113.44 from 192.168.50.2
ss -ltnp '( sport = :443 )'

Acceptez ensuite une nouvelle connexion externe et, séparément, une requête qui doit encore sortir par le VPN. Si la seconde sort maintenant directement, l'exception est plus large que le problème que vous résolviez, et le test qui compte est celui que vous ne comptiez pas modifier.

Une vérification d'adresse publique dans un navigateur ne rapporte que les requêtes que ce navigateur a effectuées. Elle ne dit rien des réponses du serveur web, de la sélection de source d'une autre application locale, ni de ce qui arrive au trafic de gestion après la prochaine reconnexion VPN.

Décidez à quel point l'exception peut être étroite

Deux conceptions sont défendables et doivent être choisies délibérément. Si l'hôte existe pour publier ce service et que son trafic sortant n'a pas d'importance, une adresse locale dédiée avec une politique réservée au WAN est un arrangement raisonnable à condition d'accepter toute la portée. Si seules certaines connexions entrantes doivent être éligibles, la sélection d'adresse est trop grossière et une conception consciente des connexions doit la précéder.

Notez le contrat sur lequel vous vous appuyez : le mappage public, l'adresse de l'hôte à laquelle la requête est livrée et le chemin que la réponse est censée prendre. Un service entrant publié via un fournisseur VPN est un contrat différent de celui publié via un routeur domestique, et une exception copiée d'un exemple est souvent fausse pour l'autre.

Persistez la politique dans le composant qui possède le routage au lieu de coller une commande dans un fichier de démarrage. L'ordre des règles, le nettoyage après un changement de réseau et la relecture après un redémarrage doivent tous survivre, et un fichier de démarrage non testé échoue généralement au moment où vous ne regardez pas. Terminez par le résultat d'acceptation que vous pouvez défendre : un site publié rétabli et un flux sans rapport inchangé.