Partagez une connexion VPN avec chaque appareil de votre LAN

Un ordinateur portable détient le tunnel, le reste de la maison veut le même accès, et la première tentative consiste à tout pointer vers la machine connectée. Cela échoue pour des raisons qui n’ont rien à voir avec le VPN : l’hôte récepteur doit transférer le paquet, réécrire sa source et s’assurer que les réponses trouvent le chemin du retour. Si l’un des trois manque, l’ordinateur connecté continue de fonctionner tandis que tous les autres appareils expirent. La solution est une conception de routage, pas un réglage du client.

Pourquoi pointer les appareils vers l’hôte échoue

Un hôte qui reçoit un paquet adressé à un réseau distant devient un routeur à cet instant, que quelqu’un l’ait configuré comme tel ou non. Le transfert est désactivé par défaut sous Linux et sous Windows, sauf si une fonctionnalité l’active. La traduction compte parce que le côté distant doit savoir où envoyer les réponses, et une adresse LAN privée ne signifie rien pour lui. La route de retour est la troisième pièce, et c’est celle que les gens oublient quand le premier ping semble réussir.

Diagnostiquez dans cet ordre au lieu de basculer des réglages au hasard. Chaque pièce manquante produit un symptôme légèrement différent.

Activez le transfert et la traduction sur l’hôte

Deux changements sur l’hôte connecté couvrent les deux premières pièces : activez le transfert IPv4 et traduisez le trafic LAN vers l’interface du tunnel.

sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A POSTROUTING -o tun0 -j MASQUERADE

Conservez la valeur sysctl dans un fichier sous /etc/sysctl.d, et revérifiez la règle MASQUERADE après un redémarrage, car les interfaces de pare-feu peuvent vider des chaînes personnalisées. Sous Windows, la fonction de partage effectue les deux étapes, mais elle réadresse aussi l’adaptateur LAN sur un sous-réseau fixe et efface sa passerelle, ce qui casse l’adressage statique et la redirection de port. Restaurez le chemin du routeur vers l’hôte à sa nouvelle adresse avant de conclure que le partage a échoué. Surveillez ensuite l’augmentation des compteurs de règles pendant qu’un deuxième appareil envoie du trafic.

Donnez au LAN un chemin qui survit aux redémarrages

Les autres appareils ont besoin d’une route vers le préfixe distant, et les deux façons de la fournir diffèrent par leur portée.

ip route add 10.8.0.0/24 via 192.168.1.20 dev eth0

Pointer la passerelle par défaut d’un client vers l’hôte envoie tout son trafic à travers l’hôte, y compris l’impression locale et le partage de fichiers, si bien que des choses sans rapport s’arrêtent quand l’hôte dort. Ajouter une route spécifique sur le routeur pour le préfixe distant est plus étroit : seules les destinations derrière le tunnel vont vers la machine connectée, et le reste du LAN continue de fonctionner. Les sous-réseaux ci-dessus sont des exemples, remplacez-les par vos propres plages LAN et tunnel. Dans tous les cas, testez depuis un deuxième appareil avec le tunnel actif puis inactif.

Surveillez la MTU avant de blâmer le tunnel

Les tunnels réduisent la taille utile des paquets, et le deuxième appareil n’en a aucune idée. Les gros transferts et les handshakes TLS se bloquent tandis que les petites requêtes réussissent.

ping -M do -s 1400 10.8.0.5

Une réponse prouve que cette taille traverse le chemin sans fragmentation ; un délai d’attente signifie que la surcharge d’encapsulation a poussé le paquet au-delà de la MTU du tunnel. Abaissez la MTU sur l’interface de partage ou limitez la taille maximale de segment sur le transfert, puis répétez la même sonde. Testez d’abord la même taille côté LAN, car un échec local pointe vers le LAN et non vers le tunnel. Notez la taille qui fonctionne, car un changement ultérieur de fournisseur ou de tunnel peut la déplacer.

Pour un seul appareil supplémentaire, le partage depuis l’hôte suffit. Pour un foyer, mettez la route sur le routeur. Quand l’accès doit survivre au départ de l’ordinateur avec vous, le tunnel lui-même appartient à une passerelle dédiée.