Bastion SSH ou accès VPN direct : quelle politique s’applique ?

Savoir si les utilisateurs VPN peuvent joindre des serveurs sans passer par un hôte de rebond est une question de politique déguisée en réseau. Si le bastion exerce un contrôle obligatoire, alors rejoindre le VPN doit y mener et non le contourner. Si l’hôte de rebond ne faisait que relier un segment auparavant inaccessible, un chemin direct étroit peut être le remplacement honnête. Faites les vérifications ci-dessous dans l’ordre et arrêtez-vous à la première qui échoue, car cette réponse décide du reste.

Vérifiez ce que le bastion contrôle réellement

Commencez par des preuves sur le présent, pas par un schéma du document de conception. Regardez la configuration SSH et le filtre de paquets de la cible : si le port 22 entrant n’est accepté que depuis l’adresse du bastion, l’hôte de rebond est un contrôle imposé. Si le même port accepte des connexions de tout le pool VPN, le bastion était une commodité et l’application vit tout ailleurs. L’historique des tickets confirme en général lequel des deux a existé en premier.

Énoncez la conclusion en une phrase nommant le contrôle que fournit le bastion : restriction de destination, seconde étape d’authentification, enregistrement de session ou visibilité opérationnelle pendant un incident. Cette phrase est ce que la politique de remplacement doit préserver.

Vérifiez si la cible peut distinguer les chemins

Les règles d’adresse source ne fonctionnent que tant que les deux chemins arrivent avec des adresses source différentes. Une passerelle VPN qui masque le trafic vers le sous-réseau des serveurs efface cette différence, et chaque connexion au port 22 semble alors venir de la passerelle. La vérification est locale à la cible et prend un instant : listez les sessions SSH établies et lisez l’adresse du pair pour chacune.

Quand les deux chemins se réduisent à une seule adresse, la distinction doit être faite plus tôt, par les destinations que le VPN est autorisé à pousser et par les filtres propres à la passerelle. Ajouter une règle sur la cible dans cette situation crée l’illusion d’une frontière sans changer ce qui arrive.

Vérifiez ce que chaque enregistrement contient vraiment

Trois journaux différents décrivent trois événements différents, et aucun ne remplace l’autre. L’enregistrement de connexion du VPN montre qu’une identité est entrée dans le périmètre réseau. L’enregistrement de transfert du bastion montre un canal TCP qui le quitte vers une destination et un port. Le journal d’authentification de la cible montre qu’un compte s’est connecté via SSH. C’est les lire ensemble qui produit une chronologie ; en lire un seul produit une conjecture.

Aucun de ces enregistrements ne contient ce qui s’est passé à l’intérieur de la session chiffrée entre le client et la cible. Si une revue au niveau des commandes est exigée, elle demande un mécanisme d’enregistrement déployé volontairement, avec ses propres règles de traitement des données. L’attendre des journaux de l’hôte de rebond, c’est ainsi qu’une lacune d’audit reste cachée jusqu’au moment où elle compte.

Vérifiez où la politique est réellement appliquée

Un réglage client comme ProxyJump est une demande, non une restriction. OpenSSH ouvrira volontiers une connexion directe quand la destination est joignable, donc les fichiers de configuration des portables décrivent l’intention tandis que les pare-feu décident du résultat. L’application relève des destinations autorisées de la passerelle VPN et des règles d’accès propres à la cible, et l’utilisateur ne peut modifier ni l’une ni l’autre. Auditez en même temps les chemins alternatifs : une seconde interface, un écouteur public, une couche mesh ou un ancien tunnel intersite peuvent chacun rétablir le raccourci que vous venez de fermer.

Configurez tout de même ProxyJump, car cela rend la route approuvée la plus simple et empêche le travail courant de générer des exceptions. Confirmez ce que le client résout réellement avant de lui faire confiance.

ssh -G app01.lab.internal | grep -iE '^(hostname|port|proxyjump|proxycommand)'

Vérifiez par une tentative directe délibérée

Une politique jamais testée est un espoir. Depuis un client attaché au VPN, tentez le chemin qui devrait désormais être refusé, puis tentez celui qui est approuvé, et conservez les deux résultats. La tentative refusée est la preuve que le changement a pris effet.

nc -vz -w 3 10.20.30.41 22
ssh -J bastion.lab.internal app01.lab.internal true

Un résultat propre ressemble à une connexion directe refusée ou expirée vers l’adresse de la cible, suivie d’une connexion réussie à l’hôte de rebond et d’une entrée d’authentification côté cible nommant la source prise en charge. Tout le reste signifie que la frontière reste poreuse, quoi qu’en dise la documentation. Notez la date, la règle modifiée et les deux issues, puis donnez au chemin de secours un responsable et une date d’expiration afin que l’accès d’urgence ne devienne pas discrètement la route quotidienne.