Tyblog

” Mijn ideale router bouwen voor $50 ”

Nadat mijn Asus N66U het loodje legde, overwoog ik een paar opties: een andere all-in-one router, upgraden naar iets als een EdgeRouter, of iets op maat brouwen.Toen ik het Ars Technica-artikel las waarin de deugden van het bouwen van je eigen router werden benadrukt, was de kous daarmee zo’n beetje af: DIY it is.

Ik heb een beetje een psychologisch complex als het gaat om het uitrollen van mijn eigen over-engineered oplossingen, maar ik heb een aantal algemene doelen gesteld: het eindresultaat moet goedkoop, low-power, goed ondersteund door Linux, en uitbreidbaar zijn.Overigens, ARM boards voldoen aan veel van deze eisen, en sommige, zoals de Raspberry Pi, hebben zoveel community-activiteit aangewakkerd dat er grote steun is voor het ARM-platform, ook al voelt het misschien vreemd van x86.

Ik ben er in geslaagd om een apparaat in elkaar te flansen dat niet alleen spotgoedkoop is voor wat het doet, maar ook zeer capabel is. Als je interesse hebt om je eigen thuisrouter te bouwen, zal ik hier demonstreren dat dit niet alleen haalbaar is, maar ook relatief eenvoudig om te doen en een enorme hoeveelheid mogelijkheden biedt – van traffic shaping, tot netflow monitoring, tot dynamische DNS.

Ik heb het gebouwd met behulp van de espressobin, Arch Linux Arm, en Shorewall.

Deze foto toont het bord in een 3D-geprinte behuizing. Helaas is de espressobin niet populair genoeg om een grote verscheidenheid aan te kopen behuizingen te hebben zoals de Raspberry Pi heeft, maar er zijn een aantal goede modellen die 3D-geprint kunnen worden.

Als een kanttekening, de volgende documentatie is niet bedoeld als een uitgebreide stap-voor-stap gids om hetzelfde zelf te doen.Hoewel ik veel van de keuzes die in de bouw zijn gemaakt wil behandelen, zou het configureren van zoiets belangrijks als een router/firewall echt geen kopieer/plak werkje moeten zijn en zou beter losjes geleid kunnen worden door de stappen hier met een grondig begrip van hoe en waarom.

• Het Waarom
• Deel Een: Hardware
  • Wat met WiFi?
• Deel Twee: Software
  • Besturingssysteem
  • Firewall
• Deel Drie: De basisopbouw
  • OS Install
  • OS Config
  • Firewall
  • DHCP
• Part Four: Interlude
• Part Five: Upgrades
  • Netflow Monitoring
  • Traffic Shaping
• Conclusie

Het Waarom

Er zijn genoeg solide routers die je kunt kopen die geen standaard ISP bandenbranders zijn en die waarschijnlijk meer dan geschikt zouden zijn (ik kijk liefdevol naar je, EdgeRouter Lite).Dus waarom moeite met dit alles? Er zijn een aantal legitieme voordelen hier:

• Het is eigenlijk zeer betaalbaar. Mijn router heeft mijn benchmarks met vlag en wimpel doorstaan, en heeft alle mogelijkheden die ik uit Linux zou kunnen halen (en dat is een grote lijst).
• Het is veilig. Ik heb het gevoel dat er elke maand een nieuwe kwetsbaarheid wordt aangekondigd voor een randapparaat voor consumentennetwerken. Vergelijk dat met een zelfbeheerde firewall, en ik weet precies welke services zijn blootgesteld (en als iptables kapot is, heeft de wereld grotere problemen). Voor de neezeggers, de enige poort die luistert op mijn firewall is een willekeurige poort met een hoog nummer voor ssh-authenticatie met alleen publieke sleutels. Dus ja, ik denk dat het veiliger is dan een of andere Huawei consumenten router.
• Het heeft geweldige functies. Zeker, mijn espressobin kan routeren en als firewall dienen, maar ik heb er ook een aantal andere nuttige mogelijkheden in gestopt.
• Het is performant. In de kleine benchmarks die ik heb uitgevoerd, kan de espressobin echt verkeer pushen zonder te zweten.
• Het was echt leuk om te bouwen. Als je a) een nieuwe router nodig hebt of b) je tanden wilt zetten in een single-board ARM project, zou dit een goede keuze kunnen zijn.

