
Mõned meist ei kasuta internetti ilma VPN-ita mitmel põhjusel: mõnel inimesel on vaja eraldi IP-aadressi, ning lihtsam ja odavam on osta VPS kahe IP-ga, kui osta aadress teenusepakkujalt; mõned soovivad pääseda juurde kõikidele veebisaitidele, mitte ainult Venemaal lubatud neile; kolmandatel on vaja IPv6, kuid teenusepakkuja ei paku seda…
Enamasti luuakse VPN-ühendus otse seadmes, mida hetkel kasutatakse, mis on täitsa mõistlik, kui sul on vaid üks arvuti ja üks telefon ning neid harva samal ajal kasutatakse. Kui aga sinu koduvõrgus on mitmeid seadmeid või näiteks on olemas selliseid, kus VPN-i seadistada ei saa, oleks mugavam luua tunnel otse koduses ruuteris, et mitte muretseda iga seadme eraldi seadistamise pärast.
Kui oled kunagi OpenVPN-i oma ruuterisse seadnud, siis oled tõenäoliselt olnud ebameeldivalt üllatunud selle töökiirusest. Odavate ruuteri SoC-id saavad probleemideta edastada peaaegu gigabitist liiklust, edastades marsruutimise ja NAT-funktsioonid eraldi kiibile, mis on mõeldud ainult selle ülesande täitmiseks, ning nende ruuterite peamised protsessorid on suhteliselt nõrgad, kuna neile ei ole praktikas suuri koormusi. Selline kompromiss võimaldab saavutada ruuteri kõrget töökiirust ja märgatavalt vähendada valmis seadme hinda — võimsate protsessoritega ruuterid maksavad mitu korda rohkem ja neid positsioneeritakse mitte ainult interneti edastamiseks, vaid ka NAS-i, torrenti allalaadimise ja kodumaise meedia süsteemina.
Minu ruuter, TP-Link TL-WDR4300, ei ole just uus — mudel ilmus 2012. aasta keskel ja sellel on 560 MHz MIPS32 74Kc arhitektuuri protsessor, mille võimsus on piisav vaid 20-23 Mb/s krüpteeritud liikluse edastamiseks OpenVPN-i kaudu, mis tänapäeva koduse interneti kiirusest on üsna vähe.
Kuidas saaksime suurendada krüpteeritud tunneli kiirus? Minu ruuter on üsna funktsionaalne, toetab 3×3 MIMO ja töötab üldiselt hästi, ei tahaks seda vahetada.
Kuna praegu on kombeks teha 10-megabaidiseid internetilehti, kirjutada töölauarakendusi node.js-is ja pakendada neid 100-megabaidisesse faili, suurendada arvutusvõimet optimeerimise asemel, teeme midagi kohutavat — viime VPN-ühenduse tootlikule ühesirgele „arvutile“ Orange Pi One, mille paigaldame ruuteri korpusesse, kasutamata olemasolevaid võrgu- ja USB-pordi, kõik vaid $9.99*!
* + saatmine, + maksud, + õlle jaoks, + MicroSD.
OpenVPN
Ei saa öelda, et ruuteri protsessor oleks täiesti nõrk — see suudab šifreerida ja hajutada andmeid AES-128-CBC-SHA1 algoritmi abil kiirusel 50 Mb/s, mis on märgatavalt kiirem kui OpenVPN töötab, ja kaasaegne vooluline šifrisüsteem CHACHA20 POLY1305 hajutiga arendab lausa 130 megabitit sekundis! Miks on VPN-tunneli kiirus siis nii madal? Asi on konteksti vahetamises kasutaja- ja tuumaruumi vahel: OpenVPN šifreerib liiklust ja suhtleb välimailmaga kasutaja kontekstis, samas kui tuumaruumi kontekstis toimub marsruutimine ise. Operatsioonisüsteem peab pidevalt vahetama kontekste iga vastuvõetud või edastatud paketi puhul, ja see operatsioon ei ole kiire. See probleem on iseloomulik kõigile VPN-rakendustele, mis töötavad TUN/TAP draiveri kaudu, ja ei saa öelda, et madala kiirus problemaatika tuleneb OpenVPN halvast optimeerimisest (kuigi muidugi on seal kohti, mida võiks üle vaadata). Ükski userspace VPN-klient ei tooda isegi gigabitist minu sülearvutis, kui krüpteerimine on välja lülitatud, rääkimata nõrkade protsessoritega süsteemidest.
Orange Pi One
Xunlongi Orange Pi One on kõige soodsam pakkumine toote ja hinna suhe hetkel. $9.99* eest saad hea neljatuumalise ARM Cortex-A7 protsessori, mis töötab stabiilselt 1008 MHz sagedusel ja on selgelt võimekam kui tema konkurendid Raspberry Pi Zero ja Next Thing C.H.I.P. samas hinnaklassis. Sellele järgneb aga probleem. Xunlongi tarkvara tähelepanu on null, ning kui One müügile tuli, ei olnud nad isegi seadme konfiguratsioonifaili esitanud, rääkimata valmiskaubanduse piltidest. Allwinner, SoC tootja, ei paku oma toote kohta ka suurt tuge. Neid huvitab vaid minimaalne toimimine Android 4.4.4-s, seega oleme sunnitud kasutama versiooni 3.4 kerest koos Androidi plaastritega. Õnneks on entusiastid, kes koguvad ja toimetavad distributsioone, muudavad kera ning kirjutavad koodi seadmete toeks mainline-kernes, tehes balay töö tootja eest, et see kehvem asi korralikult töötaks. Minu eesmärkidel valisin distributsiooni Armbian, mis uuendatakse sageli ja mugavalt (uued kerged installitakse otse pakihalduri kaudu, mitte failide kopeerimisega spetsiaalsesse osi, nagu see tavaliselt Allwinneris toimub) ning toetab enamikku perifeeria seadmeid, erinevalt teistest.
Ruuter
Kuna me ei soovi nõrgestada ruuteri protsessorit krüpteerimisega ja kiirendada meie VPN-ühendust, saame selle ülesande kanda võimekamale Orange Pi protsessorile, ühendades selle ruuteriga kuidagi. Meelde tuleb kas Ethernet või USB — mõlemad standardid on seadmetes toetatud, kuid ma ei sooviks kasutada juba olemasolevaid porte. Õnneks on lahendus.
USB-hub GL850G, mida kasutatakse ruuteris, toetab 4 USB-porti, millest kaks pole joodetud. Pole selge, miks tootja ei jootnud neid, eeldan, et nad ei soovinud anda kasutajatele võimalust ühendada korraga 4 seadmeid, millel on kõrge voolutarve (näiteks kõvakettad), kuna ruuteri tavaline toiteplokk ei ole selliseks koormuseks mõeldud. Igatahes on see meile kasuks.

