Alcuni di noi non utilizzano Internet senza un VPN per vari motivi: alcuni hanno bisogno di un IP dedicato, ed è più semplice ed economico acquistare un VPS con due IP piuttosto che acquistare un indirizzo dal provider; qualcuno vuole accedere a tutti i siti web, non solo a quelli autorizzati in Russia; altri ancora hanno bisogno di IPv6, ma il provider non lo fornisce…
La maggior parte delle volte, la connessione VPN viene stabilita direttamente sul dispositivo utilizzato in quel momento, il che ha senso se si dispone di un solo computer e un solo telefono, e li si utilizza raramente contemporaneamente. Tuttavia, se nella tua rete domestica ci sono molti dispositivi, o se ci sono dispositivi su cui non è possibile configurare una VPN, sarebbe più comodo instaurare un tunnel direttamente sul router di casa, in modo da non doversi preoccupare di configurare ogni dispositivo singolarmente.
Se hai mai installato OpenVPN sul tuo router, probabilmente sei rimasto sconcertato dalla velocità con cui funziona. I SoC anche dei router economici gestiscono senza problemi il traffico vicino al gigabit, trasferendo le funzioni di routing e NAT su un chip separato concepito esclusivamente per questo compito; i processori principali di questi router sono piuttosto deboli, poiché non hanno carichi praticamente nulli. Questo compromesso consente di raggiungere alte velocità di funzionamento del router e di ridurre significativamente il costo del dispositivo finito: i router con processori potenti costano molte volte di più e sono posizionati non solo come semplici scatole per distribuire Internet, ma anche come NAS, torrent downloader e sistemi multimediali domestici.
Il mio router, TP-Link TL-WDR4300, non può essere definito nuovo: il modello è apparso a metà del 2012 e dispone di un processore MIPS32 74Kc a 560 MHz, la cui potenza è sufficiente solo per 20-23 Mb/s di traffico criptato tramite OpenVPN, che è davvero poco rispetto agli standard di velocità della moderna connessione Internet domestica.
Come possiamo aumentare la velocità del tunnel criptato? Il mio router è piuttosto funzionale, supporta 3×3 MIMO e in generale funziona bene, non vorrei cambiarlo.
Poiché ora è comune creare pagine web di 10 megabyte, sviluppare applicazioni desktop in node.js e confezionarle in file da 100 megabyte, e aumentare la potenza computazionale anziché ottimizzare, commetteremo qualcosa di terribile: trasferiremo la connessione VPN su un "computer" monocircuito performante Orange Pi One, che installeremo all'interno del case del router, senza occupare le porte di rete e USB esistenti, il tutto per soli $9.99*!
* + spedizione, + tasse, + per la birra, + MicroSD.
OpenVPN
Non si può dire che il processore del router sia del tutto debole: è in grado di crittografare e fare hashing dei dati con l'algoritmo AES-128-CBC-SHA1 a una velocità di 50 Mb/s, notevolmente più veloce di come funziona OpenVPN, mentre il moderno cifrario a flusso CHACHA20 con hash POLY1305 raggiunge addirittura 130 megabit al secondo! Perché però la velocità del tunnel VPN è così bassa? Tutto si riduce allo switching di contesto tra lo spazio utente e lo spazio kernel: OpenVPN crittografa il traffico e comunica con il mondo esterno nello spazio utente, mentre nel contesto del kernel avviene il routing vero e proprio. Al sistema operativo tocca continuamente cambiare da uno spazio all'altro per ogni pacchetto ricevuto o trasmesso, e questa operazione non è veloce. Questo problema è comune a tutte le applicazioni VPN che funzionano tramite driver TUN/TAP, e non si può dire che la bassa velocità sia causata da una cattiva ottimizzazione di OpenVPN (anche se, certo, ci sono aree che necessitano di revisione). Nessun client VPN in user space riesce a raggiungere anche solo un gigabit senza crittografia sul mio laptop, figuriamoci sui sistemi con processori deboli.
Orange Pi One
L'Orange Pi One di Xunlong è l'offerta migliore per il rapporto qualità/prezzo in questo momento. Con $9.99* ottieni un buon processore quad-core ARM Cortex-A7, che lavora stabilmente a una frequenza di 1008 MHz, e risulta chiaramente più performante dei suoi concorrenti Raspberry Pi Zero e Next Thing C.H.I.P. nella stessa fascia di prezzo. Tuttavia, qui si fermano i punti positivi. L'azienda Xunlong ignora completamente il software delle sue schede e, al momento del lancio dell'One, non forniva nemmeno un file di configurazione della scheda, per non parlare delle immagini pronte all'uso. Anche Allwinner, produttore dell'SoC, non si prende cura della supporto per il suo prodotto. La loro preoccupazione è solo la funzionalità minima su Android 4.4.4, il che significa che siamo costretti a usare un kernel della versione 3.4 con patch per Android. Fortunatamente, ci sono appassionati che raccolgono distribuzioni, modificano il kernel e scrivono codice per supportare le schede nel kernel mainline, in altre parole fanno il lavoro del produttore, rendendo questo prodotto accettabilmente funzionante. Per i miei scopi ho scelto la distribuzione Armbian, che si aggiorna frequentemente e con facilità (i nuovi kernel si installano direttamente tramite il gestore pacchetti, non copiare file su una partizione speciale, come di solito fa Allwinner), e supporta la maggior parte delle periferiche, a differenza delle altre.
Router
Per non sovraccaricare il debole processore del router con la crittografia e velocizzare la nostra connessione VPN, possiamo delegare questo compito a un processore più potente come l'Orange Pi, collegandolo al router in qualche modo. Mi vengono in mente o la connessione tramite Ethernet o USB — entrambi questi standard sono supportati da entrambi i dispositivi, ma non vorrei occupare le porte già esistenti. Fortunatamente, c'è una soluzione.
Il chip hub USB GL850G, utilizzato nel router, supporta il funzionamento di 4 porte USB, due delle quali non sono saldate. Non è chiaro perché il produttore non le abbia saldate, suppongo per evitare che gli utenti possano collegare immediatamente 4 dispositivi ad alto consumo energetico (come ad esempio dischi rigidi), poiché l'alimentatore del router non è progettato per tale carico. In ogni caso, questo gioca a nostro favore.
Per ottenere un'altra porta USB, è sufficiente saldare due fili ai pin 8(D-) e 9(D+) oppure 11(D-) e 12(D+).
Tuttavia, non è sufficiente collegare semplicemente due dispositivi USB e sperare che tutto funzioni da solo, come farebbe con l'Ethernet. In primo luogo, dobbiamo far funzionare uno di essi in modalità USB Client, e non USB Host; in secondo luogo, dobbiamo decidere come i dispositivi si riconosceranno a vicenda. Ci sono molti driver dei cosiddetti USB Gadgets (dal nome del sottosistema del kernel Linux) che consentono di emulare vari tipi di dispositivi USB: adattatori di rete, schede audio, tastiere e mouse, pen drive, fotocamere, console tramite porta seriale. Poiché il nostro dispositivo opererà in rete, la migliore opzione per noi è l'emulazione di un adattatore Ethernet.
Esistono tre standard Ethernet-over-USB:
- Remote NDIS (RNDIS). Uno standard obsoleto di Microsoft, utilizzato principalmente ai tempi di Windows XP.
- Ethernet Control Model (ECM). Uno standard semplice che incapsula i frame Ethernet in pacchetti USB. Ottimo per modem cablati con connessione USB, dove è comodo trasmettere frame senza elaborazione, ma a causa della sua semplicità e delle limitazioni del bus USB, non funziona molto velocemente.
- Ethernet Emulation Model (EEM). Un protocollo più intelligente che tiene conto delle limitazioni dell'USB e aggrega in modo ottimale diversi frame in uno, aumentando così la larghezza di banda.
- Network Control Model (NCM). Il protocollo più recente. Ha i vantaggi dell'EEM e ottimizza ulteriormente l'operatività con il bus.
Per far funzionare uno di questi protocolli sulla nostra scheda, come sempre, ci troveremo ad affrontare alcune difficoltà. Poiché ad Allwinner interessano solo le parti del kernel Android, funziona correttamente solo Android Gadget — quel codice che implementa la connessione con adb, l'esportazione del dispositivo tramite protocollo MTP e l'emulazione di una pen drive su dispositivi Android. Lo stesso Android Gadget supporta anche il protocollo RNDIS, ma nel kernel di Allwinner è rotto. Se provi a compilare il kernel con qualsiasi altro USB Gadget, il dispositivo semplicemente non apparirà nel sistema, qualunque cosa tu faccia.
Per risolvere il problema, fondamentalmente è necessario trovare il punto di inizializzazione del controller USB nel codice modificato dello sviluppatore dell'Android Gadget android.c, ma c'è anche una manovra alternativa per far funzionare almeno l'emulazione Ethernet tramite 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; /* is udc enable by gadget? */
+static u8 is_udc_enable = 1; /* is udc enable by gadget? */
#ifdef CONFIG_USB_SUNXI_USB0_OTG
static struct platform_device *g_udc_pdev = NULL;Questa patch attiva forzatamente la modalità USB Client, permettendo l'utilizzo di normali gadget USB da Linux.
Ora è necessario ricompilare il kernel con questa patch e il gadget richiesto. Ho scelto EEM, poiché dai risultati dei test si è rivelato più performante di NCM.
Il team di Armbian fornisce per tutte le schede supportate nel distributore. Basta scaricarlo, posizionare la nostra patch in userpatches/kernel/sun8i-default/otg.patch, modificare leggermente compile.sh e scegliere il gadget necessario:
Il kernel verrà compilato in un pacchetto deb, che sarà facile installare sulla scheda tramite dpkg.
Resta solo da collegare la scheda tramite USB e configurare il nostro nuovo adattatore di rete per ricevere un indirizzo tramite DHCP. Per fare ciò, è necessario aggiungere circa quanto segue in /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'È meglio impostare manualmente l'indirizzo MAC, poiché sarà casuale ad ogni riavvio del dispositivo, il che è scomodo e problematico.
Colleghiamo un cavo MicroUSB al connettore OTG, alimentiamo la scheda dal router (è possibile fornire alimentazione ai pin 2 e 3 della striscia, non solo al connettore di alimentazione).
Resta solo da configurare il router. È sufficiente installare il pacchetto con il driver EEM e aggiungere il nostro nuovo dispositivo USB di rete nel bridge della zona firewall locale:
opkg install kmod-usb-net-cdc-eem
Per instradare tutto il traffico nel tunnel VPN, è necessario aggiungere una regola SNAT sull'indirizzo IP della scheda lato router, oppure fornire come indirizzo gateway l'indirizzo della scheda tramite dnsmasq. L'ultimo può essere fatto aggiungendo la seguente riga in /etc/dnsmasq.conf:
dhcp-option = tag:lan, option:router, 192.168.1.100dove 192.168.1.100 — IP dell tua scheda. Non dimenticare di impostare l'indirizzo del router nelle impostazioni di rete sulla scheda stessa!
Per isolare i contatti della scheda dai contatti del router è stata utilizzata una spugna in melamina. È venuto così:
Conclusione
La rete funziona sorprendentemente bene tramite USB: 100-120 Mb/s, mi aspettavo di meno. OpenVPN gestisce circa 70 Mb/s di traffico crittografato, che non è molto, ma per le mie esigenze va bene. Il coperchio del router si chiude male, lasciando un piccolo spazio. Gli esteti possono rimuovere i connettori Ethernet e USB Host dalla scheda, permettendo al coperchio di chiudersi completamente, e ci sarà anche dello spazio in più.
O è meglio non fare queste perversioni e comprare .
Fonte: habr.com