Part One: Hardware

Technisch zou je een router kunnen samenstellen met behulp van elke computer met twee NICs, maar we kunnen het net zo goed doen met minder vermogen, een kleinere vormfactor, en betaalbaarder.ARM-printplaten zijn een schot in de roos: ze zijn supergoedkoop, krachtiger dan je zou denken, en goed ondersteund met zoveel varianten op de markt.

De bekendste mededinger is de Raspberry Pi, maar zonder twee NIC’s of gigabit-netwerken is het geen goede optie.Plus, je betaalt voor dingen zoals een GPU die niet nodig zijn in een headless netwerk device.

Het goede nieuws is dat vorig jaar de espressobin is uitgebracht, en het is super capabel.Het voelt speciaal gebouwd voor dit soort dingen: gigabit netwerken, een ingebouwde switch, en geen franje die je anders nodig zou hebben voor iets meer algemeen-purpose (er is niet eens een display uit, alleen een seriële console).

Hoewel het bord vrij jong is, ondersteunen zowel Armbian als Arch Linux Arm de hardware, en beide projecten doen het geweldig.Als je de wereld van Linux op ARM nog niet hebt verkend, is er niet veel om hier bang voor te zijn.Armbian en Arch Linux Arm bieden alles wat je nodig hebt voor aarch64 in de distributie repos, dus er is weinig dat je zult tegenkomen dat vreemd aanvoelt op een 64-bit ARM chip, en het voelt zeker de moeite waard als je de betaalbaarheid van de hardware en de lage power footprint meetelt.

Hier zijn enkele van de hoogtepunten voor mij:

• Het bord bevat een ingebouwde Topaz netwerkswitch. In mijn netwerktests is verkeer dat alleen de LAN interfaces passeert qua snelheid niet te onderscheiden van verkeer dat door een vanilla switch gaat. Als je streamt vanaf een NAS of anderszins hoge eisen stelt aan de communicatie tussen apparaten die de router passeren, kan dit een groot verschil maken.
• De seriële console is een eersteklas burger. Op mijn Raspberry Pis raakte ik soms gefrustreerd als ik naar mijn HDMI scherm moest grijpen bij het debuggen van problemen, maar de espressobin heeft een micro USB seriële poort voor gemakkelijke toegang tot de console.
• De aarch64 chip is geweldig geweest. Niet alleen heeft het alles afgehandeld wat ik er tegenaan gegooid heb, maar wist je dat het niet beïnvloed wordt door meltdown? De Cortex-A53 chips worden niet beïnvloed door de speculatieve executie bug, dus dat is een extra bonus.

Hoe zit het met WiFi?

Ik zal hier een kleine opmerking maken dat ik ook geprobeerd heb om de espressobin als een draadloos toegangspunt te gebruiken.Het bord heeft een mini PCIe slot dat zeer geschikt is voor een draadloze kaart, en hoewel het had moeten werken, kan ik definitief melden dat het niet een goed idee is.

Zonder in pijnlijke details te treden, is er een reeks problemen die het niet de moeite waard maken.Ik kon de 5Ghz banden onder geen enkel scenario aan de praat krijgen, mijn 2.4Ghz hostapd service werd elke twaalf uur of zo onbereikbaar, en de snelheden waren schokkend slecht.

In het algemeen denk ik dat dit een tekortkoming is van de espressobin hardware. Kaarten die anders goed ondersteund zouden moeten worden in Linux (sommige van de kaarten die ik getest heb waren Ath9k of Ath10k-gebaseerd) werken gewoon niet met de mPCIe interface van het bord.Zelfs de officieel aanbevolen kaarten hadden problemen – de RTL8191SE werkte met tussenpozen, en zelfs de kaart geproduceerd door Globalscale werkt niet zoals geadverteerd.Overigens, als je een goed-ondersteunde kaart op de espressobin vindt, laat dan een reactie achter op de gerelateerde forumdraad die ik gestart ben om dit probleem te bespreken.

Met dit alles gezegd hebbende, was het mijn bedoeling aan het begin van dit project om mijn AP van mijn router te scheiden, of ik uiteindelijk een espressobin zou gebruiken of niet.Het apart houden van de taken van firewalling/routing van wireless is een mooie scheiding van zorgen, en je kunt hele goede dedicated AP apparaten krijgen zonder enige functie buiten het uitzenden van een signaal om het simpel en krachtig te houden.