Teise USB-pordi saamiseks piisab, kui jootada kaks juhtme 8(D-) ja 9(D+) või 11(D-) ja 12(D+) jala külge.

Kuid lihtsalt kaht USB-seadet ühendada ja loota, et kõik töötab iseenesest, nagu juhtuks Ethernetiga, ei piisa. Esiteks peame sundima ühte neist töötama USB kliendi režiimis, mitte USB hostina; teiseks peame leidma viisi, kuidas seadmed üksteist tuvastavad. On olemas palju draivereid nn USB Gadgets (nime põhjal Linuxi tuumasüsteemis), mis võimaldavad emuleerida erinevaid tüüpe USB-seadmeid: võrguadapterit, helikaarti, klaviatuuri ja hiirt, USB-mälupulka, kaamerat, konsooli läbi seeriaport. Kuna meie seade töötab võrguga, sobib meile kõige paremini Ethernet-adapteri emulatsioon.
On olemas kolm Ethernet-over-USB standardit:
- Remote NDIS (RNDIS). Vananenud standard Microsoftilt, mida kasutati peamiselt Windows XP aegadel.
- Ethernet Control Model (ECM). Lihtne standard, mis kapseldab Etherneti raame USB-pakettidesse. Sobib suurepäraselt USB-ühendusega juhtmetele mootoritele, kus raamide edastamine ilma töötlemiseta on mugav, kuid oma lihtsuse ja USB-bussi piirangute tõttu ei tööta see väga kiiresti.
- Ethernet Emulation Model (EEM). Nutikam protokoll, mis arvestab USB piiranguid ja optimaalselt kogub mitu raami üheks, suurendades seeläbi läbilaskevõimet.
- Network Control Model (NCM). Uusim protokoll. Omab EEM-i eeliseid ja optimeerib veelgi bussi tööd.
Kuna igal neist protokollidest meie plaadil tööle saamine, nagu alati, toob kaasas teatavad raskused. Kuna Allwinnerit huvitavad ainult Androidi korpuse osad, töötab normaalselt ainult Android Gadget – see kood, mis rakendab ühendust adb, seadme eksportimist MTP protokolli kaudu ja USB-mälupulga emuleerimist Android-seadmetes. Isegi Android Gadget toetab RNDIS protokolli, kuid Allwinneri tuumas on see rikutud. Kui proovite kompileerida tuuma mõne teise USB Gadgetiga, ei ilmu seade süsteemi, olenemata sellest, mida teete.
Probleemi lahendamiseks oleks mõistlik leida USB-kontrolleri initsialiseerimise koht Android-gadget android.c modifitseeritud arendajate koodis, kuid on ka ringtee, et käivitada vähemalt Etherneti emulatsioon USB kaudu:
--- 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;See patch forcedly enables USB client mode, allowing the use of regular USB Gadgets from Linux.
Now, you should rebuild the kernel with this patch and the required gadget. I chose EEM, as it proved to be more efficient than NCM in tests.
The Armbian team provides for all supported boards in the distribution. Just download it, place our patch in userpatches/kernel/sun8i-default/otg.patch, edit compile.sh and select the necessary gadget:

