Pourquoi une ressource VPN fonctionne et une autre expire

Un service privé se charge par le tunnel et le suivant expire, et la tentation est de reconstruire tout le profil du client. Le service qui fonctionne est plus utile comme contrôle que comme raison de repartir de zéro. Il prouve qu’une destination, un port et un chemin d’autorisation ont été satisfaits, et rien de plus.

Deux services sur la même passerelle peuvent être atteints par des familles d’adresses, des sous-réseaux et des politiques différents.

Séparez le flux qui fonctionne de celui qui échoue

Traitez chaque service comme son propre flux, et non comme un symptôme du VPN. Un client illustratif peut ouvrir portal.corp.example à 172.20.4.15:443 et pourtant ne pas atteindre une base de données à 172.20.9.40:5432, car ce sont deux destinations avec deux jeux de règles. Notez les deux lignes avant de changer quoi que ce soit, y compris le port et le protocole, car une règle qui autorise TCP 443 sur un hôte ne dit rien sur TCP 5432 sur le même hôte.

La ligne qui échoue est celle à examiner. La ligne qui fonctionne indique seulement où se situe la base de référence, et elle sera le point de comparaison après chaque changement.

Comparez les adresses avant de comparer les noms

Résolvez chaque nom complet par la politique que l’application utilise réellement, puis notez la famille d’adresses qu’elle a choisie. Un nom peut renvoyer une adresse IPv6 tandis qu’un autre renvoie IPv4, et une ancienne réponse en cache peut envoyer une requête vers une adresse publique qui n’a rien à voir avec le service privé.

ip route get 172.20.4.15
ip route get 172.20.9.40
ip -6 route get 2001:db8:60::20

La recherche répond à une question étroite : quelle route cet hôte choisirait-il pour cette destination, avec les tables et les règles de politique actuelles. Une route pour 172.20.4.0/24 ne couvre pas 172.20.9.0/24, et un second gestionnaire de réseau ou une route locale plus spécifique peut discrètement supplanter le tunnel. Répétez la recherche à l’intérieur de l’espace de noms ou avec la marque que l’application utilise lorsqu’elles diffèrent de votre shell. Notez aussi l’interface par laquelle le paquet sort, car la table de routage peut nommer une interface tandis que le routage par politique envoie le flux par une autre.

Une route qui correspond est une condition nécessaire, pas une autorisation. Elle indique que le paquet a où aller et rien sur le fait qu’un pare-feu, un service d’autorisation ou l’hôte lui-même l’acceptera.

Le protocole et l’étape de réponse disent où cela s’arrête

Une réponse ping ne prouve pas qu’un port de base de données est ouvert, et une page HTTPS réussie n’autorise pas un partage de fichiers sur la même machine. Notez ce qui est réellement revenu plutôt que d’aplatir chaque échec dans une seule catégorie. Un délai d’attente, une réinitialisation, une erreur d’identité TLS et un rejet au niveau applicatif pointent chacun vers une couche différente.

La distinction compte parce que les corrections divergent. Le silence signifie généralement un problème de route, de pare-feu ou de traduction sur le chemin. Une réinitialisation immédiate suggère que quelque chose a atteint l’hôte et a refusé le port. Une erreur de certificat signifie que la connexion est arrivée et que le nom ne correspondait pas, ce qui est un problème de configuration et non d’accessibilité. Un refus applicatif signifie que le réseau a fait son travail et que l’identité a été rejetée ensuite.

Lorsqu’une ressource est publiée via une passerelle, comparez l’adresse source que la destination voit avec la source que votre client croit utiliser. Une requête émise par la passerelle elle-même peut réussir alors que la même requête depuis un client échoue, car les deux arrivent d’adresses différentes et rencontrent des règles différentes.

Changez une variable et relancez les deux requêtes

L’identité est le dernier endroit où les gens regardent et le premier où un refus correct apparaît. La connexion VPN, le groupe d’annuaire et le compte applicatif sont trois identités distinctes qui peuvent diverger. L’accès à un portail n’implique jamais l’accès à la base de données derrière lui, et un nom dans un annuaire ne crée pas de ligne dans un autre. Si le service se situe hors du périmètre prévu de l’utilisateur, le refus est le système qui fonctionne.

Demandez au propriétaire de la ressource de confirmer le droit prévu au lieu d’ajouter une route large ou d’ouvrir un groupe à titre de test. Élargir le réseau pour prouver un point est la façon dont un diagnostic temporaire devient une exposition permanente, et cela détruit le contrôle avec lequel vous avez commencé. Un écart démontré par itération suffit : une route manquante, une mauvaise famille d’adresses, un port bloqué ou une appartenance à un groupe manquante.

Après chaque changement, répétez les deux requêtes et gardez les sorties côte à côte. L’enquête se termine lorsque le service qui échouait fonctionne selon sa propre politique, tandis que le service qui fonctionne et les refus que vous attendez encore se comportent exactement comme avant.