Certains d'entre nous n'utilisent pas Internet sans VPN pour diverses raisons : certains ont besoin d'une IP dédiée, et il est plus simple et moins coûteux d'acheter un VPS avec deux adresses IP plutôt que de les acheter auprès d'un fournisseur, d'autres souhaitent avoir accès à tous les sites Web, et non seulement à ceux autorisés sur le territoire russe, d'autres encore ont besoin d'IPv6, que leur fournisseur ne propose pas…
La plupart du temps, la connexion VPN est établie sur l'appareil utilisé à un moment donné, ce qui est tout à fait justifié si vous n'avez qu'un seul ordinateur et un seul téléphone, et que vous ne les utilisez que rarement en même temps. Cependant, si votre réseau domestique comporte de nombreux appareils ou, par exemple, s'il y en a sur lesquels le VPN ne peut pas être configuré, il serait plus pratique d'établir un tunnel directement sur le routeur domestique afin de ne pas avoir à configurer chaque appareil individuellement.
Si vous avez déjà configuré OpenVPN sur votre routeur, vous avez probablement été désagréablement surpris par sa vitesse de fonctionnement. Les SoC même des routeurs bon marché gèrent sans problème un trafic proche d'un gigabit, grâce à la délocalisation des fonctions de routage et de NAT sur une puce distincte spécialement conçue pour cette tâche, tandis que les processeurs principaux de ces routeurs sont relativement faibles, car ils n'ont pratiquement aucune charge. Ce compromis permet d'atteindre une haute vitesse de fonctionnement du routeur et de réduire considérablement le prix de l'appareil fini : les routeurs avec des processeurs puissants coûtent plusieurs fois plus cher et ne se positionnent plus seulement comme une boîte pour distribuer Internet, mais également comme NAS, téléchargeur torrent et système multimédia domestique.
Mon routeur, le TP-Link TL-WDR4300, ne peut pas être considéré comme nouveau — le modèle est apparu au milieu de 2012 et possède un processeur de 560 MHz de l'architecture MIPS32 74Kc, dont la puissance ne suffit que pour 20-23 Mo/s de trafic chiffré via OpenVPN, ce qui est relativement peu en termes de vitesse de l'Internet domestique moderne.
Comment pouvons-nous augmenter la vitesse du tunnel chiffré ? Mon routeur est assez fonctionnel, prend en charge 3×3 MIMO et fonctionne globalement bien, je préférerais ne pas le changer.
Avec la tendance actuelle de créer des pages Web de 10 Mo, d'écrire des applications de bureau en node.js et de les regrouper dans un fichier de 100 Mo, tout en augmentant la puissance de calcul au lieu d'optimiser, nous allons faire quelque chose de terrible : transférer la connexion VPN sur un « ordinateur » à carte unique performant, l'Orange Pi One, que nous allons installer dans le boîtier du routeur, sans occuper les ports réseau et USB existants, le tout pour seulement 9,99 $*!
* + frais d'expédition, + taxes, + pour la bière, + MicroSD.
OpenVPN
On ne peut pas dire que le processeur du routeur est complètement faible : il peut crypter et hacher des données avec l'algorithme AES-128-CBC-SHA1 à une vitesse de 50 Mo/s, ce qui est nettement plus rapide que le fonctionnement d'OpenVPN, tandis que le chiffrement courant CHACHA20 avec le hachage POLY1305 atteint même 130 mégabits par seconde ! Pourquoi la vitesse du tunnel VPN est-elle si basse ? Tout est dû au basculement de contexte entre l'espace utilisateur et l'espace noyau : OpenVPN crypte le trafic et communique avec le monde extérieur dans le contexte utilisateur, tandis que le routage lui-même se fait dans le contexte noyau. Le système d'exploitation doit constamment basculer d'un côté et de l'autre pour chaque paquet reçu ou transmis, et cette opération n'est pas rapide. Ce problème est commun à toutes les applications VPN fonctionnant via un driver TUN/TAP, et on ne peut pas dire que la faible vitesse soit causée par une mauvaise optimisation d'OpenVPN (bien qu'il y ait effectivement des points à retravailler). Aucun client VPN en espace utilisateur ne dépasse même un gigabit sans chiffrement sur mon ordinateur portable, sans parler des systèmes avec un processeur faible.
Orange Pi One
L'Orange Pi One de Xunlong est actuellement la meilleure offre en termes de rapport performance/prix. Pour 9,99 $, vous obtenez un bon processeur quad-core ARM Cortex-A7, fonctionnant à une fréquence stable de 1008 MHz, clairement plus performant que le Raspberry Pi Zero et le Next Thing C.H.I.P. dans cette gamme de prix. Cependant, les avantages s'arrêtent là. Xunlong ne prête aucune attention aux logiciels de ses cartes, et au moment du lancement de One, n'a même pas fourni de fichier de configuration, sans parler des images prêtes à l'emploi. Allwinner, le fabricant de SoC, ne prend pas non plus son produit au sérieux en matière de support. Leur préoccupation se limite à un fonctionnement minimum avec Android 4.4.4, ce qui signifie que nous devons utiliser un noyau de version 3.4 avec des patchs Android. Heureusement, des passionnés mettent en œuvre des distributions, corrigent le noyau, écrivent du code pour prendre en charge les cartes dans le noyau mainline, c'est-à-dire qu'ils effectuent en fait le travail du fabricant pour rendre cet appareil utilisable. Pour mes besoins, j'ai choisi la distribution Armbian, qui reçoit des mises à jour fréquentes et pratiques (deux nouveaux noyaux sont installés directement via le gestionnaire de paquets, au lieu de copier des fichiers sur une partition spéciale, comme c'est souvent le cas avec Allwinner), et qui prend également en charge la plupart des périphériques, contrairement aux autres.
Routeur
Pour éviter de surcharger le processeur faible du routeur avec le chiffrement et d'accélérer notre connexion VPN, nous pouvons transférer cette tâche à un processeur plus performant de l'Orange Pi, en le connectant au routeur d'une manière ou d'une autre. On pense à une connexion par Ethernet ou par USB — ces deux standards sont supportés par les deux appareils, mais il n'est pas souhaitable de prendre des ports déjà existants. Heureusement, il existe une solution.
La puce du hub USB GL850G, utilisée dans le routeur, prend en charge 4 ports USB, dont deux ne sont pas soudés. On ne sait pas pourquoi le fabricant n'a pas choisi de les souder, je suppose que c'est pour éviter aux utilisateurs de connecter quatre périphériques à forte consommation, comme des disques durs, car l'alimentation d'origine du routeur n'est pas prévue pour une telle charge. Dans tous les cas, cela nous est favorable.
Pour obtenir un autre port USB, il suffit de souder deux fils sur les broches 8(D-) et 9(D+) ou 11(D-) et 12(D+).
Cependant, il ne suffit pas de connecter simplement deux appareils USB et d'espérer que tout fonctionne tout seul, comme cela serait le cas avec Ethernet. Tout d'abord, nous devons faire fonctionner l'un d'eux en mode USB Client, et non USB Host. Ensuite, nous devons déterminer comment les appareils s'identifieront. Il existe de nombreux pilotes appelés USB Gadgets (du nom de la sous-système du noyau Linux) qui permettent d'émuler différents types d'appareils USB : adaptateur réseau, carte son, clavier et souris, clé USB, appareil photo, console via un port série. Comme notre appareil va fonctionner avec un réseau, l'émulation d'un adaptateur Ethernet nous conviendra le mieux.
Il existe trois standards Ethernet-over-USB :
- Remote NDIS (RNDIS). Un standard obsolète de Microsoft, principalement utilisé à l'époque de Windows XP.
- Ethernet Control Model (ECM). Un standard simple qui encapsule les trames Ethernet dans des paquets USB. Idéal pour les modems filaires avec connexion USB, où il est pratique de transmettre des trames sans traitement, mais en raison de sa simplicité et des limitations du bus USB, il ne fonctionne pas très rapidement.
- Ethernet Emulation Model (EEM). Un protocole plus intelligent qui prend en compte les limites de l'USB et agrège de manière optimale plusieurs trames en une seule, augmentant ainsi la bande passante.
- Network Control Model (NCM). Le protocole le plus récent. Il tire parti des avantages de l'EEM et optimise encore plus le fonctionnement avec le bus.
Pour faire fonctionner l'un de ces protocoles sur notre carte, comme toujours, il faudra faire face à certaines difficultés. Étant donné qu'Allwinner ne s'intéresse qu'aux parties Android du noyau, seul Android Gadget fonctionne correctement — ce code qui implémente la connexion avec adb, l'exportation de l'appareil via le protocole MTP et l'émulation de clé USB sur les appareils Android. Le propre Android Gadget prend également en charge le protocole RNDIS, mais dans le noyau Allwinner, il est cassé. Si vous essayez de compiler le noyau avec n'importe quel autre USB Gadget, l'appareil n'apparaîtra tout simplement pas dans le système, peu importe ce que vous ferez.
Pour résoudre le problème, il est nécessaire de trouver l'emplacement d'initialisation du contrôleur USB dans le code modifié de l'Android Gadget android.c, mais il existe aussi une solution de contournement pour faire fonctionner, au moins, l'émulation Ethernet via USB :
--- sun8i/drivers/usb/sunxi_usb/udc/sunxi_udc.c 2016-04-16 15:01:40.427088792 +0300
+++ sun8i/drivers/usb/sunxi_usb/udc/sunxi_udc.c 2016-04-16 15:01:45.339088792 +0300
@@ -57,7 +57,7 @@
static sunxi_udc_io_t g_sunxi_udc_io;
static u32 usb_connect = 0;
static u32 is_controller_alive = 0;
-static u8 is_udc_enable = 0;
+static u8 is_udc_enable = 1;
#ifdef CONFIG_USB_SUNXI_USB0_OTG
static struct platform_device *g_udc_pdev = NULL;Ce patch active de force le mode USB client, permettant d'utiliser des gadgets USB standard sous Linux.
Il faut maintenant reconstruire le noyau avec ce patch et le gadget nécessaire. J'ai choisi EEM, car d'après les tests, il s'est avéré plus performant que NCM.
L'équipe Armbian fournit pour toutes les cartes prises en charge dans la distribution. Il suffit de le télécharger, de placer notre patch dans userpatches/kernel/sun8i-default/otg.patch, d'éditer légèrement compile.sh et de choisir le gadget nécessaire :
Le noyau sera compilé en paquet deb, ce qui permettra de l'installer facilement sur la carte via dpkg.
Il ne reste plus qu'à connecter la carte par USB et à configurer notre nouvel adaptateur réseau pour obtenir une adresse via DHCP. Pour ce faire, il faut ajouter environ ce qui suit dans /etc/network/interfaces:
auto usb0
iface usb0 inet dhcp
hwaddress ether c2:46:98:49:3e:9d
pre-up /bin/sh -c 'echo 2 > /sys/bus/platform/devices/sunxi_usb_udc/otg_role'Il est préférable de définir l'adresse MAC manuellement, car elle sera aléatoire à chaque redémarrage de l'appareil, ce qui est peu pratique et ennuyeux.
Connectez le câble MicroUSB au port OTG, puis branchez l'alimentation du routeur (vous pouvez l'appliquer sur les broches 2 et 3 de la connectique, et pas seulement sur le connecteur d'alimentation).
Il reste à configurer le routeur. Il suffit d'installer le paquet avec le pilote EEM et d'ajouter notre nouvel appareil USB réseau au pont de la zone de pare-feu local :
opkg install kmod-usb-net-cdc-eem
Pour acheminer tout le trafic dans le tunnel VPN, il faut soit ajouter une règle SNAT pour l'adresse IP de la carte côté routeur, soit utiliser l'adresse de la carte comme adresse de passerelle via dnsmasq. Cela se fait en ajoutant la ligne suivante dans /etc/dnsmasq.conf:
dhcp-option = tag:lan, option:router, 192.168.1.100où 192.168.1.100 — L'adresse IP de votre carte. N'oubliez pas de spécifier l'adresse du routeur dans les paramètres réseau de la carte elle-même !
Pour isoler les contacts de la carte des contacts du routeur, une éponge en mélamine a été utilisée. Cela a donné quelque chose comme ça :
Conclusion
Le réseau fonctionne de manière étonnamment rapide via USB : 100-120 Mo/s, je m'attendais à moins. OpenVPN gère environ 70 Mo/s de trafic chiffré, ce qui n'est pas énorme, mais cela suffit pour mes besoins. Le couvercle du routeur ne ferme pas complètement, laissant un petit écart. Les esthètes peuvent retirer les ports Ethernet et USB Host de la carte, ce qui permettra au couvercle de se fermer complètement, laissant même de la place.
Il vaut mieux ne pas se lancer dans de telles pratiques et acheter .
Source : habr.com
