Tyblog

” Ihanteellisen reitittimen rakentaminen $50:llä ”

Sen jälkeen, kun Asus N66U -tietokonettani ei enää tarvinnut enää käyttää, harkitsin muutamaa vaihtoehtoa: EdgeRouteriin, tai valmistaa jotain mukautettua.Kun luin Ars Technican artikkelin, jossa kehuttiin oman reitittimen rakentamisen hyveitä, se ratkaisi asian:

Minulla on jonkinlainen psykologinen kompleksi, kun on kyse omien ylimitoitettujen ratkaisujen kehittelystä, mutta asetin joitakin yleisiä tavoitteita: lopputuloksen pitäisi olla halpa, vähävirtainen, Linuxin hyvin tukema ja laajennettavissa.ARM-levyt sopivat muuten moniin näistä vaatimuksista, ja jotkut, kuten Raspberry Pi, ovat herättäneet niin paljon yhteisön aktiivisuutta, että ARM-alustalle on suuri tuki, vaikka se voi tuntua vieraalta x86:n rinnalla.

Olen onnistunut kasaamaan laitteen, joka ei ole vain törkeän halpa siihen nähden, mitä se tekee, vaan myös erittäin kyvykäs.Jos olet kiinnostunut rakentamaan oman kotireitittimesi, osoitan tässä, että se ei ole vain mahdollista, vaan myös suhteellisen helppoa ja tarjoaa valtavan määrän hyötyjä – liikenteen muotoilusta, netflow-valvonnasta ja dynaamisesta DNS:stä.

Rakensin sen käyttäen espressobinia, Arch Linux Armia ja Shorewallia.

Tässä kuvassa piirilevy on suljettu 3d-tulostettuun koteloon. espressobin ei valitettavasti ole tarpeeksi suosittu, jotta se voisi ylpeillä laajalla valikoimalla ostettavissa olevia koteloita, kuten Raspberry Pi:llä on, mutta 3d-tulostukseen on olemassa joitakin hyviä malleja.

Sivuhuomautuksena mainittakoon, että seuraavaa dokumentaatiota ei ole tarkoitettu kattavaksi askel askeleelta -oppaaksi, jonka avulla saman asian voi tehdä itse.Vaikka haluan kattaa monia valintoja, jotka menivät rakentamiseen, jonkin niinkin tärkeän asian kuin reitittimen/palomuurin konfiguroinnin ei todellakaan pitäisi olla copy/paste-hommaa, ja se olisi parempi ohjeistaa löyhästi tämän ohjeen vaiheiden avulla, kun on perusteellinen ymmärrys siitä, miten ja miksi.

• Miksi
• Ensimmäinen osa: Laitteisto
  • Mitä WiFi:stä?
• Toinen osa: Ohjelmisto
  • Käyttöjärjestelmä
  • Palomuuri
• Kolmas osa: Perusrakenne
  • OS Install
  • OS Config
  • Firewall
  • DHCP
• Neljäs osa: Väliaika
• Viides osa: Upgrades
  • Netflow Monitoring
  • Traffic Shaping
• Conclusion

The Why

On olemassa paljon vankkoja reitittimiä, joita voit ostaa ja jotka eivät ole ISP:n varastossa olevia rengasrouttereita ja jotka luultavasti soveltuisivat paremmin kuin hyvin tähän tarkoitukseen (katson sinua rakastavasti, EdgeRouter Lite).Joten miksi vaivautua tähän kaikkeen?Tässä on joitakin oikeutettuja etuja:

