Un portable sous VPN a-t-il besoin du transfert IP pour aller plus vite ?
Le transfert fait passer les paquets entre interfaces ; il n’accélère pas un navigateur local. Séparez le rôle client du rôle de passerelle avant d’élargir une règle.
Transformer le portable en routeur est une façon populaire de résoudre le mauvais problème. Le transfert existe pour qu’une machine puisse transmettre des paquets dont la destination n’est pas elle-même, et il n’a pas d’avis sur la vitesse à laquelle un navigateur de cette même machine charge une page. Les deux chemins ne se ressemblent que parce que tous deux envoient le trafic dans un même tunnel. Séparez-les une fois, et une bonne partie des conseils sur l’activation du transfert ou l’ouverture du pare-feu se révèle décrire une topologie que vous n’avez pas.
Deux chemins de paquets qui semblent identiques depuis le bureau
Le navigateur du portable crée sa propre requête. L’hôte choisit la route du tunnel, le processus client encapsule le paquet et l’envoie au pair, et la réponse revient à l’application. Rien dans cette séquence ne traverse une décision de transfert, car cette machine est à la fois la source et la destination de la conversation.
Placez maintenant un autre appareil sur un segment Ethernet configuré exprès et faites du portable sa passerelle par défaut. Cet appareil émet la requête, le portable reçoit un paquet adressé ailleurs et le noyau doit décider s’il le transmet. C’est le rôle de transfert, et il arrive avec des prérequis que le rôle client n’a jamais eus : un chemin de transit autorisé, des routes des deux côtés et un chemin de retour qui fonctionne encore si la traduction fait partie de la conception.
| Role | Who originates the traffic | What has to be true |
|---|---|---|
| Client only | The laptop itself | Tunnel route, working resolver, supported profile |
| Gateway | Another device | Forwarding enabled, permitted transit, routes both ways, return-path decision |
Ce que ip_forward change réellement
La documentation du noyau sur IPv4 sysctl décrit ip_forward comme l’interrupteur qui permet à un hôte de transmettre des paquets entre interfaces. Ce n’est pas une voie rapide pour le trafic que l’hôte a lui-même généré, et aucune lecture de ce paramètre ne rend un navigateur local plus rapide. S’il change quelque chose, le transfert ajoute de l’état et de la politique à une machine qui faisait moins de travail auparavant.
La même documentation avertit que changer la valeur réinitialise d’autres paramètres IPv4 à leurs valeurs par défaut d’hôte ou de routeur. Cela fait de l’interrupteur un événement de configuration plutôt qu’une sonde : des réglages ajustés peuvent revenir sous vos pieds, et le changement peut être responsable d’une régression que personne ne penserait à lui attribuer. Cela signifie aussi que l’interrupteur doit être réglé une fois, délibérément, par celui qui possède le rôle de passerelle. Le basculer pendant une enquête sur une lenteur est le seul cas où l’effet secondaire est garanti d’être confondu avec le symptôme.
Trois questions de pare-feu qui ne sont pas la même question
Autoriser un écouteur VPN, autoriser les services que le portable exécute et autoriser le trafic à traverser le portable sont trois autorisations distinctes. La première laisse un pair atteindre un démon, la deuxième expose quelque chose de local, et la troisième transforme la machine en transit pour quelqu’un d’autre. Chacune a une portée différente, et la dernière est bien plus large que les réponses dont une application sortante ordinaire a besoin.
Quand un flux précis est bloqué, nommez sa source, sa destination, sa direction et le propriétaire de la politique avant de modifier une règle. Une règle étroite pour ce flux est une correction ; accepter tout sur l’interface du tunnel est un changement de politique qui inclut la correction par hasard. Un navigateur qui fonctionne ensuite prouve que le flux fonctionne, pas que la règle large était nécessaire.
Ne mesurez qu’une fois le chemin correct
Mesurez avec la même destination, la même charge et des conditions comparables, et changez une variable à la fois. Un test qui regroupe un changement de transfert, un élargissement du pare-feu et un réglage de chiffrement copié produit un nombre et aucune explication, car rien en lui ne dit laquelle des trois choses a déplacé le résultat.
Gardez les défaillances de route et de résolveur complètement hors de la conversation sur les performances. Un nom qui se résout lentement n’est pas un problème de débit, et un transfert qui bloque à une taille fixe est généralement une question de MTU et non une limite de vitesse. Notez laquelle de ces trois choses vous avez réellement observée avant de comparer des chiffres. Sinon, le lecteur suivant hérite d’une mesure qui mesure la mauvaise chose et d’un changement que personne ne peut justifier.
Décrivez la topologie que vous avez, pas l’étiquette sur le client
Un portable qui partage sa connexion, héberge un réseau de conteneurs routé ou porte le trafic d’une machine virtuelle est une passerelle, quel que soit le nom que le logiciel se donne. Le mot client décrit comment le tunnel est configuré, pas si des paquets sont transmis à quelqu’un d’autre.
Rendez le rôle explicite dans le manuel d’exploitation : ce qui émet le trafic, ce qui doit traverser la machine et laquelle des deux choses concerne la tâche en cours. Activez le rôle de passerelle lorsqu’il relève du forfait pris en charge, non comme un ajustement de vitesse inexpliqué appliqué à une topologie qui n’en a jamais eu besoin.