Voor wat het waard is, ik heb uiteindelijk een Ubiquity UniFi apparaat gekocht en ben er helemaal blij mee.

Deel Twee: Software

Er zijn twee grote keuzes hier: OS en firewalling software.

Operating System

De eerste keuze die u moet maken is of u dit met de hand wilt rollen vanaf een distributie die aarch64 ondersteunt of een vooraf gebouwde firmware-achtige oplossing wilt gebruiken zoals OpenWRT.Persoonlijk heb ik ondervonden dat wanneer ik een shrink-wrapped oplossing zoals Tomato/OpenWrt of FreeNAS gebruik voor een build, ik meestal gefrustreerd raak zonder dat ik er echt in kan komen en dingen kan tweaken, dus zal ik een Linux distributie voor algemeen gebruik gebruiken voor het besturingssysteem.

Zoals ik al eerder zei, Armbian en Arch Linux ARM ondersteunen het bord, en espressobin heeft officiële documentatie voor Ubuntu (evenals Yocto, waar ik tot nu toe niet bekend mee was).Hoewel ik je niet zal vertellen wat het beste is voor jouw gebruik, hier is waarom ik de voorkeur gaf aan Arch Linux Arm:

• Ik ben helemaal verkocht aan rollende release distributies.
• Ik ben ook verkocht aan het draaien boven op bloedende cutting-edge distro’s. In het geval van een router is het prettig om dicht bij de upstream te zijn wanneer mogelijk beveiligingsgerelateerde updates worden uitgebracht.
• Arch zal ons voorzien van een schone lei om op te bouwen zonder enige vreemde diensten. Dit betekent dat, met een minimale basis, we precies kunnen weten wat we geïnstalleerd, blootgesteld, en draaiend zullen hebben na het samenstellen van de stukken.
• Ik ken en mag de Arch Linux ARM mensen. Hi WarheadsSE!

Firewall

Enkele namen zoals PFSense komen meteen in me op, maar ik zou echt graag iets op Linux draaien, omdat ik dat veel beter ken dan een BSD (plus, de beste OS opties voor de espressobin zijn Linux-gebaseerd).

Het Linux firewall landschap is behoorlijk breed. Hoewel we vrijwel zeker iets zullen gebruiken dat op iptables is gebaseerd, zijn er genoeg diensten op hoger niveau die bovenop iptables zitten (ufw, firewalld, enz.).Hoewel je je eigen eenvoudige iptables regelset zou kunnen schrijven en daarmee aan de slag zou kunnen gaan, heb ik ervoor gekozen om een firewall service te gebruiken, omdat we op die manier wat kennis opdoen die de Linux gemeenschap heeft opgebouwd gedurende de vele jaren dat ze iptables firewalls hebben beheerd.

In het algemeen zou een goede firewalling daemon:

• in het “gezonde OSS project” profiel moeten passen. Dit betekent dat het actief moet worden onderhouden, al een tijdje bestaat, en een behoorlijke adoptie heeft.
• Vermijd complexiteit. Eenvoudige ontwerpen zijn gemakkelijker te debuggen, uit te breiden en te bedienen.
• Support enkele nice-to-have features, zoals ondersteuning voor traffic shaping en eenvoudige port forwarding configuratie.

Na een tijdje rondneuzen, kwam ik uit op Shorewall. Hier zijn enkele van de meer noemenswaardige redenen waarom ik het ben gaan gebruiken:

• De configuratie flow is compile-then-apply. Dit zorgt ervoor dat onze regelset gezond is voordat hij wordt toegepast, wat ook betekent dat er geen residente daemon is die de bronnen van het apparaat verbruikt, wat relevant is op een kleine single-board computer.
• Er is veel mooie historische kennis ingebouwd, zodat de iptables regels die worden uitgespuugd veel randgevallen aankunnen waar je normaal gesproken niet aan zou denken.
• Ik zal hier later meer over vertellen, maar packet marking en native ondersteuning voor traffic shaping maken classful qdiscs eenvoudig.

Derde deel: The Basic Build

Deze post is niet bedoeld als een uitgebreide gids, maar ik wilde de grote opsomming geven zodat het duidelijk is hoe eenvoudig dit in elkaar te zetten is.