• Se on itse asiassa erittäin edullinen. Reitittimeni on läpäissyt vertailuarvoni moitteetta, ja siinä on kaikki ominaisuudet, jotka voisin mahdollisesti vetää Linuxista (mikä on iso lista).
• Se on turvallinen. Minusta tuntuu, että joka kuukausi ilmoitetaan jostain kuluttajaverkon reunalaitteesta uusi haavoittuvuus. Vertaa sitä itse hallinnoituun palomuuriin, ja tiedän tarkalleen mitkä palvelut ovat alttiina (ja jos iptables on rikki, maailmalla on isompia ongelmia). Kaikille epäilijöille tiedoksi, että ainoa portti, jota palomuurini kuuntelee, on satunnainen suuri numeroinen portti vain julkisen avaimen ssh-todennusta varten. Joten kyllä, mielestäni se on turvallisempi kuin joku Huawein kuluttajareititin.
• Tässä on loistavia ominaisuuksia. Toki espressobinini voi reitittää ja toimia palomuurina, mutta olen pudottanut siihen myös muita hyödyllisiä ominaisuuksia.
• Se on suorituskykyinen. Suorittamissani vähäisissä vertailuanalyyseissä espressobin voi todella työntää liikennettä hikoilematta.
• Se oli todella hauska rakentaa. Jos a) tarvitset uuden reitittimen tai b) haluat leikata hampaitasi yhden piirilevyn ARM-projektissa, tämä voisi sopia hyvin.

Part One: Hardware

Teknisesti reitittimen voisi koota mistä tahansa tietokoneesta, jossa on kaksi verkkokorttia, mutta yhtä hyvin pärjäämme vähemmällä virralla, pienemmällä muotokertoimella ja edullisemmin.ARM-piirilevyt osuvat kohdalleen: ne ovat superhalpoja, tehokkaampia kuin luulisi ja hyvin tuettuja, sillä markkinoilla on niin monia vaihtoehtoja.

Tunnetuin kilpailija on Raspberry Pi, mutta ilman kahta verkkokorttia tai gigabittiverkkoa se ei ole hyvä vaihtoehto.Lisäksi maksat GPU:n kaltaisista asioista, jotka eivät ole välttämättömiä päättömässä verkkolaitteessa.

Hyvä uutinen on, että viime vuonna julkaistiin espressobin, ja se on superkykyinen.Se tuntuu tarkoituksenmukaisesti rakennetulta tämäntyyppiseen laitteeseen: gigabitin verkkoyhteys, sisäänrakennettu kytkin, eikä mitään hienouksia, joita muuten tarvitsisi johonkin yleiskäyttöisempään laitteeseen (siinä ei ole edes näyttöä ulos, vain sarjakonsoli).

Vaikka kortti on melko nuori, niin sekä Armbian että Arch Linux Arm tukevat laitteistoa, ja molemmat projektit tekevät hienoa työtä.Jos et ole vielä tutkinut Linuxin maailmaa ARM:llä, tässä ei ole paljon pelättävää.Armbian ja Arch Linux Arm tarjoavat kaiken tarvittavan aarch64:lle natiivisti jakelurepossa, joten et törmää juuri mihinkään sellaiseen, mikä tuntuisi vieraalta 64-bittisellä ARM-piirillä, ja se tuntuu tietysti kannattavan, kun ottaa huomioon laitteiston edullisuuden ja pienen tehojalanjäljen.

Tässä muutamia kohokohtia itselleni:

• Kortti sisältää sisäänrakennetun Topaz-verkkokytkimen. Verkkotesteissäni liikenne, joka kulkee vain LAN-liitäntöjen yli, on nopeudeltaan erottamaton vaniljakytkimen läpi kulkevasta liikenteestä. Jos suoratoistat NAS:sta tai sinulla on muuten suuria vaatimuksia reitittimen ylittävälle laitteiden väliselle viestinnälle, tällä voi olla suuri merkitys.
• Sarjakonsoli on ensimmäisen luokan kansalainen. Raspberry Pissäni turhauduin joskus, kun jouduin tavoittelemaan HDMI-näyttöä ongelmien debuggauksen yhteydessä, mutta espressobinissä on mikro-USB-sarjaportti, jonka kautta konsoliin pääsee helposti käsiksi.
• Aarch64-piiri on ollut loistava. Se ei vain ole hoitanut kaikkea, mitä olen sille heittänyt, mutta tiesitkö, että meltdown ei vaikuta siihen? Cortex-A53-piireihin ei vaikuta spekulatiivisen suorituksen bugi, joten se on lisäbonus.

