Néhányunk számára a VPN használata elengedhetetlen az interneten, legyen szó akár dedikált IP-cím igényéről — ilyenkor gyakran egyszerűbb és olcsóbb VPS-t vásárolni két IP-címmel, mint közvetlenül a szolgáltatótól vásárolni — akár arról, hogy minden weboldalhoz szeretnénk hozzáférni, nem csak azokhoz, amelyek Oroszország területén megengedettek; másoknak pedig IPv6-ra van szükségük, de a szolgáltató ezt nem biztosít…
A VPN kapcsolatot leggyakrabban az adott eszközön állítják be, amelyet éppen használunk, ami teljesen indokolt, ha csak egy számítógépünk és egy telefonunk van, amelyeket ritkán használunk egyszerre. Ha viszont számos eszköz található az otthoni hálózatban, vagy például vannak olyanok, amelyeken nem lehet VPN-t beállítani, kényelmesebb lenne, ha a tunnelt közvetlenül az otthoni routeren építhetnénk fel, így nem kellene minden egyes eszköz beállításával bajlódnunk.
Ha valaha is telepítette az OpenVPN-t a routerére, valószínűleg kellemetlenül csalódott a sebességében. A még olcsó routerek SoC-jai gond nélkül átengedik a gigabites forgalmat, mivel a routing és a NAT funkciókat egy külön chip végzi, amelyet kizárólag erre a feladatra szántak. A fő processzorok viszont viszonylag gyengék, mivel szinte semmilyen terhelés nincs rajtuk. Ez a kompromisszum lehetővé teszi a router magas sebességű működését, és jelentősen csökkenti a készülék árát — a nagy teljesítményű processzorral rendelkező routerek többszörös áron kaphatók, és már nem csak internetmegosztó dobozként pozicionálják őket, hanem NAS-ként, torrentletöltőként és otthoni multimédiás rendszerekként is.
Az én routerem, a TP-Link TL-WDR4300, nem nevezhető újnak — a modell 2012 közepén jelent meg, és egy 560 MHz-es MIPS32 74Kc architektúrájú processzorral rendelkezik, amelynek teljesítménye csupán 20-23 Mbps titkosított forgalom feldolgozására elegendő az OpenVPN-en keresztül, ami a mai otthoni internet sebességének tükrében meglehetősen alacsony.
Hogyan tudnánk növelni a titkosított tunnell sebességét? Az én routerem elég funkcionális, 3×3 MIMO támogatással bír, és jól is működik, nem szeretném cserélni.
Mivel manapság általános, hogy 10 megás weboldalakat készítünk, desktop alkalmazásokat írunk node.js-en és 100 megás fájlokba csomagoljuk őket, illetve a számítási teljesítmény növelésére törekszünk az optimalizálás helyett, valami borzalmasat fogunk tenni — a VPN kapcsolatot egy teljesítményorientált, egylapos "számítógépre", az Orange Pi One-ra helyezzük, amelyet a router házába fogunk telepíteni, anélkül, hogy elfoglalnánk a meglévő hálózati és USB portokat, mindezt mindössze $9.99*!
* + szállítás, + adók, + sörre, + MicroSD.
OpenVPN
A router processzorát nem lehet teljesen gyengének nevezni — képes az AES-128-CBC-SHA1 algoritmus használatával 50 Mb/s sebességgel titkosítani és hasheleni az adatokat, ami észrevehetően gyorsabb, mint az OpenVPN működése, míg a modern folyamatos titkosítás, a CHACHA20 és a POLY1305 hash akár 130 megabit per másodperc sebességet is elér! Miért olyan alacsony mégis a VPN alagút sebessége? Az ok a felhasználói és a kernel tér közötti kontextusváltás: az OpenVPN a felhasználói kontextusban titkosítja a forgalmat és kommunikál a külvilággal, miközben a forgalom irányítása a kernel kontextusában zajlik. Az operációs rendszernek folyamatosan váltogatnia kell, hogy melyik irányba összpontosítson, minden egyes fogadott vagy küldött csomagnál, és ez a művelet nem gyors. Ez a probléma minden VPN alkalmazásra jellemző, amely TUN/TAP meghajtón keresztül működik, és nem mondható el, hogy a lassú sebességet az OpenVPN rossz optimalizálása okozza (bár nyilvánvalóan vannak olyan helyek, amelyeket érdemes lenne újragondolni). Egyetlen felhasználói VPN kliens sem tudott még 1 gigabitet produkálni titkosítás nélkül a laptopomon, nemhogy a gyenge processzorral rendelkező rendszerekről beszéljünk.
Orange Pi One
Az Xunlong Orange Pi One egypalackos számítógépe a legjobb ár-érték arányt kínálja jelenleg. 9,99 USD-ért* egy jó négymagos ARM Cortex-A7 processzort kap, amely stabilan 1008 MHz-en működik, és egyértelműen teljesítményben felülmúlja a Raspberry Pi Zero és a Next Thing C.H.I.P. készülékeket az árkategóriájában. Az előnyök ezzel véget is érnek. Az Xunlong vállalat egyáltalán nem foglalkozik a lapjaik szoftverével, és amikor az One elérhetővé vált, még a lap konfigurációs fájlját sem biztosították, nemhogy a kész képeket. Az Allwinner, a SoC gyártója sem igazán figyel a termékét támogató szoftverre. Őket csak az Android 4.4.4-es operációs rendszer minimalista működése érdekli, ami azt jelenti, hogy muszáj a 3.4-es verziójú kernel használatára korlátozódnunk Android-patch-ekkel. Szerencsére vannak lelkes fejlesztők, akik disztribúciókat állítanak össze, korrigálják a kernelt, és kódokat írnak a lapok mainline kernelben való támogatásához, tehát gyakorlatilag elvégzik a gyártó munkáját, hogy ez a termék megfelelően működjön. Én az Armbian disztribúciót választottam a céljaimhoz, mivel gyakran és kényelmesen frissíthető (az új kernelt közvetlenül a csomagkezelőn keresztül telepítjük, nem pedig fájlok másolásával egy speciális partícióra, mint ez az Allwinner esetében általában történik), és a legtöbb perifériát támogatja, ellentétben a többihez képest.
Router
Annak érdekében, hogy ne terheljük le a router gyenge processzorát a titkosítással, és felgyorsítsuk a VPN-kapcsolatunkat, átvihetjük ezt a feladatot a teljesítményesebb Orange Pi processzorra, ha valamilyen módon csatlakoztatjuk a routerhez. Az Ethernet vagy a USB csatlakoztatás jut eszembe – mindkét szabványt támogatják a készülékek, de nem szeretném elfoglalni a már meglévő portokat. Szerencsére van megoldás.
A routerben használt GL850G USB hub chip négy USB-port működését támogatja, amelyekből kettő nincs forrasztva. Nem világos, miért nem forrasztotta ezeket a gyártó, feltételezem, hogy nem kívánja lehetővé tenni a felhasználóknak, hogy egyszerre négy magas energiaigényű eszközt (például merevlemezeket) csatlakoztassanak, mivel a router beépített tápegysége nem készült fel ilyen teherbírásra. Mindenesetre ez nekünk kedvez.
Ahhoz, hogy egy új USB-portot kapjunk, elegendő két vezetéket forrasztani a 8-as (D-) és a 9-es (D+) vagy a 11-es (D-) és a 12-es (D+) lábakhoz.
Azonban nem elég csak két USB-eszközt csatlakoztatni, és remélni, hogy minden magától működik, ahogyan az Ethernet esetében történne. Először is, meg kell győződnünk róla, hogy az egyik eszköz USB Client üzemmódban működik, nem pedig USB Host módban, másodszor pedig meg kell határoznunk, hogyan fogják az eszközök azonosítani egymást. Számos úgynevezett USB Gadget illesztőprogram létezik (a Linux kernel alrendszerének nevezete), amelyek különböző típusú USB-eszközök emulálására szolgálnak: hálózati adapter, hangkártya, billentyűzet és egér, pendrive, fékamera, konzol soros porton. Mivel az eszközünk a hálózattal fog dolgozni, a legjobban az Ethernet-adapter emulációja fog megfelelni nekünk.
Három Ethernet-over-USB szabvány létezik:
- Remote NDIS (RNDIS). Ez a Microsoft elavult szabványa, és főként a Windows XP idejében használták.
- Ethernet Control Model (ECM). Egyszerű szabvány, amely az Ethernet-csomagokat USB-csomagokba encapsulálja. Kiválóan alkalmas USB csatlakozású vezetékes modemek számára, ahol kényelmes kereteket továbbítani feldolgozás nélkül, de egyszerűsége és az USB-busz korlátai miatt nem túl gyors.
- Ethernet Emulation Model (EEM). Okosabb protokoll, amely figyelembe veszi az USB korlátait, és optimálisan aggregál több keretet egybe, így növelve a sávszélességet.
- Network Control Model (NCM). A legújabb protokoll. Az EEM előnyeivel rendelkezik, és tovább optimalizálja a busz kezelését.
Ahhoz, hogy bármelyik protokollt működésre bírjuk a lapkánkon, mint mindig, néhány nehézséggel szembe kell néznie. Mivel az Allwinner csak az Android kernel részeivel foglalkozik, normálisan csak az Android Gadget működik – ez a kód, amely biztosítja a kapcsolatot az adb-vel, az eszköz exportálását MTP protokollon keresztül és a pendrive emulációt Android-eszközökön. Maga az Android Gadget is támogatja az RNDIS protokollt, de az Allwinner kernelben törött. Ha megpróbálja egy másik USB Gadget-tel lefordítani a kernelt, az eszköz egyszerűen nem fog megjelenni a rendszerben, bármit is tesz.
A probléma megoldásához valójában meg kell találni a USB-vezérlő inicializálási helyét a módosított Android gadget kód android.c filen, de van egy kerülő megoldás is, hogy legalább az Ethernet emulációt USB-n keresztül működésre bírjuk:
--- 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;
/* is udc enable by gadget? */
#ifdef CONFIG_USB_SUNXI_USB0_OTG
static struct platform_device *g_udc_pdev = NULL;Ez a javítás kényszeríti az USB kliens módot, lehetővé téve a normál USB Gadgetek használatát Linuxból.
Most újra kell fordítani a kernelt ezzel a javítással és a szükséges gadgettel. Az EEM-et választottam, mivel a tesztek szerint jobb teljesítményt nyújt, mint az NCM.
Az Armbian csapata biztosít az összes támogatott laphoz a disztribúcióban. Csak le kell tölteni, a javítást el kell helyezni userpatches/kernel/sun8i-default/otg.patch, kicsit szerkeszteni kell a compile.sh és ki kell választani a szükséges gadgetet:
A kernel deb-csomagként fog összeállni, amelyet könnyen telepíthetünk a lapra a dpkg.
Csak csatlakoztatni kell a lapot USB-n, és be kell állítani az új hálózati adapterünket, hogy DHCP-n keresztül kapjon címet. Ehhez körülbelül a következőt kell hozzáadni a /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'A MAC-címet jobb kézzel megadni, mivel az minden újraindításkor véletlenszerű lesz, ami kényelmetlen és fáradságos.
Csatlakoztassuk a MicroUSB kábelt az OTG porthoz, és csatlakoztassuk az áramot az útválasztótól (azt a 2. és 3. tűre is csatlakoztathatjuk, nem csak a tápcsatlakozóra).
Most be kell állítani az útválasztót. Elég telepíteni az EEM drivert és hozzáadni az új USB hálózati eszközünket a helyi tűzfal zónához:
opkg install kmod-usb-net-cdc-eem
Ahhoz, hogy az összes forgalmat a VPN alagúton irányítsuk, vagy SNAT-szabályt kell hozzáadni az útválasztón lévő lap IP-címére, vagy az útválasztó címének a lap címét kell megadni dnsmasq révén. Az utóbbit a következő sor hozzáadásával lehet megtenni /etc/dnsmasq.conf:
dhcp-option = tag:lan, option:router, 192.168.1.100ahol 192.168.1.100 — az Ön lapjának IP-címe. Ne feledje, hogy az útválasztó címét a lap hálózati beállításaiban is meg kell adni!
A lap érintkezőinek elszigetelésére a router érintkezőitől melamin szivacsot használtunk. Így néz ki:
Zárás
A hálózat USB-n keresztül meglepően gyorsan működik: 100-120 Mb/s, kevesebbre számítottam. Az OpenVPN körülbelül 70 Mb/s titkosított forgalmat enged át, ami nem túl sok, de az én igényeimhez elegendő. A router fedél nem záródik teljesen, kis rés marad. Az esztéták eltávolíthatják az Ethernet és USB Host csatlakozókat az alaplapról, hogy a fedél teljesen záródjon, és még hely is maradjon.
Vagy inkább ne foglalkozzunk ilyesmivel, és vegyünk egyet. .
Forrás: habr.com
