Az utóbbi időben észrevettem egy tendenciát. Ahelyett, hogy akkor cserélnék le egy routert, amikor az szó szerint leáll, már korábban kellett cselekednem – új felszerelést kellett cserélnem, mert egy régi router már nem tudott lépést tartani a területen elérhető növekvő internetsebességgel. (Megjegyzem, kellőképpen hálás vagyok ezért a problémáért.) Legutóbbi példaként egy egész csomó Netgear ProSafe 318G router hagyott cserben utoljára, mivel a kisvállalkozások 1,5-9mbps-os hagyományos T1-kapcsolatokról 50mbps-os koax (kábel) kapcsolatokra álltak át.
Igen, koax – nem üvegszálas. Még a koax is túl soknak bizonyult a régi ProSafe sorozat számára. Ezek az eszközök nemhogy nem tudták tartani a lépést, hanem egyenesen pofára estek. Gyakran előfordult, hogy a régi routerek a régi kapcsolattal 9mbps-ről az 50mbps-os kapcsolattal 3mbps vagy annál is kevesebb sebességteszt eredményt dobtak le. Ez nyilvánvalóan nem működik.
Egyre inkább a vezeték nélküli routerek jelentik a választ. Ezek általában hosszúak a dörzsölt kinézetű műanyag és az élénk színű webes felületek, de rövidek a műszaki jellemzők és a megbízhatóság terén. Mit tehet egy zsoldos rendszergazda? Nos, alapvetően bármi, ami két fizikai hálózati interfésszel rendelkezik, lehet router. És ma már rengeteg viszonylag gyors, olcsó és (szuper fontos!) teljesen szilárdtest-generikus doboz van forgalomban.
Az idő tehát végre eljött. Szembesülve az öregedő hardverekkel és az új fogyasztói ajánlatokkal, amelyek nem feleltek meg az igényeimnek, úgy döntöttem, hogy saját routert építek. És ha a mai morfondírozó csatlakozási tájkép hasonló helyzetben hagyja önt, kiderül, hogy mind az építés, mind az építés elég gyors.
Miért csináljuk a nehezebb úton
Egy csomóan valószínűleg azt mormolják, hogy “persze, pfSense, persze”. Néhányan talán még a smoothwallon vagy az untangle NG-n is gondolkodtok. Játszottam a legtöbb tűzfal disztróval, de úgy döntöttem, hogy egyszerűbb, régimódibb megoldást választok: egy egyszerű, csak CLI-vel telepített Ubuntu Server és néhány iptables szabály.
Kétségtelen, hogy valószínűleg nem ez a legpraktikusabb megközelítés minden olvasó számára, de nekem így volt értelme. Elég sok tapasztalatom van az iptables és magának a Linux kernelnek a nagy áteresztőképességű internetes skálán történő finomhangolásában, és minél kevesebb csillogó funkció, grafika és kattogó dolog kerül közém és a tűzfalasztal közé, annál kevesebb bolyhos dolgot kell eltüntetnem az útból, és annál kevesebb új, a munkám többi részében nem alkalmazható dolgot kell megtanulnom. Minden szabályt, amit már tudok, hogyan kell létrehozni az iptablesben a szervereimhez való hozzáférés kezeléséhez, azt is tudom, hogyan kell alkalmazni a tűzfalamra – ha a tűzfalamon ugyanaz a disztribúció fut, mint a szervereimen.
Mellett elég sokat dolgozom az OpenVPN-nel, és szeretném, ha továbbra is úgy tudnám beállítani a szervereit és a klienseit, ahogyan már megszoktam. Néhány tűzfal disztrónak van beépített OpenVPN támogatása, néhánynak nincs, de még azok is, amelyeknek van beépített támogatása, hajlamosak arra, hogy másképp várják el a dolgok futását, mint én. Ismétlem, minél inkább kimarad a rendszer az utamból, annál boldogabb leszek.
További bónuszként tudom, hogy nagyon egyszerűen mindent teljesen naprakészen tudok tartani az új és teljesen vaníliás Ubuntu routeremen. Minden közvetlenül a Canonical által támogatott, és mindenre be lehet (és be is van) kapcsolva az automatikus frissítés. Hozzáadom az alkalmi cron feladatot a router újraindításához (hogy új kerneleket kapjak), és máris aranyat ér.
Hardver, hardver, hardver
Egy későbbi cikkben végigvesszük a hogyan-t, de ma fontos leszögezni, hogy miért lehet a DIY router-építés a legjobb megoldás. Ehhez először is meg kell értenünk a mai általános helyzetet.
A fogyasztói világban a routerek többnyire ici-pici MIPS CPU-kat rejtenek a motorháztető alatt, sok RAM nélkül (finoman szólva). Ezek a routerek nagyrészt az interfész alapján különböznek egymástól: Mennyire fényes? Hány technikai funkcióval rendelkezik? Könnyen eligazodnak rajta a felhasználók?
A SOHO-piac felsőbb szegmensében már okostelefon-minőségű ARM CPU-kkal és sokkal több RAM-mal találkozhatunk. Ezek a routerek – mint például a Nightgear Nighthawk sorozat, amelyek közül az egyiket később kalapáljuk – több maggal, magasabb órajelekkel és sokkal több RAM-mal rendelkeznek. Ezek sokkal magasabb árcédulával is rendelkeznek, mint az olcsóbb versenytársak. Én egy Linksys EA2750-et vettem 89 dollárért, de a Netgear Nighthawk X6, amit hozzá kaptam, majdnem háromszor drágább volt (még ünnepi akcióban is!) 249 dollárral.
Mégis más utat akartam választani. Mostanában rengeteg érdekes és viszonylag olcsó kis x86-64-es ventilátor nélküli gép kezdett felbukkanni a piacon. A trükk a router építésénél az, hogy olyan gépet találjunk, amelyik több NIC-vel rendelkezik. Az Amazonon találhatsz néhány meglehetősen biztonságos tétet, de ezek régebbi Atom-alapú processzorok, és én egy újabb Celeront akartam. Néhány jó öreg internetes keresgélés és tétovázás után végül belevágtam az Alibaba-ba, és rendeltem magamnak egy új Partaker Mini PC-t a Shenzhen Inctel Technology Company-tól. Miután 240 dollárt fizettem magáért a routerért, és további 48 dollárt egy 120 GB-os Kingston SSD-ért a Newegg-től, körülbelül 40 dollárral többet költöttem a Homebrew Specialre, mint a Nighthawkra. Vajon megérte volna?
Előkerült egy kihívó
Mielőtt elkezdenénk a tesztelést, vessünk egy gyors vizuális pillantást a versenytársakra.
A Nighthawk a többihez képest hatalmas és impozáns (még inkább, mint ahogy a képen látszik). Valójában lényegesen nagyobb, mint az én Homebrew Special-om, ami egy teljesen működőképes, általános célú PC, amit tökéletesen alkalmas asztali számítógépként használhatsz. Olyan, mintha a DC Comics megkérte volna H.R. Giger-t, hogy segítsen megtervezni egy vezeték nélküli routert Batman számára.
A Homebrew Special maga is imádnivaló. Egy kék és egy piros LED van a ház belsejében, és éjszaka mindkettő fénye közvetett módon kiárad a hűtőnyílásokból, így a hálózati stack ünnepi party megjelenést kap. Ha lenne rajta ventilátor, ami villódzást okozna, az őrületbe kergetne, de mivel ez egy egyenletes, lágy világítás, nekem tulajdonképpen tetszik.
A Linksys és a Buffalo viszont pontosan úgy néz ki, mint amilyenek – olcsó routerek. Érdemes azonban megjegyezni, hogy a Linksys stílusa nagy előrelépés a márka múltjához képest. Úgy néz ki, mint valami professzionális és kevésbé, mint egy gyermekjáték. (De elég a stílusból – itt az ideje, hogy ezeket a szegény routereket próbára tegyük.)
A nyilvánvaló első kihívás egy egyszerű sávszélesség-teszt. Egy számítógépet teszel a LAN oldalra és egy számítógépet a WAN oldalra, és lefuttatod az iperf nevű ügyes kis eszközt középen. Egyszerű, igaz?
Nos, ez egy rövid, unalmas cikk lenne. Maga a hálózat gigabitet mér, a három gigabites router gigabitet, a 100 megabites router pedig 100 megabitet.
A valóságban egy ilyen egyszerű teszt még csak meg sem mondja el a lényeget. Az egyetlen ok, hogy megcsináljuk, talán az, hogy megmutassuk, mennyire értelmetlen. A routergyártók egyre inkább tudatában vannak annak, hogy az emberek valóban tesztelik a termékeiket, és egyetlen gyártó sem akarja, hogy a terméke bárhol máshol legyen, mint a smallnetbuilder router-táblázatának élén. Ennek fényében a gyártók manapság aktívan hajszolják a statisztikákat.
A probléma az, hogy a statisztikák csak statisztikák. Egy magas számot elérni egy tiszta átviteli tesztben jobb, mint a semmi, de ez messze nem a teljes történet. Ezt a leckét a saját bőrömön tapasztaltam meg, amikor a 2000-es évek elején egy T-1 szállítónak dolgoztam. A rendkívül drága Adtran-modemeik 50-100 ember normál internethasználatát remekül kezelték, de egyetlen felhasználó, aki Limewire-t vagy más P2P-klienst futtatott, pillanatok alatt tönkretette az egészet. (Az akkori megoldás: a drága Adtran-modem elé egy olcsó, de félelmetes 150 dolláros Netopia router került. A probléma megoldva.)
Még viszonylag egyszerű útválasztás esetén is – nincs mély csomagvizsgálat, nincs streaming malware-ellenőrzés vagy behatolásérzékelés, nincs alakítás – a processzor és a router rendelkezésére álló RAM egyaránt fontos, jóval az internetkapcsolat telítettségének képességén túl. A peer-to-peer fájlcsere manapság a legbrutálisabb tevékenység, amellyel egy hálózat találkozhat (legyen az a bittorrent, a Gnutella vagy az eDonkey valamelyik változata, vagy egy játékgyártó peer-to-peer letöltési rendszere). Én már nem játszottam WoW-ot, mire a Blizzard P2P terjesztési rendszerét bevezették, de az akkori szobatársam még nem. Az indulás napján az új WoW peer letöltési rendszere segítő jelleggel alapértelmezés szerint nem tartalmazott semmilyen fojtást. Vidáman próbált kapcsolatot találni és fenntartani egyszerre szó szerint több ezer klienssel, és az otthoni hálózatom úgy ment tönkre, mint Gilbert Godfried, akit Terry Tate megtámadott. A szobatársam és én összeszólalkoztunk.
Az ilyen múltbeli tapasztalatok alapján nem csak minimálisan akarom “tesztelni” a kihívóimat és befejezni a napot, hanem tényleg meg akarom őket izzasztani. Ezért olyan munkaterhelésekkel fogom őket sújtani, amelyek három problémás területet hangsúlyoznak: a hálózati kapcsolat telítettségét, az egyes TCP/IP-kapcsolatok nagyon gyors létrehozását és megszakítását, valamint az egyes TCP/IP-kapcsolatok tömeges nyitva tartását egyszerre.
Egy botnet van a zsebemben, és készen állok rá, hogy felrázzam
Rövid ideig fontolgattam, hogy felállítok valamilyen förtelmes, Docker-üzemű monstrumot több tízezer Linux-konténerrel, egyedi IP-címekkel, amelyek mind kapcsolatért kiáltanak és/vagy weboldalakat szolgálnak ki. Aztán észhez tértem. Ami a routereket illeti, nincs különbség aközött, hogy több ezer egyedi IP-címhez vagy csak több ezer porthoz tartanak fenn kapcsolatot ugyanazon az IP-címen. Egy kis időt töltöttem azzal, hogy Lee Hutchinson kedvenc webszerverét, az nginx-et egy nevetséges Lovecrafti-szörnyeteggé változtattam, 10 000 fejjel és pusztítási étvággyal.
Minden egyes router esetében az ApacheBench segítségével teszteltem egy jpeg letöltését három különböző fájlmérettel (10K, 100K és 1M), négy különböző párhuzamossági szinten (10, 100, 1 000 és 10 000 egyidejű ügyfél). Így összesen 12 tesztet kapunk, nem számítva a kezdeti iperf tesztünket, és érdemes mindegyiket egyfajta spektrumként látni.
A legtöbb szempontból az a 10K-s fájl nagyobb kihívást jelent. A kis fájlméret azt jelenti, hogy másodpercenként sokkal több egyedi fájlt tudsz szállítani, mielőtt telítődne az interfész, ami azt jelenti, hogy sokkal több TCP-kapcsolatot kell létrehozni és megszakítani, ami megterheli a router CPU-ját. Másrészt az 1M-os fájl azt jelenti, hogy a magasabb párhuzamossági szinteken garantáltan több kapcsolatot tartasz nyitva. Érdemes megnézni, hogyan kezelik a routerek a teljes spektrumot, mert minden szint elég jól modellezi azt a meglehetősen gyakori kihívást, amit egy routernek kezelnie kell (nagyszámú e-mail letöltése vagy küldése, peer-to-peer fájlmegosztás vagy általános webböngészés sok felhasználótól), ha extrém szintre viszik.
Végeredményben nem csak az nginxet, hanem magát a Linux kernelt is tuningolnom kellett ahhoz, hogy megbízhatóan elérjem az általam keresett átviteli teljesítményt. Maguk a routerek “stock”-ok – még az én Homebrew Special-om is hangolatlan maradt -, de a teszt szerverek, Menhir és Monolith (mindkettő AMD FX-8320 8-magos CPU-val, 32GB DDR3 RAM-mal és Ubuntu Trusty OS-sel teljesen naprakészen) elég komoly masszírozást igényeltek ahhoz, hogy kezelni tudják ezt a fajta terhelést.
Egy ekkora őrület mellett érdemes meggyőződni arról, hogy a tényleges szerverek és a hálózat mire képes, mielőtt bármilyen következtetést levonsz a közéjük helyezett routerekkel kapcsolatban. Kezdetnek először önmagában teszteltem a Menhirt a localhost interfészen (egyáltalán nincs hálózat), majd a szerverek között csak a hálózati switchemen keresztül teszteltem (egy Netgear ProSafe 16 portos gigabites, ha esetleg érdekel).
A localhost eredményei nem is lehettek volna jobbak – minden tesztnél sokkal, de sokkal nagyobb az átviteli sebesség, mint a gigabites. Valójában kézzel kellett korlátoznom a grafikon Y tengelyének skáláját, különben egyáltalán nem lehetett volna látni a valódi teszteket. A közvetlen hálózati teszt nem volt túl rossz, de nyilvánvalóan kezdünk a felső határértékekbe ütközni. Nem vagyok benne biztos, hogy a küszködő komponens maga a switch vagy a fedélzeti hálózati interfészek mindkét szerverben, de valami nem teljesen felel meg a kihívásnak. Elég jó, hogy dolgozni tudjunk vele. Ideje végre bekapcsolni a routereket.
Készüljünk fel a dübörgésre!
Kicsit ideges voltam. Már így is eléggé ragaszkodtam a kis házi készítésű készülékemhez – elvégre én magam építettem. Tudtam, hogy könnyedén le fogja győzni az öreg Buffalót, amit előástam a fiókból, és a Linksys-t, ami szó szerint a legolcsóbb dolog volt a Staples-ben gigabites interfésszel. De vajon le tudná-e győzni a Nighthawk lézervezérelt atomgőzkalapácsát? Azt hittem, igen, de nem voltam benne biztos.
Amikor a letöltési tesztek befejeződtek, nem volt több kérdés a Homebrew Specialről. Igen, képes volt legyőzni a Nighthawkot… és utána ásítva elsétálni. Eltekintve egy kis visszaeséstől a 10K fájlméret/10 egyidejű kapcsolat szintjén (ami az abszolút legtöbb létrehozott és megszakított kapcsolattal hívja ki a CPU-t), szinte ugyanúgy teljesített, mint maga a közvetlen hálózati kapcsolat.
A Nighthawk egyébként tényleg egy remek SOHO router, amit elég sokat telepítettem. Viszont szinte azonnal leesett. Egyszerre 10 megabájtos letöltéseknél fej-fej mellett haladt. Bármilyen nagyobb kihívás esetén a teljesítmény meredeken lejtőre került.
A Linksys, nem meglepő módon, egyáltalán nem teljesített jól. Még egy olyan egyszerű feladat, mint 10 fájl egyidejű letöltése is majdnem a felére csökkentette a teljesítményét, mint amit a naiv iperf teszt mutatott. A dolgok onnantól kezdve csak rosszabbodtak, és több tesztet sem tudott befejezni. A pozitívum, hogy a Linksys remekül demonstrálja, hogy az útválasztó valóban számít.
Végre a bátor kis Bölény is megérdemel némi elismerést. Annak ellenére, hogy kevesebbe került, mint a Linksys, amikor vadonatúj volt (nyolc évvel ezelőtt, ne feledd), és öt évig az íróasztal fiókjában lappangott, felállt a közmondásos bárszékről, és a tesztek felében megverte a Linksys-t. A Buffalo ezt a sikert annak ellenére érte el, hogy a hálózati interfész tizedannyi sebességre volt méretezve. Ez aztán a bátorság. Legközelebb, amikor valaki olcsón szúrja le a frissen gyártott kínai termékeket, azt fogom kiabálni: “Emlékezz a Buffalóra!”
Mielőtt azonban bármilyen következtetésre jutnánk, a feltöltési sebességet is figyelembe kell venni.
Szerencsére itt nem igazán változott semmi a routerek közötti viszonyokban. A Homebrew még mindig úgy néz ki, mintha ott sem lenne, szinte teljesen megfelel a közvetlen hálózati kapcsolatnak. A Nighthawk továbbra is teljes mértékben uralja a Linksys-t, és a selejtes kis Buffalo még mindig az elavult legjobbját nyújtja. Abszolút értékben azt láthatjuk, hogy mind a Nighthawk, mind a Linksys valamivel jobban teljesít feltöltéskor, mint letöltéskor, de ez semmi különös. Ez a végeredmény ugyanaz marad: a Homebrew Special tartja a lépést a hálózattal (furcsa módon még a közvetlen kapcsolatnál is jobban teljesít a 10.000 kapcsolat/10K fájl tesztben), a Nighthawk egyértelműen megéri az árcéduláját a Linksyshez képest, a Linksys pedig, nos, olcsó.
Az utolsó grafikonon azonban új eredményeket kapunk – a lazacszínű sávokat, amelyek elég stabilan valamivel 200mbps felett vannak az egész grafikonon. Ez a Homebrew Special a kripto-izmait fitogtatja. Egy OpenVPN szerver fut rajta. Ehhez a teszthez a WAN-oldali kiszolgáló, a Menhir, az útválasztó beépített OpenVPN-kiszolgálójához csatlakozik. A Homebrew Special LAN-oldalának forgalma a VPN-alagúton keresztül kerül átirányításra, így a Menhir a Monolith (a LAN-oldali szerver) LAN IP-címét éri el néhány igen lenyűgöző, 2048 bites, SSL-alapú titkosítás segítségével. Tekintettel arra, hogy az én körzetemben még senki sem kínál 200mbps feletti internetkapcsolatot, ez örömtáncra készteti a belső kriptokockámat. Szó szerint az internetforgalom minden egyes bájtját titkosíthatnám, mindkét irányban, teljesítménycsökkenés nélkül.
Egy gyors záró megjegyzés
Bármilyen lenyűgöző is az én kis Homebrew Special-om, egy dolog hiányzik belőle, amit mindhárom másik versenyző kínál: a vezeték nélküli hozzáférés. Hozzáadhatnék egy vezeték nélküli kártyát a Homebrew-hoz, és vezeték nélküli hozzáférést tudnék biztosítani, de jelenleg nem tervezem. Túlságosan is jól ismerem a PC-s vezeték nélküli kártyák kínálatát, és ezek mind bűzlenek a jégen. Még olcsó eszközök, mint a Linksys vagy a Buffalo szállítana egy smackdown a vezeték nélküli lefedettség és a tartomány, és a Nighthawk még csak nem is ugyanabban a ligában. Ez tényleg egy lézervezérelt atomgőzkalapács, ha a vezeték nélküli hatótávolságról, lefedettségről és egyidejű kapcsolódásról van szó. (Nekem most is van egy ilyen, amelyik 50+ felhasználót fed le egy 53 000 négyzetméteres létesítményben saroktól sarokig.)
Ezzel együtt semmi sem akadályozza meg, hogy egy külön WAP-ot (Wireless Access Point) használjon szigorúan a Wi-Fi feladatok ellátására. Az én házamban ez egy pár Ubiquiti “hoki korong” WAP, egy-egy a ház minden emeletére. Kicsit több munkával jár a kezelésük, mint a Nighthawknak, de a párjuk fele annyiba kerül. Ezek eléggé szabványos Linux eszközök, amelyekbe közvetlenül SSH-val lehet belépni, és egy nagyon klassz kis webes alkalmazásból kezelhetők, amelyet futtathatsz… kitaláltad, közvetlenül a Homebrew Special-on. (Az Ubiquiti szerver migrálása a munkaállomásomról a Homebrew Specialre lesz az egyik első feladatom e cikk után, és aztán aktív használatra fogom előléptetni az otthoni irodai hálózatomban.)
Az alaposság nevében meg kell jegyeznünk egy közös korlátot, valamit az összes általam valaha kezelt fogyasztói hálózati eszköznél: a szinte bármilyen változtatás utáni újraindítási vágyat. Néhány ilyen újraindítás jóval több mint egy percig tart. Fogalmam sincs, hogy miért, de bármi is az oka, a Homebrew Special-t nem sújtja ez az ipari szabvány. Változtatsz valamit, alkalmazod, és kész. És ha újra kell indítani a Special-t? 12 másodperc alatt újraindul. (A leesett pingeket számolva mértem.)
Ha tehát a számok meggyőztek, és szeretnéd megépíteni a saját Homebrew Special-odat, csak egy PC kell hozzá, két fizikai hálózati interfésszel. Ez lehet egy speciális mini PC, mint amilyet itt használtam, vagy lehet bármilyen régi doboz, ami nálad van, és amibe bele tudsz zsúfolni két hálózati kártyát. Ne hagyja, hogy az első képernyőkép megfélemlítse. A saját, igazán gyors router építése nem is olyan nehéz. Ha pedig útitervre vágysz, akkor hamarosan felvázoljuk a folyamatot egészen a “itt egy hagyományos számítógép” szövegtől a “itt egy router, és így konfiguráld” szövegrészig.
Jim Salter (@jrssnet) író, előadó, kisvállalkozó, zsoldos rendszergazda és háromgyermekes apuka – nem feltétlenül ebben a sorrendben. Az első igazi ízelítőt a nyílt forráskódból akkor kapta, amikor 1999-ben az Apache-ot futtatta a saját dedikált FreeBSD 3.1 szerverén, és azóta is a FOSS lelkes híve. Ő hozta létre és tartja fenn a http://freebsdwiki.net és http://ubuntuwiki.net.
oldalakat is.