Mitä WiFi:stä?

Tänään pieni huomautus, että yritin käyttää espressobinia myös langattomana tukiasemana.Piirilevyssä on mini-PCIe-korttipaikka, joka sopii hyvin langattomalle kortille, ja vaikka sen olisi pitänytkin onnistua, voin lopullisesti raportoida, että se ei ole hyvä idea.

Menemättä tuskallisiin yksityiskohtiin, on joukko ongelmia, jotka eivät tee siitä vaivan arvoista. 5 GHz:n kaistoja en saanut toimimaan missään skenaariossa, 2,4 GHz:n hostapd-palveluni ei vastannut noin kahdentoista tunnin välein, ja nopeudet olivat järkyttävän huonoja.

Yleisesti uskon, että tämä on espressobin-laitteiston vika. kortit, joiden pitäisi muuten olla hyvin tuettuja Linuxissa (osa testaamistani korteista oli ath9k tai ath10k-pohjaisia) eivät yksinkertaisesti toimi kortin mPCIe-liitännän kanssa.Jopa virallisesti suositelluilla korteilla oli ongelmia – RTL8191SE toimi ajoittain, ja jopa Globalscalen valmistama kortti ei toimi kuten mainostetaan.Muuten, jos löydät hyvin tuetun kortin espressobiniin, vastaa siihen liittyvään foorumiketjuun, jonka aloitin keskustellakseni tästä asiasta.

Kaiken tämän sanottuani tarkoitukseni oli projektin alussa erottaa AP:ni reitittimestä riippumatta siitä, päädyinkö lopulta käyttämään espressobinia vai en.Palomuurin/reitityksen tehtävien pitäminen erillään langattomasta on mukava huolenaiheiden erottaminen, ja voit saada erittäin hyviä dedikoituja AP-laitteita, joilla ei ole muita toimintoja kuin signaalin lähettäminen, jotta se pysyisi yksinkertaisena ja tehokkaana.

Päädyin lopulta ostamaan Ubiquity UniFi -laitteen, ja olen ollut siihen täysin tyytyväinen.

Kakkososa: Ohjelmistot

Tässä kohtaa on kaksi suurta vaihtoehtoa: Käyttöjärjestelmä ja palomuuriohjelmisto.

Käyttöjärjestelmä

Ensimmäinen valinta on se, haluatko tehdä tämän käsin jostain aarch64:ää tukevasta jakelusta vai haluatko käyttää valmiiksi rakennettua firmwarea muistuttavaa ratkaisua, kuten OpenWRT:tä.Itse olen huomannut, että aina kun käytän Tomaton/OpenWrtin tai FreeNASin kaltaista kutistettua ratkaisua rakentamiseen, turhaudun yleensä ilman, että pääsen kunnolla säätämään asioita, joten käytän käyttöjärjestelmänä yleiskäyttöistä Linux-jakelua.

Kuten aiemmin mainitsin, Armbian ja Arch Linux ARM tukevat levyä, ja espressobinilla on virallista dokumentaatiota Ubuntulle (sekä Yoctolle, jota en tuntenut tähän asti).Vaikka en aio kertoa, kumpi on paras käyttötapaukseesi, tässä kerrotaan, miksi suosin Arch Linux Armia:

• Olen täysin myyty rullaaviin julkaisujakeluihin.
• Olen myös myyty käyttämään atop bleeding cutting-edge -distroja. Reitittimen tapauksessa on mukavaa olla lähellä upstreamia, kun mahdollisesti tietoturvaan liittyviä päivityksiä julkaistaan.
• Arch tarjoaa meille puhtaan pohjan, jonka päälle voimme rakentaa ilman mitään ylimääräisiä palveluita. Tämä tarkoittaa sitä, että minimaalisella pohjalla voimme tietää tarkalleen, mitä meillä on asennettuna, altistettuna ja käynnissä palasten kokoamisen jälkeen.
• Tunnen ja pidän Arch Linuxin ARM-ihmisistä. Hei WarheadsSE!

