VPN domestique pour amis : partagez la sortie, pas le LAN
Un VPN invité limité à internet et l'accès au LAN sont deux produits différents. Séparez les frontières du foyer, de l'hôte et du client, et testez aussi les refus.
Dire qu'un ami peut naviguer via votre connexion domestique n'est pas la même chose que dire qu'il peut utiliser votre réseau domestique, et l'écart entre ces deux phrases contient le NAS, les imprimantes, la page d'administration du routeur et tous les autres appareils du LAN. Chaque arrangement a besoin de ses propres règles de transfert. La plupart des incidents de VPN partagé dont j'entends parler ne sont pas des attaques exotiques ; c'est un invité qui a atteint quelque chose parce que personne n'a écrit quelle frontière était achetée. Décidez quel contrat vous offrez, puis exprimez-le dans la politique de transfert et d'accès plutôt que dans un message.
Deux contrats qui sonnent pareil
Internet uniquement signifie que le trafic du client invité sort par votre connexion et rien de plus. L'accès complet signifie que ce même client rejoint aussi votre réseau local, et ce second contrat inclut silencieusement le premier, et c'est ainsi que les gens y glissent. La différence se résume à une poignée de règles de transfert, et c'est aussi la différence entre partager une bande passante et partager une maison. Écrivez le contrat avant de toucher au pare-feu, car une règle ajoutée ensuite est plus facile à justifier qu'à retirer.
Choisissez le contrat internet uniquement, sauf si quelqu'un a vraiment besoin d'un service sur le LAN, car une règle que vous n'avez jamais écrite est une permission que vous n'avez jamais accordée. Vérifiez ensuite quel contrat le logiciel client met en œuvre, car un réglage par défaut en tunnel complet peut silencieusement livrer le plus large.
Frontière un : le réseau du foyer
Le trafic invité n'a rien à faire sur les réseaux du foyer. Un sous-réseau VPN séparé ou un segment d'hébergement dédié rend cette politique plus facile à exprimer, mais le nom différent n'impose rien en soi. Nommez l'appareil qui déplace réellement les paquets et gardez-y les règles de traversée, car une règle écrite sur une machine qui ne transfère pas est une décoration. Quand le VPN tourne sur le routeur, ce point d'application est la chaîne de transfert du routeur lui-même.
Un réseau invité avec isolation des clients est une alternative raisonnable, à condition que les clients VPN y atterrissent réellement. Les deux conceptions ont besoin du même test depuis un client plutôt que depuis la console.
Frontière deux : l'hôte et les autres invités
Les clients ont besoin du service VPN et de rien d'autre sur la machine qui l'exécute, donc l'accès de gestion reste une permission distincte. C'est celle qui est le plus souvent accordée par accident, car l'écouteur du tunnel et l'interface d'administration sont sur la même machine. Si le VPN se termine sur le routeur, le port du tunnel et l'interface web ou SSH sont des sujets différents et méritent des règles différentes. Une règle qui protège une page de connexion ne doit jamais être lue comme une interdiction de transférer.
L'accès à internet n'exige pas non plus de laisser un client invité atteindre un autre. Les pools d'accès distant se comportent souvent comme un segment partagé si vous ne dites pas le contraire, alors rendez la décision explicite dans la configuration du pool. Pour une poignée d'amis, l'isolation est la valeur par défaut qui vaut la peine d'être choisie.
Cartographiez les chemins avant d'écrire les règles
Un appareil autonome a deux ensembles distincts de paquets à surveiller : ceux qui se terminent sur lui et ceux qu'il relaie au nom d'un client. Les recommandations réseau de la CISA traitent les chemins entrants, sortants et inter-réseaux comme des accès qui demandent une justification, ce qui est le bon cadre ici. Listez les préfixes du foyer tels qu'ils sont réellement, IPv4 et IPv6 les deux, car un bloc limité à IPv4 laisse un foyer qui route aussi IPv6 grand ouvert à la même frontière. Décidez ensuite comment les clients obtiennent le DNS et si une exception de résolveur n'expose que le service prévu.
Ce sont des exigences plutôt qu'une recette universelle, car les règles dépendent de l'endroit où le VPN se termine et de l'endroit où la traduction a lieu. Évitez d'ajouter une autorisation large juste pour que la première requête du navigateur réussisse.
Ce que vous assumez, et comment le tester
Partager une sortie crée un rôle d'exploitation. Invitez les gens via le modèle d'identité du service, rendez le retrait praticable, maintenez l'hôte et le routeur et décidez quelle part de votre débit montant le service peut utiliser. Les requêtes partent de votre adresse, donc les plaintes et les problèmes de réputation arrivent à votre porte même si aucun appareil privé n'a été touché. Une conception technique d'isolation ne dit rien de la position juridique, et restreindre le trafic aux ports web courants ne rend pas toute activité autorisée inoffensive.
Testez ensuite les refus avec un client autorisé plutôt que depuis la console du routeur. Chacun de ces points doit tenir :
- L'accès à internet fonctionne depuis le tunnel invité.
- Le NAS et les imprimantes sont refusés par adresse et par nom.
- L'administration du routeur est refusée depuis l'adresse du tunnel.
- Un second client invité est injoignable.
- Retirer l'autorisation du client met réellement fin à l'accès.
Si le propriétaire ne peut pas maintenir ces frontières et les tâches d'exploitation, remettre un fichier de configuration sous-estime ce que l'arrangement lui demande. C'est la description honnête du service, et elle appartient au message qui accompagne la configuration.