Atteindre un appareil de la maison via un VPN d’accès distant : cinq portes

Un VPN commercial de sortie internet masque votre adresse ; il ne vous connecte pas à votre propre maison. Atteindre le NAS ou l’imprimante d’un réseau domestique exige une passerelle située sur ce réseau et un client qui construit un tunnel vers elle. Le paquet doit ensuite passer cinq contrôles, et n’importe lequel qui échoue se voit de la même façon de l’extérieur.

Porte 1 : le client doit sélectionner le tunnel

Vérifiez que le préfixe de destination est réellement routé dans le tunnel sur le client. Un profil de tunnel divisé qui ne pousse que le sous-réseau propre du VPN enverra 192.168.x.x directement par l’interface locale, où il n’arrive nulle part. Regardez la table de routage du client, pas le nom du profil.

C’est l’échec le plus courant avec les clients téléphoniques, qui souvent par défaut n’envoient que le DNS ou qu’un seul préfixe. Si la route manque, la poignée de main peut être parfaite et l’appareil rester injoignable.

Confirmez que l’adresse du pool du client et le sous-réseau domestique ne se chevauchent pas avant de continuer.

Porte 2 : la passerelle doit transférer

Le VPN se termine sur un hôte qui doit transférer le paquet déchiffré vers le LAN. Cela exige le transfert IP activé et une politique de pare-feu autorisant le flux de l’interface VPN vers l’interface LAN. Sur une appliance routeur, c’est généralement intégré ; sur une machine Linux avec strongSwan ou WireGuard, ce sont deux réglages que les gens oublient. Vérifiez les deux avant de tester le service, car chacun seul produit le même délai d’attente.

Testez avec une capture sur l’interface LAN, car un paquet qui n’y apparaît jamais a été rejeté ou n’a jamais été transféré.

C’est un échec différent de celui d’un service qui refuse la connexion, et cette distinction fait gagner beaucoup de temps. Gardez l’autorisation étroite, limitée au service et au pool VPN plutôt qu’à tout le sous-réseau.

Porte 3 : le chemin de retour décide de tout

La cible répond à l’adresse source qu’elle a vue, qui est soit l’adresse du pool du client, soit la passerelle, selon que vous traduisez ou non. Si la passerelle par défaut de la cible est le routeur domestique et que ce routeur n’a aucune route vers le pool VPN, la réponse sort par internet et meurt. C’est la classique connexion unidirectionnelle.

Deux correctifs légitimes existent : ajouter une route pour le pool sur la passerelle LAN, ou faire du source-NAT sur la passerelle VPN pour que la cible ne voie jamais que l’adresse de la passerelle. Le second est plus simple et perd l’identité d’origine de la source.

Choisissez-en un délibérément et notez lequel, car les règles de pare-feu et les journaux en dépendent. Le guide de transfert strongSwan parcourt le côté Linux de cette décision.

Porte 4 : noms et chevauchement de préfixes

Les noms de découverte locaux ne franchissent pas une frontière routée, donc un appareil qui apparaît sous un nom convivial dans la maison peut être invisible par le tunnel. Fournissez du DNS pour la zone privée, ou documentez l’adresse. Quel que soit le nom utilisé, il doit se résoudre en quelque chose que le client distant peut router. Voilà pourquoi un appareil peut être joignable par adresse et invisible par nom en même temps.

Les préfixes qui se chevauchent sont l’autre piège : si le pool du client est 192.168.1.0/24 et le réseau domestique aussi, le client traite la destination comme locale et ne l’envoie jamais par le tunnel.

Renumérotez un côté, ou utilisez un pool d’une plage que vous ne rencontrerez jamais chez vous.

Porte 5 : testez depuis l’extérieur de la maison

Un test depuis la cuisine ne prouve rien, car le trafic peut ne jamais quitter le LAN. Connectez-vous depuis un point d’accès mobile ou un autre réseau, puis parcourez les portes dans l’ordre : route sur le client, capture sur l’interface LAN, réponse du service, capture de la réponse et résolution de noms. La première porte qui ne produit aucune preuve est là où se trouve le travail.

Si le service répond mais pas le nom, vous avez un problème DNS plutôt qu’un problème de tunnel.

Conservez la configuration qui fonctionne dans une note avec le pool, la route et le choix NAT, car le prochain remplacement de routeur réinitialisera les trois.