Firewall

Joitain nimiä kuten PFSense tulee heti mieleen, mutta haluaisin oikeasti ajaa jotain Linuxilla, koska tunnen sen paljon paremmin kuin BSD:n (plus, parhaat käyttöjärjestelmävaihtoehdot espressobinille ovat Linux-pohjaisia).

Linuxin palomuurimaisema on melko laaja. vaikka käytämme lähes varmasti jotain iptables-pohjaista, on olemassa paljon korkeamman tason palveluita, jotka istuvat iptablesin päällä (ufw, firewalld, jne.)Vaikka voisitkin kirjoittaa oman yksinkertaisen iptables-sääntökokoelman ja mennä sen kanssa, päätin käyttää palomuuripalvelua, koska näin saamme mukavaa heimotietämystä, jota Linux-yhteisö on kasvattanut monien vuosien aikana, kun he ovat hallinnoineet iptables-palomuureja.

Yleisesti ottaen hyvän palomuurihallintodemonin pitäisi:

• Sopivuusprofiiliin sopia. Tämä tarkoittaa, että sitä tulisi ylläpitää aktiivisesti, sen tulisi olla ollut olemassa jo jonkin aikaa ja sillä tulisi olla kunnollinen hyväksyntä.
• Välttää monimutkaisuutta. Yksinkertaiset mallit ovat helpompia debugata, laajentaa ja käyttää.
• Tukea joitain mukavia ominaisuuksia, kuten tuki liikenteen muotoilulle ja helppo portinohjauksen konfigurointi.

Kierreltyäni jonkin aikaa, päädyin Shorewalliin.Seuraavassa on joitain merkittävimpiä syitä, joiden vuoksi päädyin siihen:

• Konfigurointivirtaus on compile-then-apply. Tämä varmistaa, että sääntökokonaisuutemme on järkevä ennen sen soveltamista, mikä tarkoittaa myös sitä, että laitteen resursseja ei kuluta mikään residenttidemoni, mikä on merkityksellistä pienessä yhden piirilevyn tietokoneessa.
• Se sisältää paljon mukavaa historiatietoa sisäänrakennettuna, joten iptables-säännöt, jotka sylkevät ulos, käsittelevät monia ääritapauksia, joita et normaalisti ajattelisi.
• Kerron tästä lisää myöhemmin, mutta pakettien merkitseminen ja natiivituki liikenteen muotoilulle tekevät luokkakohtaisista qdisceistä helppoja.

Kolmas osa: Tämä postaus ei ole tarkoitettu kattavaksi oppaaksi, mutta halusin sisällyttää siihen pääkohdat, jotta on selvää, kuinka helppoa tämä on koota.

OS-asennus

Tämä on helppoa – seuraa vain Arch Linux Arm espressobin -sivua. on erityisen tärkeää huomioida lisätyt liput mkfs.ext4-komennossa ja ylimääräinen U-Boot-konfiguraatio.

OS Config

Yleisesti Arch Linux Arm -asennukset ovat melko hyvin valmiina heti alusta alkaen.Tietenkin haluat määrittää muunkin kuin root-käyttäjän hallinnointia varten, joka ei ole oletustili, joten muista poistaa alarm-käyttäjä käytöstä, vaihtaa kaikki salasanat ja päivittää järjestelmä.

Sivuhuomautuksena suosittelen lämpimästi asentamaan pacmatic-paketin ja käyttämään sitä tavanomaisen pacman:n sijasta.Se havaitsee automaattisesti konfiguraatiotiedostojen päivitykset ja auttaa niiden yhdistämisessä sekä riviin tärkeät uutiset rikkovista pakettimuutoksista.

Lisäksi suosittelen etckeeperin asentamista seuraamaan palomuurin konfiguraatiota (Archin wikissä on hyvä esittely). minä asensin omani työntämään automaattisesti yksityisesti isännöidylle gitolite-repolle.Ollakseni täysin rehellinen, inhoan kaikkia olemassa olevia konfiginhallintaratkaisuja, ja lähes kaikki muutoksemme rajoittuvat /etc:iin, joten tämä on ainakin minulle riittävän hyvä vararatkaisu.

