Labo maison et tunnel divisé : routez ce dont vous avez besoin, pas tout

Le conseil qu’un labo maison a besoin d’un tunnel complet vient généralement d’un tutoriel qui en avait un, pas d’une exigence. Le tunneling divisé n’est pas la version compromise d’un VPN correct ; c’est la version dont vous pouvez expliquer la table de routage. Un labo avec cinq services et une interface de gestion n’a pas besoin que chaque paquet qui quitte la maison traverse un tunnel. Ce dont il a besoin, c’est d’un inventaire et d’une route pour chaque élément de cet inventaire.

Le mythe : le tunneling divisé est un compromis

Le mythe survit parce qu’un tunnel complet est plus facile à configurer une fois et plus difficile à déboguer ensuite. Cet échange est raisonnable pour un portable en Wi-Fi public et faux pour une baie au sous-sol.

Il cache aussi une seconde supposition : l’adressage du labo n’a rien en commun avec le réseau depuis lequel vous vous connectez.

Inventoriez les ressources avant les routes

Notez chaque sous-réseau du labo, le service qui y vit, le nom par lequel vous le résolvez et qui est autorisé à l’atteindre ; les notes de redirection de votre passerelle décrivent le chemin de retour contre lequel vous planifiez. Ajoutez les plages de conteneurs et les plages de LAN que le client distant utilise peut-être déjà, car le chevauchement est la panne que cet inventaire évite. Une route qui couvre chaque adresse privée entrera en collision avec un réseau domestique tôt ou tard. L’inventaire est aussi le plan de test, c’est pourquoi il vaut la peine d’être fait avant la configuration et non après.

Attribuez à chaque ressource un chemin : par le tunnel, direct ou refusé. Une ressource sans chemin attribué est celle qui génère plus tard la question de support confuse.

Cinq lignes et une colonne de décisions valent mieux qu’une table de routage que personne ne peut lire.

La passerelle a besoin d’un chemin de retour

La redirection sur la passerelle n’est que la moitié. Le labo a besoin d’une route retour vers le pool de clients, ou d’un arrangement de traduction pris en charge qui rend le retour possible. Si les réponses ne trouvent pas le client, le tunnel paraît connecté et chaque requête expire ; c’est un symptôme de routage, pas une panne de VPN. Vérifiez le chemin de retour dans le cadre de la conception, pas comme une étape de dépannage.

Un pool de clients qui chevauche l’adressage propre au labo est l’autre moitié de ce problème, et il échoue exactement de la même manière.

Corrigez le plan, pas les symptômes, quand les deux plages se heurtent.

Les rôles de gestion et d’internet sont séparés

Décidez si seul le trafic du labo utilise le tunnel ou s’il devient aussi une sortie internet. N’ajoutez pas de route par défaut simplement parce qu’un tutoriel en a utilisé une, car cette décision change où vont chaque requête DNS et chaque vérification de mise à jour. Préservez un chemin extérieur vers le point de terminaison VPN lui-même, sinon le tunnel tentera de porter sa propre connexion extérieure. Gardez l’accès de gestion étroit et joignable par une méthode de récupération approuvée.

Un DNS privé peut être choisi pour les noms du labo sans supposer que chaque requête publique a besoin du même résolveur. C’est une décision de résolveur, pas une décision de route.

Les garder séparés est ce qui rend les modes de panne distinguables plus tard.

Testez depuis l’extérieur, pas depuis le LAN

Utilisez une connexion externe autorisée plutôt qu’un test depuis le même LAN, car un test depuis le même LAN peut masquer complètement une route de retour manquante. Vérifiez une adresse du labo, son nom d’hôte privé, une destination directe prévue et le comportement de panne requis. Le cas d’échec compte autant que le cas de succès : une ressource qui ne devrait pas être joignable doit vraiment être injoignable. Notez les quatre résultats avant de déclarer la conception terminée.

Ensuite, enregistrez la configuration des routes et du DNS à côté de l’inventaire, avec un propriétaire nommé. Quand le labo gagne un autre sous-réseau, mettez à jour les deux et retestez.

Une route inexpliquée qui chevauche un réseau domestique existant est le résultat par défaut de cette étape sautée.

La conception finie est petite, documentée et ennuyeuse, ce qui est exactement ce qu’un labo veut de son réseau. La version intéressante est celle qui casse pendant que vous êtes loin de chez vous.