Ik heb de laatste tijd een trend opgemerkt. In plaats van een router te vervangen wanneer deze letterlijk stopt met werken, heb ik eerder moeten handelen – nieuwe apparatuur inruilen omdat een oude router de toenemende internetsnelheden in de omgeving niet langer kon bijhouden. (Let wel, ik ben dankbaar voor dit probleem.) Als laatste voorbeeld, een heleboel Netgear ProSafe 318G routers hebben me voor de laatste keer in de steek gelaten omdat kleine bedrijven hebben geüpgraded van 1,5-9mbps traditionele T1-verbindingen naar 50mbps coax (kabel).
Ja, coax-niet glasvezel. Zelfs coax is te veel gebleken voor de oude ProSafe serie. Deze apparaten konden het niet alleen niet bijhouden, ze vielen plat op hun gezicht. Vaak lieten de oude routers snelheidstestresultaten vallen van 9mbps met de oude verbinding tot 3mbps of minder met de 50mbps verbinding.
Heden ten dage lijken draadloze routers steeds vaker het antwoord te zijn. Deze routers zijn vaak voorzien van fraai ogend plastic en felgekleurde webinterfaces, maar bieden weinig technische functies en betrouwbaarheid. Wat moet een huurling systeembeheerder doen? Nou, in de basis kan alles met twee fysieke netwerk interfaces een router zijn. En vandaag de dag zijn er heel veel relatief snelle, goedkope, en (super belangrijk!) volledig solid-state generieke dozen op de markt.
Dus, de tijd was eindelijk gekomen. Geconfronteerd met verouderende hardware en nieuwe consumenten aanbiedingen die niet aan mijn behoeften, heb ik besloten om mijn eigen router te bouwen. En als het veranderende connectiviteitslandschap van vandaag u in een vergelijkbare positie brengt, blijkt dat zowel het bouwen als het bouwen vrij snel gaat.
Waarom het op de moeilijke manier doen
Velen van u mompelen nu waarschijnlijk, “juist, pfSense, zeker.” Sommigen van jullie denken misschien zelfs aan smoothwall of untangle NG. Ik heb gespeeld met de meeste firewall distro’s die er zijn, maar ik besloot om meer basic te gaan, meer old school: een gewone, CLI-only installatie van Ubuntu Server en een paar iptables regels.
Toegegeven, dit is waarschijnlijk niet de meest praktische aanpak voor elke lezer, maar het was zinvol voor mij. Ik heb nogal wat ervaring met het aanpassen van iptables en de Linux kernel zelf voor hoge doorvoer op Internet schaal, en hoe minder glimmende functies en graphics en klik-dingen er tussen mij en de firewall tabel komen te staan, hoe minder pluisjes ik uit de weg hoef te ruimen en hoe minder nieuwe niet-toepasbare-dingen ik hoef te leren. Elke regel die ik al in iptables kan maken om de toegang tot mijn servers te beheren, kan ik ook op mijn firewall toepassen – als mijn firewall dezelfde distro draait als mijn servers.
Ook werk ik vrij veel met OpenVPN, en ik wil zowel de servers als de clients kunnen blijven instellen op de manier waarop ik dat nu al doe. Sommige firewalldistro’s hebben OpenVPN-ondersteuning ingebouwd en sommige niet, maar zelfs degenen met ingebouwde ondersteuning verwachten dat de dingen anders lopen dan ik doe. Nogmaals, hoe meer het systeem mij uit de weg blijft, hoe gelukkiger ik zal zijn.
Als een extra bonus, weet ik dat ik heel gemakkelijk alles volledig up-to-date kan houden op mijn nieuwe en volledig vanilla Ubuntu router. Het is allemaal rechtstreeks ondersteund door Canonical, en het kan (en doet) allemaal met automatische updates ingeschakeld. Voeg af en toe een cron job toe om de router opnieuw op te starten (om nieuwe kernels te krijgen), en ik ben goud.
Hardware, hardware, hardware
We zullen de how-to in een toekomstig stuk doornemen, maar vandaag is het belangrijk om vast te stellen waarom een DIY router-build de beste optie kan zijn. Om dat te doen, moet je eerst het algemene landschap van vandaag begrijpen.
In de consumentenwereld hebben routers meestal piepkleine MIPS CPU’s onder de motorkap zonder een heleboel RAM (om het zacht uit te drukken). Deze routers onderscheiden zich grotendeels van elkaar op basis van de interface: Hoe glanzend is het? Hoeveel technische mogelijkheden heeft hij? Kunnen gebruikers het gemakkelijk uitvinden?
Aan het hogere uiteinde van de SOHO-markt, begin je een aantal smartphone-grade ARM CPU’s en veel meer RAM te zien. Deze routers, zoals de Nightgear Nighthawk-serie, waar we later op zullen hameren, hebben meerdere kernen, hogere kloksnelheden en veel meer RAM-geheugen. Ze hebben ook veel hogere prijskaartjes dan de goedkopere concurrentie. Ik kocht een Linksys EA2750 voor 89 dollar, maar de Netgear Nighthawk X6 die ik erbij kreeg, was bijna drie keer zo duur (zelfs in de uitverkoop!): 249 dollar.
Toch wilde ik een andere weg inslaan. Er zijn de laatste tijd veel interessante en redelijk goedkope kleine x86-64 ventilatorloze machines op de markt verschenen. De truc voor het bouwen van een router is er een te vinden met meerdere NICs. Je kunt een paar redelijk veilige vinden op Amazon, maar dat zijn oudere Atom gebaseerde processors, en ik wilde een nieuwere Celeron. Na wat ouderwets Internet afstruinen en treuzelen, waagde ik uiteindelijk de sprong op Alibaba en bestelde ik een nieuwe Partaker Mini PC van Shenzhen Inctel Technology Company. Na $240 voor de router zelf en nog eens $48 voor een 120GB Kingston SSD van Newegg, had ik ongeveer $40 meer uitgegeven aan de Homebrew Special dan ik had uitgegeven aan de Nighthawk. Zou het de moeite waard zijn?
Een uitdager verschijnt
Voordat we beginnen met testen, laten we eens een snelle visuele blik werpen op de concurrenten.
Die Nighthawk is, in vergelijking met de andere, enorm en indrukwekkend (nog indrukwekkender dan hij op de foto lijkt). Hij is zelfs aanzienlijk groter dan mijn Homebrew Special, wat een volledig functionele PC is die je kunt gebruiken als een perfect bureaublad. Het is alsof DC Comics H.R. Giger heeft gevraagd om een handje te helpen bij het ontwerpen van een draadloze router voor Batman.
De Homebrew Special zelf is een beetje schattig. Het heeft een blauwe en een rode LED in de behuizing, en ’s nachts, het licht van beide morst uit de koelopeningen indirect, waardoor het netwerk stack een feestelijke uitstraling. Als er ventilatoren zouden zijn die het licht laten flikkeren, zou ik gek worden, maar omdat het een constant zacht schijnsel is, vind ik het eigenlijk wel mooi.
De Linksys en de Buffalo zien er daarentegen precies zo uit als wat ze zijn: goedkope routers. De vormgeving van de Linksys is echter een grote verbetering ten opzichte van het verleden van het merk. Het ziet er meer uit als iets professioneels en minder als kinderspeelgoed. (Maar genoeg over de styling-het is tijd om deze arme routers door de handschoen te halen.)
De voor de hand liggende eerste uitdaging is een eenvoudige bandbreedte test. Je zet een computer aan de LAN kant en een computer aan de WAN kant, en je laat een handig tooltje genaamd iperf door het midden lopen. Simpel, toch?
Wel, dat zou een kort, saai artikel worden. Het netwerk zelf meet gigabit, de drie gigabit-routers meten gigabit, en de 100 megabit-router meet 100 megabit.
In werkelijkheid vertelt zo’n eenvoudige test niet eens het hele verhaal. De enige reden om het te doen kan zijn om te laten zien hoe zinloos het is. Routerfabrikanten worden zich er steeds meer van bewust dat mensen hun producten daadwerkelijk testen, en geen enkele fabrikant wil dat zijn product ergens anders dan bovenaan staat in zoiets als smallnetbuilder’s router chart. In het licht daarvan jagen fabrikanten tegenwoordig actief op statistieken.
Het probleem is dat statistieken slechts statistieken zijn. In staat zijn om een hoog nummer op een pure throughput test is beter dan niets, maar het is een verre schreeuw van het hele verhaal. Ik heb die les op de harde manier geleerd toen ik in de vroege jaren 2000 voor een T-1 leverancier werkte. Hun extreem dure Adtran modems konden het normale Internetgebruik van 50 tot 100 mensen prima aan, maar een enkele gebruiker die Limewire of een andere P2P-client draaide, zou de hele zaak in een mum van tijd platleggen. (De oplossing in die tijd: zet een goedkope-maar-geweldige $150 Netopia router voor dat dure Adtran modem. Probleem opgelost.)
Zelfs voor relatief eenvoudige routing-geen deep packet inspection, geen streaming malware scanning of intrusion detection, geen shaping-de CPU en het RAM beschikbaar voor de router zijn beide belangrijk ver boven en buiten het vermogen om de Internet link te verzadigen. Peer-to-peer filesharing is zo’n beetje de meest brute activiteit die een netwerk tegenwoordig te zien krijgt (of het nu gaat om bittorrent, een van de Gnutella of eDonkey varianten, of het peer-to-peer download systeem van een gamebedrijf). Ik was klaar met WoW tegen de tijd dat Blizzard’s P2P-distributiesysteem werd geïntroduceerd, maar mijn toenmalige kamergenoot niet. Op de dag van de lancering had het nieuwe WoW peer download systeem de standaard ingesteld op geen enkele throttling. Het probeerde vrolijk verbindingen te vinden en te onderhouden met letterlijk duizenden clients tegelijk, en mijn thuisnetwerk ging plat als Gilbert Godfried die getackeld werd door Terry Tate. Mijn kamergenoot en ik hadden woorden.
Gebaseerd op zulke ervaringen uit het verleden, wil ik mijn uitdagers niet alleen minimaal “testen” en er een punt achter zetten, ik wil ze echt laten zweten. Ik wil ze echt laten zweten. Om dat te doen, ga ik ze opzadelen met werklasten die drie probleemgebieden benadrukken: de netwerkverbinding verzadigen, heel snel individuele TCP/IP-verbindingen maken en verbreken, en een enorm aantal individuele TCP/IP-verbindingen tegelijkertijd openhouden.
Ik heb een botnet in mijn zak, en ik ben er klaar voor
Ik heb even overwogen om een of ander afzichtelijk, door Docker aangedreven gedrocht op te zetten met tienduizenden Linux-containers met individuele IP-adressen, die allemaal om verbindingen schreeuwen en/of webpagina’s aanbieden. Toen kwam ik tot bezinning. Wat de routers betreft, is er geen verschil tussen het onderhouden van verbindingen naar duizenden individuele IP-adressen of gewoon naar duizenden poorten op hetzelfde IP-adres. Ik spendeerde wat tijd om Lee Hutchinson’s favoriete webserver nginx te veranderen in een belachelijk Lovecraftiaans monster met 10.000 hoofden en een honger naar vernietiging.
Voor elke router, gebruikte ik ApacheBench om het downloaden van een jpeg te testen met drie verschillende bestandsgroottes (10K, 100K, en 1M) op vier verschillende concurrency niveaus (10, 100, 1.000, en 10.000 gelijktijdige clients). Dit geeft ons 12 tests in totaal, onze eerste iperf test niet meegerekend, en het is de moeite waard om ze allemaal als een soort spectrum te zien.
In de meeste opzichten is dat 10K bestand een grotere uitdaging. De kleine bestandsgrootte betekent dat je veel meer van de individuele bestanden per seconde kunt afleveren voordat je de interface verzadigt, wat betekent dat je veel meer TCP-verbindingen moet maken en verbreken, wat belastend is voor de CPU van de router. Aan de andere kant betekent het bestand van 1M dat je gegarandeerd meer verbindingen openhoudt op de hogere concurrency niveaus. Het is de moeite waard om te zien hoe de routers omgaan met het hele spectrum, omdat elk niveau een redelijk goed werk doet van het modelleren van een vrij veel voorkomende uitdaging die een router zou moeten aankunnen (downloaden of verzenden van een groot aantal e-mails, omgaan met peer-to-peer bestandsdeling, of algemeen surfen op het web door veel gebruikers) als het tot een extreem niveau wordt genomen.
Uiteindelijk moest ik niet alleen nginx tunen, maar ook de Linux kernel zelf, om betrouwbaar het soort doorvoer te leveren waar ik naar op zoek was. De routers zelf zijn “standaard” – zelfs mijn Homebrew Special was nog niet afgesteld – maar de test servers, Menhir, en Monolith (elk met AMD FX-8320 8-core CPU, 32GB DDR3 RAM, en Ubuntu Trusty OS volledig up to date gepatcht) hadden een aantal vrij serieuze massages nodig om dat soort belasting aan te kunnen.
Met zoveel gekkigheid, wil je er zeker van zijn waar je eigenlijke servers en netwerk toe in staat zijn, voordat je conclusies trekt over routers die je ertussen zet. Om te beginnen heb ik Menhir eerst zelf getest op de localhost-interface (helemaal geen netwerk) en daarna heb ik een test uitgevoerd tussen de servers via mijn netwerkswitch (een Netgear ProSafe 16-poorts gigabit, voor het geval je het je afvraagt).
De localhost-resultaten hadden niet beter kunnen zijn – een veel hogere doorvoer dan gigabit voor elke test. Ik moest zelfs de schaal van de Y-as van de grafiek handmatig beperken, anders zou het moeilijk zijn om de echte tests te zien. De directe netwerktest was niet zo slecht, maar we beginnen duidelijk tegen grenzen aan te lopen aan de bovenkant. Ik weet niet zeker of het de switch zelf is, of de on-board netwerk interfaces in beide servers, maar er is iets dat de uitdaging niet helemaal aan kan. Maar het is goed genoeg om mee te werken. Tijd om eindelijk de routers in te schakelen.
Let’s get ready to rumble!
Ik was een beetje nerveus. Ik was al erg gesteld op mijn zelfgebouwde apparaatje, ik had het tenslotte zelf gebouwd. Ik wist dat het de oudere Buffalo die ik uit een la had gehaald en de Linksys, die letterlijk het goedkoopste ding bij Staples was met een gigabit interface, met gemak zou overtreffen. Maar kon het die lasergeleide atomaire stoomhamer van een Nighthawk verslaan? Ik dacht van wel, maar ik wist het niet zeker.
Toen de downloadtests waren voltooid, waren er geen vragen meer over de Homebrew Special. Ja, hij kon de Nighthawk verslaan… en daarna geeuwend weglopen. Afgezien van één kleine dip op het 10K bestandsgrootte/10 gelijktijdige verbindingen niveau (dat de CPU uitdaagt met de absolute meeste gemaakte en verbroken verbindingen), presteerde het bijna identiek aan de directe netwerkverbinding zelf.
De Nighthawk, overigens, is echt een geweldige SOHO router die ik vrij veel heb ingezet. Hij viel echter vrijwel direct af. Voor megabyte downloads 10 per keer, het was nek-aan-nek. Met een meer van een uitdaging, de prestaties begon af te nemen scherp.
De Linksys, geen verrassing, presteerde niet goed op alle. Zelfs een taak zo eenvoudig als het downloaden van 10 bestanden op hetzelfde moment sneed de doorvoer tot bijna de helft van wat de naïeve iperf test liet zien. Vanaf daar werd het alleen maar erger, en het lukte zelfs niet om verschillende tests te voltooien. Aan de positieve kant laat de Linksys goed zien dat je router er echt toe doet.
Eindelijk, de dappere kleine Buffalo verdient een shout-out. Ondanks het feit dat hij minder kostte dan de Linksys toen hij gloednieuw was (acht jaar geleden, let wel) en vijf jaar in een bureaula lag weg te kwijnen, kwam hij van de spreekwoordelijke barkruk en versloeg hij de Linksys in de helft van de tests. De Buffalo had dat succes ondanks een netwerkinterface die voor een tiende van de snelheid werd geschat. Dat is moxie. De volgende keer dat iemand een goedkope steek neemt in vers-van-de-boot Chinees gemaakte producten, ga ik roepen “Vergeet de Buffalo niet!”
Alvorens conclusies te trekken, moet echter rekening worden gehouden met upload snelheden.
Gelukkig is er hier niet echt iets veranderd aan de verhoudingen tussen de routers. De Homebrew ziet er nog steeds uit alsof hij er niet eens is en komt bijna volledig overeen met een directe netwerkverbinding. De Nighthawk blijft de Linksys volkomen domineren, en de scrappy kleine Buffalo doet nog steeds zijn verouderde best. In absolute termen kun je zien dat zowel de Nighthawk als de Linksys het iets beter doen op upload dan op download, maar het is niets om over naar huis te schrijven. De bottom line blijft hetzelfde: de Homebrew Special houdt gelijke tred met het netwerk (vreemd genoeg doet hij het zelfs beter dan een directe verbinding in de 10.000 verbindingen/10K bestanden test), de Nighthawk is duidelijk zijn prijskaartje waard vergeleken met de Linksys, en de Linksys is, nou ja, goedkoop.
Met deze laatste grafiek, hebben we wel een nieuwe set resultaten, hoewel-de zalmkleurige balken, die vrij stabiel zijn op iets meer dan 200mbps over de grafiek. Dat is de Homebrew Special die zijn crypto spieren spant. Het heeft een OpenVPN server draaien. Voor deze test is de WAN-side server, Menhir, verbonden met de on-board OpenVPN server van de router. Verkeer voor de LAN kant van de Homebrew Special wordt over de VPN tunnel geleid, dus Menhir raakt het LAN IP adres van Monolith (de LAN-side server) door middel van een behoorlijk indrukwekkende 2048-bit, SSL-gebaseerde encryptie. Gezien het feit dat niemand in mijn omgeving nog Internetverbindingen boven de 200mbps aanbiedt, doet dat mijn innerlijke crypto nerd dansen van vreugde. Ik zou letterlijk elke byte van mijn internetverkeer kunnen versleutelen, in beide richtingen, zonder prestatieverlies.
Een snel slotcaveat
Zo indrukwekkend als mijn kleine Homebrew Special is, er ontbreekt één ding, dat alle drie de andere deelnemers wel bieden: draadloze toegang. Ik zou een draadloze kaart aan de Homebrew kunnen toevoegen en hem draadloos kunnen laten werken, maar dat ben ik momenteel niet van plan. Ik ben maar al te bekend met wat er beschikbaar is voor PC draadloze kaarten, en ze stinken allemaal op het ijs. Zelfs goedkope apparaten zoals de Linksys of de Buffalo zouden een klap uitdelen voor wat betreft draadloze dekking en bereik, en de Nighthawk komt niet eens in de buurt van dezelfde klasse. Het is echt een laser-geleide atomische stoomhamer als het gaat om draadloos bereik, dekking, en gelijktijdige connectiviteit. (Ik heb er een die 50+ gebruikers in een faciliteit van 53.000 vierkante meter van hoek tot hoek dekt op dit moment.)
Met dat gezegd, niets houdt je tegen om een aparte WAP (Wireless Access Point) te gebruiken, strikt om Wi-Fi-taken te vervullen. In mijn huis, zijn dat een paar Ubiquiti “hockey puck” WAP’s, een voor elke verdieping van het huis. Het is wat meer werk om ze te beheren dan de Nighthawk, maar ze kosten de helft minder. Het zijn vrij standaard Linux apparaten waar je direct op kunt SSH’en en die beheerd worden vanuit een vrij coole kleine Web applicatie die je kunt draaien… je raadt het al, direct op de Homebrew Special. (Het migreren van de Ubiquiti Server van mijn werkstation naar de Homebrew Special zal een van mijn eerste taken zijn na dit stuk, en ik zal het dan promoveren tot actief gebruik voor mijn thuiskantoor netwerk.)
In de naam van grondigheid, moeten we een gedeelde beperking observeren, iets door alle consumenten netwerk apparatuur die ik ooit heb beheerd: de wens om te rebooten na bijna elke verandering. Sommige van die reboots duren meer dan een minuut. Ik heb geen flauw idee waarom, maar wat de reden ook is, de Homebrew Special heeft geen last van deze industrie standaard. Je maakt een wijziging, je past ze toe, je bent klaar. En als je de Special opnieuw moet opstarten? Binnen 12 seconden is hij weer in de lucht. (Ik heb het getimed door het tellen van pings die wegvielen.)
Dus als de cijfers je hebben overtuigd, en je wilt je eigen Homebrew Special bouwen, dan is alles wat je nodig hebt een PC met twee fysieke netwerk interfaces. Dat kan een speciale mini PC zijn zoals degene die ik hier gebruikt heb, of het kan elke oude doos zijn die je hebt liggen en waar je twee netwerkkaarten in kunt proppen. Laat je niet intimideren door het eerste screenshot. Zelf een echt snelle router bouwen is niet zo moeilijk om onder de knie te krijgen. En als je schreeuwt om een stappenplan, in feite zullen we het proces helemaal schetsen van “hier is een gewone computer” tot “hier is een router, en hier is hoe je hem configureert” binnenkort.
Jim Salter (@jrssnet) is een auteur, publieke spreker, kleine bedrijfseigenaar, huurling sysadmin, en vader van drie – niet noodzakelijkerwijs in die volgorde. Hij kreeg voor het eerst echt de smaak van open source te pakken door Apache te draaien op zijn eigen FreeBSD 3.1 server in 1999, en sindsdien is hij een fervent voorstander van FOSS. Hij creëerde en onderhoudt ook http://freebsdwiki.net en http://ubuntuwiki.net.