Huomaa, että espressobinin oletusverkkokonfiguraatio toimii hyvin reitittimen käyttötapauksessa:

• Kummatkin lan-liitännät, lan0 ja lan1, sillataan liitäntään br0. Näin voimme keskittää yksityiseen verkkoon suuntautuvat asiat, kuten dnsmasq, yhteen virtuaaliseen rajapintaan.
• Julkiseen verkkoon suuntautuva rajapinta on wan. Se hakee osoitteensa ylemmältä ISP:ltä DHCP:n kautta.

Ainoat muutokset, joita tarvitaan, jotta br0 ja wan saadaan asetettua reitittimellemme, ovat kaksi lisäystä: ensinnäkin LAN-rajapinnalle annetaan staattinen IP-osoite, koska se toimii reitittimenä, ja otetaan käyttöön IP-tiedonsiirto (forwarding) ja IP-masquerading (IP-masquerading) /etc/systemd/network/br0.network:ssä:

Address=192.168.1.1/24IPForward=ipv4IPMasquerade=yes

Ja vahvista, että WAN-liitäntä pyytää osoitteen ISP:ltä kohdassa /etc/systemd/network/wan.network:

DHCP=yesIPForward=ipv4UseDNS=no

Asetan UseDNS=no tähän, koska käytän mieluummin OpenNIC-palvelimia upstream ISP:n palvelimien sijaan – mainitsen myöhemmin, mihin nämä asetetaan.

Firewall

Arch Linux ARM aarch64 -repositorioissa on uusin versio Shorewallista, jota käytin. konfiguraationi eivät ole kovin hienoja, ja jos vakavasti harkitset Shorewallin käyttöönottoa villin internet-yhteyden kanssa, suosittelen lämpimästi lukemaan koko Shorewallin esittelyn kahden rajapinnan palomuurista.Se kattaa perusasiat siitä, miten asiat pitäisi asettaa, ja sisältää mukavan yhteenvedon reitityksestä ja palomuurista yleensä.

Periaatteessa laitat br0– ja wan-liitännät oikeisiin vyöhykkeisiin ja asetat kaikki tarvittavat säännöt /etc/shorewall/rules:een.Muista antaa lähiverkon isäntien käyttää DNS-palvelinta:

DNS(ACCEPT) loc $FW

Vahvistat, että DHCP on sallittu lähiverkon liitännässä interfaces-tiedostossa.

Huomauttaisin tässä yhteydessä, että törmäsin palomuuria asentaessani Shorewallin kanssa bugiin, jonka löysin korjatuksi kirjaimellisesti edellisenä päivänä – ja Arch Linux ARM:llä oli päivitetty paketti jo upstream-tietovarastoissa. pisteet yhden pisteen siitä, että käytät ajantasaisia distroja.

DHCP

dnsmasq sopii täydellisesti kotireitittimeen.Se niputtaa DNS- ja DHCP-palvelimen yhteen kevyeksi daemoniksi, joka hoitaa kaiken, mitä pienessä verkossa tarvitaan, ja se on sen verran kehittynyt, että on olemassa runsaasti dokumentaatiota, jossa sitä käytetään juuri tuohon käyttötarkoitukseen.

Huom: Yritin käyttää systemd:n sisäänrakennettua DHCP-palvelinta, jonka voit asettaa DHCPServer=:llä .network-tiedostoissa, koska se vaikutti kevyeltä tavalta käyttää DHCP-palvelinta ilman ylimääräisiä ohjelmistoja.Ilman, että olisin liian yksityiskohtainen, se ei ole sen arvoinen, koska yksi merkittävä syy on se, ettei ole mitään tapaa löytää nykyisiä osoitteiden vuokrasopimuksia.

Tässä on paljon asetuksia, jotka kannattaa asettaa, mutta tärkeimmät ovat:

# 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

