Accès distant sécurisé

Le problème que je voulais résoudre

J'avais deux besoins d'accès distant bien distincts. D'un côté, atteindre les segments internes de mon lab FSEC, isolés derrière le NAT de VMware. De l'autre, piloter mon home lab réel — VMware Workstation, postes, VMs — depuis l'extérieur, en déplacement. Deux contextes différents, qui n'appellent pas la même solution.

Mon raisonnement

Plutôt que de forcer un seul outil partout, j'ai choisi le VPN adapté à chaque cas. Pour le lab FSEC, le tunnel devait être hébergé sur pfSense — le pare-feu est déjà le point de passage central, autant qu'il porte aussi le VPN : c'est OpenVPN. Pour le home lab, je voulais une solution légère, auto-hébergée de bout en bout, sans dépendre d'un service tiers de DNS dynamique : c'est WireGuard, sur une petite VM Debian dédiée. Dans les deux cas, la règle est la même : un accès chiffré, par certificat ou par clé, jamais un simple mot de passe partagé.

Volet 1 — OpenVPN pour le lab FSEC

Le NAT de VMware isole le réseau interne par conception : la passerelle NAT ne route pas vers les segments du lab, et des routes statiques ne suffisent pas. Le tunnel OpenVPN hébergé sur pfSense est la solution propre pour contourner cette isolation sans l'affaiblir.

• Une autorité de certification dédiée au VPN créée sur pfSense, et un certificat serveur signé par cette autorité.
• Le serveur OpenVPN configuré en UDP/1194 sur l'interface WAN, avec authentification TLS et un pool d'adresses 10.0.0.0/24 pour les clients connectés.
• Un certificat par utilisateur — l'accès n'est pas un mot de passe partagé.
• Le tunnel ne pousse que les routes vers les cinq segments internes du lab, pas vers tout Internet (split tunnel) : la navigation web locale du client reste directe.
• La résolution DNS interne (fsec.lan, via le DNS de l'AD) est poussée aux clients connectés.

Une fois le profil client importé et le tunnel établi, la machine reçoit une IP du pool VPN et peut joindre les passerelles internes des pare-feux et ouvrir des sessions SSH vers les machines des différents segments — ce qui était impossible sans le tunnel.

Volet 2 — WireGuard + RDP pour le home lab réel

Pour accéder à mon home lab depuis l'extérieur, j'ai monté un tunnel WireGuard sur une VM Debian minimale dédiée, qui sert de passerelle vers le LAN de la maison. WireGuard a été retenu pour sa surface d'attaque minimale et sa simplicité — un point clé pour un lab orienté sécurité.

• Une VM Debian « wireguard-gw » en réseau ponté (bridge) sur le LAN, avec une IP fixe réservée dans la box, et le routage IP activé pour qu'elle fasse passerelle.
• Une paire de clés par appareil — jamais de clé partagée — et un pair déclaré côté serveur pour chaque client.
• Une règle NAT/PAT sur la box redirigeant le port UDP WireGuard vers la VM ; la sécurité est assurée par WireGuard lui-même, qui ne répond rien sans clé valide — le service est invisible aux scans.
• Un sous-domaine dédié (vpn.pandack.fr, géré chez LWS) plutôt qu'un service tiers de DNS dynamique : approche auto-hébergée de bout en bout.
• Choix d'un split tunnel : seul le trafic vers le LAN maison passe par le VPN, la navigation locale reste directe.
• Une fois le tunnel établi, accès RDP au poste principal et SSH aux VMs — ce qui permet de piloter VMware Workstation à distance.

Les pièges rencontrés — et comment je les ai réglés

Ce projet m'a surtout appris à diagnostiquer. Quelques exemples concrets :

• Vérifier qu'on n'est pas en CGNAT avant tout : sans IP publique routable, aucune redirection de port n'est possible. La vraie IP publique se lit avec curl ifconfig.me, pas avec dig — qui peut renvoyer l'IP du résolveur DNS du fournisseur.
• Sur Debian minimale, iptables n'est pas installé par défaut (la distribution utilise nftables) : sans lui, le service WireGuard échoue au démarrage. Diagnostic puis installation du paquet manquant.
• L'accès RDP refusé sur un Windows 11 avec compte Microsoft et Windows Hello : pas de mot de passe utilisable pour RDP. Résolu en créant un compte local dédié à l'accès distant.
• La box ne faisant pas de NAT loopback, le test de connexion doit obligatoirement se faire depuis l'extérieur du LAN — sinon on croit à tort que ça ne fonctionne pas.

Comment j'ai validé

Côté OpenVPN : profil client importé, tunnel établi, IP du pool VPN reçue, et accès SSH effectif aux machines des segments internes du lab. Côté WireGuard : wg show affiche le handshake quelques secondes après l'activation du client, tcpdump sur la VM confirme l'arrivée des paquets, et l'accès RDP au poste principal fonctionne depuis l'extérieur — premier handshake réussi testé via un partage de connexion mobile.