OS Install

Deze is eenvoudig – volg gewoon de Arch Linux Arm espressobin pagina.Het is vooral belangrijk om de toegevoegde vlaggen op het mkfs.ext4 commando en aanvullende U-Boot configuratie op te merken.

OS Config

Over het algemeen zijn Arch Linux Arm installaties vrij goed ingesteld vanaf het begin. Natuurlijk wilt u een niet-root gebruiker instellen om mee te beheren die niet de standaard account is, dus vergeet niet om de alarm gebruiker uit te schakelen, alle wachtwoorden te veranderen, en het systeem te updaten.

Als een kanttekening, ik raad ten zeerste aan om het pacmatic pakket te installeren en het te gebruiken in plaats van de normale pacman.Het detecteert automatisch updates van configuratiebestanden en helpt ze samen te voegen, en inline belangrijk nieuws voor het breken van pakketwijzigingen.

Daarnaast stel ik voor om etckeeper in te stellen om je firewall configuratie bij te houden (de Arch wiki heeft een goede introductie). Ik heb de mijne ingesteld om automatisch naar een privé gehoste Gitolite repo te pushen.Om heel eerlijk te zijn, ik heb een hekel aan elke config management oplossing die er is, en bijna al onze wijzigingen zijn beperkt tot /etc, dus dit is in ieder geval goed genoeg als backup oplossing voor mij.

Noteer dat de standaard netwerk configuratie voor de espressobin goed werkt voor de router use case:

• Beide LAN interfaces, lan0 en lan1, zijn gebridged naar de br0 interface. Dit stelt ons in staat om prive-netwerk-gerichte dingen zoals dnsmasq te centraliseren op een enkele virtuele interface.
• De publiek-gerichte interface is wan. Het haalt zijn adres op van de upstream ISP via DHCP.

De enige veranderingen die nodig zijn om br0 en wan in te stellen voor onze router zijn twee toevoegingen: ten eerste, de LAN interface een statisch IP toewijzen omdat het de router zal zijn, en IP forwarding en IP masquerading inschakelen in /etc/systemd/network/br0.network:

Address=192.168.1.1/24IPForward=ipv4IPMasquerade=yes

En bevestig dat de WAN-facing interface een adres zal aanvragen bij de ISP in /etc/systemd/network/wan.network:

DHCP=yesIPForward=ipv4UseDNS=no

Ik stel hier UseDNS=no in omdat ik de voorkeur geef aan OpenNIC servers in plaats van mijn upstream ISP’s – ik zal later vermelden waar je deze moet instellen.

Firewall

De Arch Linux ARM aarch64 repositories hebben de laatste versie van Shorewall, die is wat ik gebruikte. Mijn configs zijn niet zo fancy, en als je serieus overweegt om Shorewall in te zetten met een verbinding naar het wilde internet, raad ik je ten zeerste aan om de hele inleiding van Shorewall tot een twee-interface firewall te lezen.Het behandelt de basis van hoe u dingen zou moeten opzetten met een mooie samenvatting van routing en firewalling in het algemeen.

Basically, zet u de br0 en wan interface in de juiste zones en stelt u de nodige regels in /etc/shorewall/rules in.Vergeet niet om hosts op uw LAN gebruik te laten maken van uw DNS server:

DNS(ACCEPT) loc $FW

U bevestigt dat DHCP is toegestaan op de LAN interface in het interfaces bestand.

Ik wil hier opmerken dat ik een bug tegenkwam met Shorewall tijdens mijn firewall setup die ik letterlijk de dag ervoor gepatcht vond – en Arch Linux ARM had het bijgewerkte pakket al in de upstream repositories. Score één punt voor het gebruik van up-to-date distro’s.

DHCP

dnsmasq is perfect voor een thuisrouter. Het bundelt een DNS en DHCP server in een lichtgewicht daemon die alles afhandelt wat je nodig hebt voor een klein netwerk, en het is volwassen genoeg dat er genoeg documentatie is om het precies voor dat gebruik te gebruiken.

Note: Ik heb geprobeerd om systemd’s ingebouwde DHCP server te gebruiken die je kan instellen met DHCPServer= in .network bestanden, aangezien het een lichtgewicht manier leek om een DHCP server te draaien zonder extra software. Zonder al te uitgebreid te zijn, het is het niet waard, een belangrijke reden is dat er geen manier is om huidige adresleases te vinden.