Jos tarvitset staattisia määrityksiä tai aliaksia, nekin on helppo lisätä.

Part Four: Interlude

Kun espressobin palvelee DHCP- ja DNS-pyyntöjä osoitteessa br0, toimii palomuurina Shorewallin kautta ja reitittää paketteja LAN:n ja WAN:n välillä, kyseessä on toimiva reititin. tässä vaiheessa WAN-portin kytkeminen ISP:n ylävirtaan ja kahden lan0/lan1-portin kytkeminen laitteisiin tai johonkin muuhun kytkimeen on kaikki mitä tarvitaan.

Tämä on kuitenkin vasta alkua.Jos haluamme todella pitää tätä reitittimen korvaajana, voimme tehdä joitain todella hienoja asioita, joilla voimme parantaa sen ominaisuuksia entisestään, jotta se ei tunnu huonommalta kuin vaikkapa vanha Asus N66U:ni.

Viides osa: Päivitykset

Lisäsin vaniljaiseen espressobin-reitittimeeni seuraavat ominaisuudet, joita käsittelen kutakin vuorollaan:

• Netflow-seuranta
• Traffic shaping

Netflow-seuranta

Traffic-näkyvyyttä pidin todella arvokkaana Asus Merlin -firmaohjelmistossani, jolla pystyn seuraamaan käyttöä.Netflow on de facto standardi tällaiselle asialle, ja kaikista saatavilla olevista vaihtoehdoista pidän todella ipt-netflowsta, koska se on natiivi kernel-moduuli, joten siinä on hyvin vähän yleiskustannuksia ja sitä ylläpidetään hyvin aktiivisesti.

Kävi ilmi, että olen luultavasti ensimmäinen henkilö, joka käyttää sitä aarch64-arkkitehtuurilla, koska sain apua saadakseni sen tuetuksi aarch64-piirisarjalla. projektin ylläpitäjä oli (ja on ollut) erittäin reagoiva bugikorjauksiin, joten minulla ei ole ollut mitään ongelmia sen varmistamisessa, että moduuli on tuettu viimeisimmillä ytimillä, joilla Arch Linuxin ARM-projekti pyörii.

Sen käyttäminen onnistuu asentamalla AUR:stä löytyvä ipt-netflow-dkms-git-paketti.Se rakennetaan sinun ytimellesi, koska dkms on mahtava, ja pudotin seuraavan /etc/modules-load.d/ipt-netflow.conf

ipt_NETFLOW

Se lataa sen, ja konfiguroit sen /etc/modprobe.d/ipt-netflow.conf:

options ipt_NETFLOW destination=$ip:2055 protocol=5

Jossa $ip on netflow-kohteesi.Lopuksi liikenne kaapataan virtaamalla erityiseen iptables-kohteeseen, mikä onnistuu kätevästi suoraan shorewallista.Kohdassa /etc/shorewall/start:

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

Tämä ohjaa kaikki reitittimellä tulevat paketit ensin NETFLOW-kohteeseen ennen mitään muuta, joka käsittelee paketit ja ohjaa ne takaisin virtaamaan Shorewallin asettamien normaalien sääntöjen läpi.

ipt-netflow tarvitsee tietysti paikan, jonne voi lähettää netflow-lokit, mutta se ei kuulu tähän postaukseen.Omassa tapauksessani minulla on Logstash-instanssi käynnissä verkossa, jossa netflow-moduuli on käynnissä ja joka aggregoi tapahtumia Elasticsearch-klusterissa. näin saan käteviä kojelautoja ja mahdollisuuden visualisoida monenlaista tietoa verkostani.Mukana on joitakin oletusarvoisia kojelautoja:

Sisältää joitakin melko hienoja, kuten Geo-IP-kojelaudan:

Vaikka, merkityksellisin metriikka, josta olen kiinnostunut, on kaistanleveyden kokonaiskäyttö, koska minulla on antidiluvialainen Internet-palveluntarjoaja, joka välittää datakapeista.Onneksi se on helppoa keräämilläni netflow-tiedoilla: voimme vain pyytää Elasticsearchia laskemaan yhteen joitakin kenttiä ja saada nämä mittarit helposti.Seuraavassa kojelaudassa on kaksi visualisointia:

