Hyperviseur du labo domestique injoignable via VPN : où chercher

Le tunnel monte, la page web de l’hyperviseur expire et le client dit qu’il est connecté. Cette combinaison exclut beaucoup de choses : la poignée de main VPN fonctionne, le client a une adresse et le point de terminaison est joignable. Ce qui reste est une courte liste de questions de routage et de politique, et elles ont un ordre naturel. Traitez-les de l’hyperviseur vers l’extérieur plutôt que du client vers l’intérieur, car l’état de l’hyperviseur lui-même est ce qu’il y a de moins coûteux à confirmer.

Commencez par le segment d’administration

Confirmez l’adresse d’administration de l’hyperviseur et le service qui y écoute, et confirmez que la page se charge depuis un autre hôte de ce segment avant de diagnostiquer quoi que ce soit à distance. Un test local qui échoue n’est pas un problème VPN, et c’est une vérification de cinq minutes qui en fait gagner une.

Puis les deux chemins. Le client VPN a besoin d’une route vers le réseau d’administration, ce qui signifie généralement que les AllowedIPs du client ou les routes poussées incluent ce sous-réseau. L’hyperviseur, ou sa passerelle par défaut, a besoin d’un chemin de retour vers le pool d’adresses des clients, sauf si la conception traduit délibérément la source à l’entrée. Ce sont deux faits distincts et l’absence de l’un ou de l’autre produit le même délai d’expiration. Vérifiez-les séparément : ip route get 192.168.10.20 sur le client, et une capture sur l’hôte hyperviseur montrant si le paquet est arrivé ou non.

Autorisez le véritable administrateur distant

L’autorisation est une question distincte de la joignabilité. Utilisez une politique de passerelle et d’hôte limitée aux sources et aux services qui ont besoin d’un accès d’administration. Un compte VPN invité qui a besoin d’une application du labo ne devrait pas pour autant atteindre le plan d’administration, et une règle plate qui admet tout le sous-réseau du tunnel est la façon dont cela arrive.

Laissez activées l’authentification propre de l’hyperviseur et les vérifications de certificat. Une route privée n’est pas une raison de cliquer à travers un avertissement d’identité inattendu.

L’avertissement mérite d’être traité comme une constatation et non comme un obstacle. Si le certificat ne correspond pas au nom que vous avez utilisé, soit le nom est faux, soit le service n’est pas celui que vous croyez, et les deux réponses comptent plus sur une interface d’administration que partout ailleurs. Atteignez la page par le nom pour lequel le certificat a été émis, et laissez le DNS pointer ce nom vers l’adresse du tunnel. Un nom privé qui se résout de façon incohérente entre le LAN et le tunnel est une cause fréquente de plaintes de certificat qui ressemblent à des pannes VPN.

Vérifiez les connexions secondaires

Certaines fonctions utilisent des connexions que la page web n’utilise pas. Une session de console, un envoi d’ISO, un proxy VNC ou SPICE et un canal de migration peuvent chacun utiliser un port différent ou une adresse d’hôte différente. Quand la page se charge et qu’une fonction échoue, lisez l’exigence de ce produit au lieu d’ouvrir tous les ports de l’hôte.

Tout ouvrir est la façon dont une interface d’administration devient non administrée. Chaque port supplémentaire est un écouteur de plus à maintenir à jour, et un hyperviseur en expose déjà assez. Identifiez la connexion précise dont la fonction a besoin, confirmez qu’elle est joignable par le tunnel, et laissez le reste fermé. Si la fonction insiste sur une connexion directe à une adresse d’hôte qui n’est pas routable par votre tunnel, c’est une contrainte de conception à contourner délibérément, pas une raison de transférer une plage.

Gardez un chemin de retour avant de toucher au réseau

Avant de modifier le réseau virtuel qui porte votre propre VPN, confirmez que vous disposez d’un chemin de retour local ou indépendant.

Cela compte surtout dans un labo domestique, car le point de terminaison VPN est souvent une machine virtuelle sur l’hyperviseur même que vous cherchez à atteindre. Modifier un commutateur virtuel, un pont ou une règle de pare-feu à distance peut supprimer le chemin que vous utilisez, et la session peut survivre assez longtemps pour le voir se produire.

Testez depuis l’extérieur du labo plutôt que depuis le LAN, et vérifiez les refus autant que les autorisations. Un réseau qui doit rester injoignable depuis le tunnel doit le rester après votre changement, et c’est une affirmation distincte du chargement de la page d’administration. Notez les deux résultats, car le second est celui qui est omis et celui qui compte quand le labo grandit.

La fiche à conserver est courte : l’adresse et le service d’administration, la route dont chaque côté a besoin, les identités autorisées à l’atteindre et le chemin de récupération. Cela suffit à la personne suivante pour reproduire l’état fonctionnel sans le redériver.

Si la page expire encore après tout cela, capturez sur l’hyperviseur et cherchez le paquet avant de changer une autre règle. Un paquet qui n’arrive jamais est une question de routage ou de pare-feu ; un paquet qui arrive et est refusé est une question de service ou de politique ; un paquet qui arrive et reçoit une réponse pendant que le client attend est une question de chemin de retour. La documentation de strongSwan sur le transfert explique comment une passerelle Linux transfère le trafic du tunnel vers un hôte interne. Trois captures valent mieux qu’une supposition de plus.