Er zijn veel opties die hier moeten worden ingesteld, maar de belangrijkste zijn:

# Listen for requests on this interfaceinterface=br0# Address range to draw fromdhcp-range=192.168.1.5,192.168.1.250,255.255.255.0,24h# Default route for clients (the address we used in /etc/systemd/network/br0.network)dhcp-option=option:router,192.168.1.1# Instead of doling out DNS servers from your upstream ISP who may do dumb# things for things like unresolvable names, you can rely on other DNS servers.# These are from OpenNIC.server=192.52.166.110server=66.70.211.246server=69.195.152.204server=158.69.239.167

Als u statische toewijzingen of aliassen nodig hebt, zijn die ook gemakkelijk toe te voegen.

Deel Vier: Intermezzo

Met de espressobin die DHCP en DNS verzoeken serveert op br0, firewalling via Shorewall, en het routeren van pakketten tussen de LAN en WAN, is het een werkende router. Op dit punt is het aansluiten van de WAN poort op de ISP upstream en de twee lan0/lan1 poorten op apparaten of een andere switch alles wat nodig is.

Hoewel, dat is slechts een begin.Als we dit echt als een router vervanging willen beschouwen, zijn er een aantal echt coole dingen die we kunnen doen om de mogelijkheden verder op te voeren, zodat het niet aanvoelt als een downgrade van iets als mijn oude Asus N66U.

Deel Vijf: Upgrades

Ik heb de volgende functies aan mijn vanilla espressobin router toegevoegd, die ik stuk voor stuk zal behandelen:

• Netflow monitoring
• Traffic shaping

Netflow monitoring

Traffic visibility is iets dat ik echt waardevol vond met mijn Asus Merlin firmware om het gebruik bij te houden.Netflow is de de facto standaard voor dit soort dingen, en van alle beschikbare opties, vind ik ipt-netflow erg goed, omdat het een native kernel module is, dus er is zeer weinig overhead en wordt zeer actief onderhouden.

Het blijkt dat ik waarschijnlijk de eerste persoon ben die het gebruikt op de aarch64 architectuur, omdat ik wat hulp heb gekregen om het ondersteund te krijgen op een aarch64 chipset.De onderhouder van het project was (en is) super ontvankelijk voor bugfixes, dus ik heb geen problemen gehad om ervoor te zorgen dat de module wordt ondersteund op de nieuwste kernels waar het Arch Linux ARM project op draait.

Het gebruik ervan is een kwestie van het installeren van het ipt-netflow-dkms-git pakket van de AUR.Het zal voor jouw kernel worden gebouwd omdat dkms geweldig is, en ik heb het volgende in /etc/modules-load.d/ipt-netflow.conf

ipt_NETFLOW

Dat zal het laden, en je configureert het in /etc/modprobe.d/ipt-netflow.conf:

options ipt_NETFLOW destination=$ip:2055 protocol=5

Waar $ip je netflow bestemming is.Tenslotte wordt het verkeer opgevangen door het in een speciaal iptables doel te laten stromen, wat direct vanuit shorewall gedaan kan worden, heel handig.In /etc/shorewall/start:

run_iptables -I INPUT -j NETFLOWrun_iptables -I FORWARD -j NETFLOWrun_iptables -I OUTPUT -j NETFLOWreturn 0

Dit leidt alle pakketten op de router om eerst het NETFLOW doel binnen te gaan voordat er iets anders gebeurt, die de pakketten verwerkt en ze terug laat stromen door de normale regels die Shorewall instelt.

Natuurlijk heeft ipt-netflow een plaats nodig om netflow logs naar toe te sturen, maar dat valt buiten het bereik van dit bericht.In mijn geval heb ik een Logstash instance draaien op mijn netwerk met de netflow module die gebeurtenissen aggregeert in een Elasticsearch cluster. Dit geeft me een aantal handige dashboards en de mogelijkheid om een grote verscheidenheid aan informatie over mijn netwerk te visualiseren.Er zijn enkele standaarddashboards:

Inclusief enkele behoorlijk coole dashboards, zoals een Geo-IP-dashboard:

De meest relevante metric waarin ik geïnteresseerd ben, is echter mijn totale bandbreedtegebruik omdat ik een antediluviaanse internetprovider heb die zich druk maakt om dataplafonds.Gelukkig is dat makkelijk met de netflow data die ik verzamel: we kunnen gewoon Elasticsearch vragen om wat velden bij elkaar op te tellen en die metrieken makkelijk te krijgen.Het volgende dashboard heeft twee visualisaties:

• De meter vergelijkt de som over de periode in kwestie met de cap die mijn ISP voor mij heeft ingesteld, zodat ik makkelijk kan zien waar mijn huidige gebruik ligt ten opzichte van de cap.
• De tijdreeks plot bandbreedte in bytes over de tijd om te zien wanneer ik die bandbreedte gebruik.

Het leuke aan deze opzet is dat, omdat we de netflow-metriek in Elasticsearch opslaan in plaats van in een andere datastore of database met tijdreeksen, ik de query’s voor deze dashboards kan richten op dingen zoals de som van totale bytes voor bepaalde CIDR-bereiken, omdat de onderliggende opslagengine (Lucene) IP-adressen van nature begrijpt.Bijvoorbeeld, de volgende query in Kibana:

NOT (netflow.dst_addr:"192.168.1.0/24" AND netflow.src_addr:"192.168.1.0/24")

Zal effectief potentieel grote stukken bandbreedte filteren die tussen hosts op mijn LAN gebeuren, zoals streaming tussen mijn Kodi host en NAS machine.Cool.

Traffic Shaping

Dit werd een vrij grote onderneming die een fascinerend konijnenhol was om in te verdwijnen.Sommige standaard en de meeste aangepaste router firmwares bieden een vorm van QoS of traffic shaping, dus ik hoopte hetzelfde te kunnen doen op mijn aangepaste router om een deel van mijn verkeer (zoals Overwatch) te beschermen tegen hoge latencies.

De wereld van QoS-technologie is een fascinerende plek.Hoewel je zou kunnen vertrouwen op een aantal eenvoudige schema’s zoals een HTB (hierarchical token bucket) filter, is de vooruitgang in pakketfiltering verrassend actief en zijn er veel interessante benaderingen.

Wat ik uiteindelijk heb geregeld was een HFSC (hierarchical fair-service curve) filter.Ik zal eerlijk zijn: de wiskunde erachter is zo buiten mijn bereik dat ik verschillende samenvattingen heb moeten lezen in een poging het te ontleden voor normale mensen, en de beste uitleg die zinvol voor mij was, was een uitstekende gist die ik tegenkwam van GitHub-gebruiker eqhmcow die de voordelen en het gebruik van HFSC in de praktijk uitlegt.

De tl;dr is dit: met een HFSC-verkeersregelklasse kun je heel effectief verkeer prioriteren en een goede balans bereiken tussen streams die veel bandbreedte en lage latencies vereisen.Het is geen magische kogel – je zult nog steeds moeten markeren welke soorten verkeer latency-gevoelig zijn – maar het heeft vrij goed voor mij gewerkt.Zonder de regels op zijn plaats, zal een Steam of Blizzard Launcher download ping tijden doden, terwijl actieve HFSC regels gracieus die zware delen van het verkeer zullen trimmen om ervoor te zorgen dat interactieve streams niet worden beïnvloed. Het is echt geweldig!

De eerder genoemde gist doet goed werk met het uitleggen hoe je je tc klassen vanaf nul kunt instellen. Shorewall kan echter eigenlijk klassevol verkeersbeheer van nature afhandelen, dus we kunnen vrij eenvoudig krachtige QoS regels instellen.De volgende configuratiebestanden zijn gebaseerd op mijn gemeten bandbreedtesnelheden, die ongeveer 230 down en 10 up zijn.

De eerste stap is het instellen van de relevante tc klassen voor elk apparaat in het tcdevices bestand:

# cat /etc/shorewall/tcdevices#INTERFACE 97%_down 90%_up options(set hfsc)wan 224mbit:200kb 9mbit hfscbr0 1000mbit:200kb 1000mbit hfsc

Hier krijgt de LAN-facing br0 interface volledige gigabit, maar de WAN interface wan krijgt 97% van zijn down snelheid en 90% van mijn beschikbare up snelheid.De redenering voor deze getallen wordt uitgelegd in de gist – we zijn in wezen deze regelset aan het herscheppen in Shorewall termen.