• Mittarissa verrataan summaa kyseiseltä ajanjaksolta kattoon, jonka ISP:ni on asettanut minulle, joten näen helposti, missä tämänhetkinen käyttöni sijoittuu kattoon nähden.
• Aikasarjassa kaistanleveyttä piirretään tavuina ajan funktiona nähdäkseni, milloin käytän kyseistä kaistanleveyttä.

Tämässä kokoonpanossa on erityisen hienoa se, että koska tallennamme netflow-mittarit Elasticsearchiin jonkin muun tietovaraston tai aikasarjatietokannan sijasta, voin itse asiassa tarkentaa näiden mittaristojen kyselyt, jotta voin esimerkiksi laskea yhteen vain kokonaistavuja tietyille CIDR-alueille, koska taustalla oleva tallennusmoottori (Lucene) ymmärtää IP-osoitteita natiivisti.Esimerkiksi seuraava kysely Kibanassa:

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

Suodattaa tehokkaasti pois potentiaalisesti suuret kaistanleveyden möhkäleet, jotka tapahtuvat lähiverkkoni isäntien välillä, kuten suoratoisto Kodi-isäntäni ja NAS-koneeni välillä.Siistiä.

Traffic Shaping

Tämästä tuli melko massiivinen hanke, joka oli kiehtova kaninkuoppa katoamiseen.Jotkin varasto- ja useimmat kustomoidut reititinfirmwaret tarjoavat jonkinlaisen QoS:n tai liikenteen muotoilun, joten toivoin voivani tehdä saman kustomoidulla reitittimelläni suojellakseni osaa liikenteestäni (kuten Overwatchia) suurilta latensseilta.

QoS-teknologian maailma on kiehtova paikka.Vaikka voisit luottaa joihinkin yksinkertaisiin skeemoihin, kuten HTB-suodattimeen (hierarchical token bucket), pakettisuodatuksen kehitys on yllättävän aktiivista ja mielenkiintoisia lähestymistapoja on paljon.

Mihin lopulta päädyin oli HFSC-suodatin (hierarchical fair-service curve).Olen rehellinen: sen taustalla oleva matematiikka on niin ylivoimaista, että jouduin lukemaan useita tiivistelmiä, joissa sitä yritettiin selittää tavallisille ihmisille, ja paras selitys, joka oli minulle järkevä, oli erinomainen gist, johon törmäsin GitHub-käyttäjä eqhmcow:lta, joka selittää HFSC:n hyödyt ja käytön käytännössä.

Tl;dr on tämä: HFSC-liikenteenohjausluokan avulla voit hyvin tehokkaasti priorisoida liikennettä ja saavuttaa hyvän tasapainon suurta kaistanleveyttä ja matalaa latenssia vaativien virtojen välillä. se ei ole taikaluoti – sinun täytyy edelleen merkitä, minkä tyyppinen liikenne on latenssiherkkää – mutta se on toiminut melko hyvin minulle.Ilman sääntöjä Steam- tai Blizzard Launcher -lataus tappaa ping-aikoja, kun taas aktiiviset HFSC-säännöt leikkaavat sulavasti nämä raskaat liikenneosuudet varmistaakseen, että vuorovaikutteiset streamit eivät kärsi.Se on todella hienoa!

Edellä mainitussa gistissä kerrotaan hyvin, miten tc-luokkia määritetään tyhjästä.Shorewall pystyy kuitenkin itse asiassa käsittelemään luokkakohtaista liikenteenohjausta natiivisti, joten voimme määrittää tehokkaat QoS-säännöt melko helposti.Seuraavat konfigurointitiedostot perustuvat mitattuihin kaistanleveysnopeuksiini, jotka ovat noin 230 alaspäin ja 10 ylöspäin.