The kernel will compile into a deb package, which can be easily installed on the board via dpkg.
All that is left is to connect the board via USB and configure our new network adapter to receive an address via DHCP. To do this, you need to add something like the following to /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'It's better to set the MAC address manually, as it will be random on each reboot of the device, which is inconvenient and troublesome.
Connect the Micro USB cable to the OTG port, connect the power from the router (it can be applied to pins 2 and 3 of the header, not just to the power jack).
Now, configure the router. Simply install the package with the EEM driver and add our new network USB device to the local firewall zone bridge:
opkg install kmod-usb-net-cdc-eem
To route all traffic into the VPN tunnel, you need either to add a SNAT rule for the board's IP address on the router side or to provide the board's address as the gateway address via dnsmasq. The latter is done by adding the following line to /etc/dnsmasq.conf:
dhcp-option = tag:lan, option:router, 192.168.1.100kus 192.168.1.100 — the IP address of your board. Don't forget to specify the router's address in the network settings on the board itself!
To isolate the board's contacts from the router's contacts, a melamine sponge was used. It turned out something like this:

Kokkuvõte
USB kaudu töötav võrk üllatab kiiruselt: 100-120 Mb/s, ootasime vähem. OpenVPN edastab umbes 70 Mb/s krüpteeritud liiklust, mis ei ole ka väga palju, kuid minu vajaduste jaoks piisab. Ruuteri kaas sulgub halvasti, jättes väikese vahe. Esteetikud võivad emaplaadilt eemaldada Etherneti ja USB Host-pesad, mis võimaldab kaanel täielikult sulguda, ja veel jääb ruumi.
Või on parem mitte tegeleda sellise poriga ja osta. .
Allikas: habr.com