Volgende, definieer hoe pakketmarkeringen zullen overeenkomen met tc klassen in het tcclasses bestand:

# cat /etc/shorewall/tcclasses#INTERFACE MARK RATE CEIL PRIO OPTIONSwan:10 1 full/2:10ms:1540 full 1 tcp-ackwan:11 3 full/2:10ms:1540 full/2 2 defaultbr0:20 2 full*9/10:10ms:1540 full*9/10 1 tcp-ackbr0:21 3 115mbit:10ms:1540 224mbit 2 default

Dit zal belangrijk/interactief verkeer laten vallen in klassen die een hogere prioriteit krijgen.Natuurlijk moeten we ook de pakketten markeren die die hogere prioriteit moeten krijgen, wat wordt gedaan in mangle:

# cat /etc/shorewall/mangle# ICMP pingMARK(1-2) 0.0.0.0/0 0.0.0.0/0 icmp echo-requestMARK(1-2) 0.0.0.0/0 0.0.0.0/0 icmp echo-reply# sshMARK(1-2) 0.0.0.0/0 0.0.0.0/0 tcp ssh# Overwatch, Hearthstone, Diablo. 3478-3497 are very general RTP ports.MARK(1-2) 0.0.0.0/0 0.0.0.0/0 tcp,udp bnetgame,blizwow,6113MARK(1-2) 0.0.0.0/0 0.0.0.0/0 udp 3478-3497,5060,5062,6120,6250,12000-64000# Local trafficMARK(1-2) 192.168.1.0/24 192.168.1.0/24

Dit stelt de hoge-prioriteit markeringen (1 en 2) in die worden afgehandeld door onze tc klasse. Het voorbeeld bevat ICMP pings, ssh, sommige Blizzard spellen, en lokaal verkeer.

Het herladen van shorewall zou deze markeringen in werking moeten stellen.Het eindresultaat zou bulkverkeer zoals downloads of streams moeten toestaan zonder nadelige gevolgen voor de latentie van interactief verkeer zoals ssh, pingtijden in games, enzovoort.Mijn informele tests hebben dit bevestigd – merk op dat als je besluit dit zelf te verifiëren, je latentiepieken kunt waarnemen onmiddellijk na een initiële uitbarsting van bulkverkeer, maar HFSC grijpt snel in om limieten af te dwingen om de latentie voor interactief verkeer laag te houden.

Ik heb een paar sets benchmarks die HFSC in actie laten zien, maar hier is een klein voorbeeld: hoe ping latency wordt beïnvloed als iperf op de achtergrond wordt uitgevoerd.

Zoals u kunt zien, kunnen uitbarstingen van bulkverkeer zonder verkeersregels behoorlijk negatieve gevolgen hebben voor interactief verkeer dat gevoelig is voor hoge latencies.Met HFSC kunnen we die problemen voorkomen.

Conclusie

Ik gebruik mijn zelfgebouwde router nu al een paar maanden en hij lijkt prima te werken.Ik heb geen mysterieuze verbindingsdips, snelheidsproblemen of hardwareproblemen ondervonden gedurende de hele periode van ononderbroken gebruik, dus ik zou de bouw als een succes beschouwen.Upgrades zijn ook prima; na een normale sudo pacmatic -Syu en reboot komt het systeem weer online met alle iptables regels en andere services zoals verwacht, dus het bijhouden van de laatste kernels en andere pakketten is eenvoudig.

Om samen te vatten:

• Voor een operationeel-knap of technisch-minded persoon, is een custom router bouwen zeer goed te doen. ARM single board computers maken het goedkoop en gemakkelijk om te beginnen.
• OSS oplossingen voor firewalling, traffic shaping, en netwerk monitoring zijn volwassen en gemakkelijk om mee te werken. In het bijzonder zijn oude oplossingen zoals Shorewall en dnsmasq zeer goed gedocumenteerd en hebben vele jaren werk gestoken in hun documentatie en functieset.
• While routing + DNS + DHCP is een slam dunk, OSS WiFi kan hit or miss zijn. Uw kilometers kan variëren, maar mijn espressobin is gewoon niet een goede access point.