Aluksi asetetaan asiaankuuluvat tc-luokat kullekin laitteelle tcdevices-tiedostossa:

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

Tässä lähiverkkoon päin oleva br0-rajapinta saa täydet gigabitit, mutta WAN-rajapinta wan saa 97 % alaspäin menevästä nopeudestaan ja 90 % käytettävissä olevasta ylöspäin menevästä nopeudesta.Näiden lukujen perustelut on selitetty gistissä – me lähinnä luomme tämän sääntökokonaisuuden uudelleen Shorewallin ehdoilla.

Seuraavaksi määritetään, miten pakettimerkinnät liitetään tc-luokkiin tcclasses-tiedostossa:

# 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

Tämä pudottaa tärkeän/interaktiivisen liikenteen luokkiin, jotka saavat korkeamman prioriteetin.Meidän on tietysti myös merkittävä paketit, joiden pitäisi saada tämä korkeampi prioriteetti, mikä tehdään kohdassa 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

Tämä asettaa korkean prioriteetin merkinnät (1 ja 2), jotka meidän tc-luokkamme käsittelee. esimerkki sisältää ICMP-pingit, ssh:n, jotkin Blizzardin pelit ja paikallisen liikenteen.

Shorewallin uudelleenlataamisen pitäisi ottaa nämä käyttöön.Lopputuloksen pitäisi sallia massaliikenne, kuten lataukset tai streamit, mutta ei vaikuta haitallisesti vuorovaikutteisen liikenteen latenssiin, kuten ssh:n, pelin sisäisten ping-aikojen ja niin edelleen.Epäviralliset testini ovat vahvistaneet tämän – huomaa, että jos päätät tarkistaa tämän itse, saatat havaita latenssipiikkejä heti massaliikenteen alkupurkauksen jälkeen, mutta HFSC puuttuu tilanteeseen nopeasti pakottaakseen rajoitukset pitämään interaktiiviselle liikenteelle asetetut latenssit pieninä.

Minulla on pari sarjaa vertailuarvoja, jotka näyttävät HFSC:n toiminnassa, mutta tässä on pieni esimerkki: miten ping-viiveet vaikuttavat, kun iperfiä ajetaan taustalla.

Kuten näette, ilman mitään liikenteenohjaussääntöjä, massaliikenteen purskeilla voi olla melko kielteisiä vaikutuksia interaktiiviseen liikenteeseen, joka on herkkä suurille viiveille.HFSC:n avulla voimme välttää nämä ongelmat.

Johtopäätös

Olen käyttänyt itse valmistamaani reititintä jo useamman kuukauden ajan, ja se näyttää toimivan hyvin.En ole kokenut yhtään mystistä yhteyden katkeamista, nopeusongelmia tai laitteisto-ongelmia koko yhtäjaksoisen käytön aikana, joten pitäisin rakentamista onnistuneena.Myös päivitykset sujuvat hienosti; normaalin sudo pacmatic -Syu ja uudelleenkäynnistyksen jälkeen järjestelmä palaa takaisin verkkoon ja kaikki iptables-säännöt ja muut palvelut toimivat odotetusti, joten uusimpien ytimien ja muiden pakettien pitäminen ajan tasalla on suoraviivaista.

Yhteenvetona:

• Toimintoihin perehtyneelle tai teknisesti perehtyneelle henkilölle mukautetun reitittimen rakentaminen on hyvin tehtävissä. ARM-korttitietokoneet tekevät aloittamisesta halpaa ja kätevää.
• OSS-ratkaisut palomuuriin, liikenteen muotoiluun ja verkonvalvontaan ovat kehittyneitä ja helppoja käyttää. Erityisesti Shorewallin ja dnsmasqin kaltaiset hienosti vanhentuneet ratkaisut ovat hyvin dokumentoituja, ja niiden dokumentaatioon ja ominaisuuksiin on panostettu useita vuosia.
• Vaikka reititys + DNS + DHCP on helppo juttu, OSS WiFi voi olla osuma tai huti. Your mileage may vary, mutta minun espressobin ei vain ole hyvä access point.