Tyblog

” Costruire il mio router ideale per 50 dollari ”

Dopo che il mio Asus N66U ha tirato le cuoia, ho considerato alcune opzioni: un altro router all-in-one, passare a qualcosa come un EdgeRouter, o creare qualcosa di personalizzato.Quando ho letto l’articolo di Ars Technica che esponeva le virtù di costruire il proprio router, questo mi ha fatto decidere: DIY sia.

Ho un po’ un complesso psicologico quando si tratta di rollare le mie soluzioni troppo ingegnerizzate, ma ho fissato alcuni obiettivi generali: il risultato finale dovrebbe essere economico, a basso consumo, ben supportato da Linux, ed estensibile.Per inciso, le schede ARM soddisfano molti di questi requisiti, e alcune come il Raspberry Pi hanno suscitato così tanta attività della comunità che c’è grande supporto per la piattaforma ARM, anche se può sembrare estranea alla x86.

Sono riuscito a mettere insieme un dispositivo che non solo è molto economico per quello che fa, ma è estremamente capace di per sé. Se siete interessati a costruire il vostro router domestico, dimostrerò qui che farlo non solo è fattibile, ma relativamente facile da fare e offre una quantità enorme di utilità – dal traffic shaping, al monitoraggio netflow, al DNS dinamico.

L’ho costruito usando espressobin, Arch Linux Arm, e Shorewall.

Questa foto mostra la scheda racchiusa in un case stampato in 3d.Sfortunatamente, l’espressobin non è abbastanza popolare da vantare una grande varietà di case acquistabili come il Raspberry Pi, ma ci sono alcuni buoni modelli là fuori per la stampa 3d.

Come nota a margine, la seguente documentazione non è intesa come una guida completa passo dopo passo per fare la stessa cosa da soli.Anche se voglio coprire molte delle scelte che sono andate nella costruzione, la configurazione di qualcosa di così importante come un router/firewall non dovrebbe essere un lavoro di copia/incolla e sarebbe meglio essere vagamente guidati dai passi qui con una comprensione approfondita del come e perché.

• Il perché
• Parte prima: Hardware
  • E il WiFi?
• Parte seconda: Software
  • Sistema operativo
  • Firewall
• Parte terza: La costruzione di base
  • Installazione dell’OS
  • Config dell’OS
  • Firewall
  • DHCP
• Parte quarta: Interludio
• Parte quinta: Aggiornamenti
  • Netflow Monitoring
  • Traffic Shaping
• Conclusione

Il Perché

Ci sono un sacco di router solidi là fuori che puoi comprare e che non sono fuochi di gomma ISP di serie e probabilmente sarebbero più che adatti (ti sto guardando con amore, EdgeRouter Lite).Quindi perché preoccuparsi di tutto questo? Ci sono alcuni benefici legittimi qui:

• E’ davvero molto conveniente. Il mio router ha superato i miei benchmark a pieni voti, e ha tutte le caratteristiche che potrei prendere da Linux (che è una grande lista).
• È sicuro. Mi sembra che ogni mese venga annunciata una nuova vulnerabilità per qualche dispositivo di rete di consumo. Confrontalo con un firewall autogestito, e so esattamente quali servizi sono esposti (e se iptables è rotto, il mondo ha problemi più grandi). Per tutti i detrattori, a proposito, l’unica porta in ascolto sul mio firewall è una porta casuale ad alto numero per l’autenticazione ssh a chiave pubblica. Quindi sì, penso che sia più sicuro di qualche router Huawei consumer.
• Ha grandi caratteristiche. Certo, il mio espressobin può instradare e servire da firewall, ma ho inserito anche altre utili funzionalità.
• È performante. Nei benchmark minori che ho eseguito, l’espressobin può davvero spingere il traffico senza sudare.
• È stato davvero divertente da costruire. Se a) hai bisogno di un nuovo router o b) vuoi farti le ossa con un progetto ARM a scheda singola, questo potrebbe essere una buona soluzione.

Parte Uno: Hardware

Tecnicamente si potrebbe mettere insieme un router usando qualsiasi computer con due NIC, ma possiamo fare altrettanto bene con meno potenza, un fattore di forma più piccolo, e più economicamente.Le schede ARM colpiscono nel segno: sono super economiche, più potenti di quanto si pensi, e ben supportate con così tante varianti sul mercato.

Il concorrente più noto è il Raspberry Pi, ma senza due NIC o una rete gigabit, non è una buona opzione.Inoltre, stai pagando per cose come una GPU che non sono necessarie in un dispositivo di rete senza testa.

La buona notizia è che l’anno scorso è stato rilasciato l’espressobin, ed è super capace.Sembra fatta apposta per questo tipo di cose: rete gigabit, uno switch integrato, e nessun fronzolo di cui altrimenti avreste bisogno per qualcosa di più generico (non c’è nemmeno un display, solo una console seriale).

Anche se la scheda è abbastanza giovane, sia Armbian che Arch Linux Arm supportano l’hardware, ed entrambi i progetti fanno un ottimo lavoro.Se non avete esplorato il mondo di Linux su ARM, non c’è molto da temere.Armbian e Arch Linux Arm forniscono tutto il necessario per aarch64 nativamente nei repo della distribuzione, quindi c’è poco in cui ti imbatterai che ti sembrerà estraneo su un chip ARM a 64 bit, e sicuramente ne vale la pena quando si considera l’accessibilità dell’hardware e il basso consumo energetico.

Ecco alcuni dei punti salienti per me:

• La scheda include uno switch di rete Topaz integrato. Nei miei test di rete, il traffico che attraversa solo le interfacce LAN è indistinguibile in termini di velocità dal traffico che passa attraverso uno switch vanilla. Se fai streaming da un NAS o hai altri requisiti elevati per la comunicazione tra dispositivi che attraversano il router, questo può fare una grande differenza.
• La console seriale è un cittadino di prima classe. Sui miei Raspberry Pis, a volte mi sentivo frustrato nel dover raggiungere il mio display HDMI per il debug dei problemi, ma l’espressobin ha una porta seriale micro USB per un facile accesso alla console.
• Il chip aarch64 è stato fantastico. Non solo ha gestito tutto ciò che gli ho gettato addosso, ma sapevate che non è influenzato da Meltdown? I chip Cortex-A53 non sono colpiti dal bug dell’esecuzione speculativa, quindi questo è un ulteriore bonus.

Che mi dici del WiFi?

Farò una piccola nota qui che ho tentato di usare l’espressobin anche come punto di accesso wireless.La scheda ha uno slot mini PCIe adatto per una scheda wireless, e anche se avrebbe dovuto funzionare, posso definitivamente segnalare che non è una buona idea.

Senza entrare in dettagli dolorosi, c’è una serie di problemi che non ne vale la pena: non ho potuto far funzionare le bande a 5Ghz in nessuno scenario, il mio servizio hostapd a 2.4Ghz non rispondeva ogni dodici ore circa, e la velocità era scioccamente cattiva.

In generale, penso che questo sia un difetto dell’hardware espressobin: schede che dovrebbero essere ben supportate in Linux (alcune delle schede che ho testato erano basate su ath9k o ath10k) semplicemente non funzionano con l’interfaccia mPCIe della scheda.Anche le schede raccomandate ufficialmente hanno avuto problemi – la RTL8191SE avrebbe funzionato a intermittenza, e anche la scheda prodotta da Globalscale non funziona come pubblicizzato.Tra l’altro, se trovi una scheda ben supportata sull’espressobin, per favore lascia una risposta sul thread del forum correlato che ho iniziato per discutere questo problema.

Con tutto ciò che è stato detto, il mio intento all’inizio di questo progetto era di separare il mio AP dal mio router, sia che finissi per usare un espressobin o no.Mantenere i compiti di firewalling/routing separati dal wireless è una bella separazione di preoccupazioni, e si possono ottenere ottimi dispositivi AP dedicati senza alcuna funzione al di fuori della trasmissione di un segnale per mantenerlo semplice e potente.

Per quello che vale, ho finito per acquistare un dispositivo Ubiquity UniFi e ne sono stato totalmente soddisfatto.

Parte Due: Software

Ci sono due grandi scelte qui: Sistema operativo e software di firewalling.

Sistema operativo

La prima scelta da fare è se si vuole fare questo a mano da una distribuzione che supporta aarch64 o utilizzare una soluzione precostruita tipo firmware come OpenWRT.Personalmente, ho scoperto che ogni volta che uso una soluzione compatta come Tomato/OpenWrt o FreeNAS per una build, di solito mi sento frustrato senza essere in grado di entrare davvero e modificare le cose, quindi userò una distribuzione Linux generale per il sistema operativo.

Come ho detto in precedenza, Armbian e Arch Linux ARM supportano la scheda, ed espressobin ha la documentazione ufficiale per Ubuntu (così come Yocto, che non conoscevo fino ad ora).Anche se non vi dirò quale sia il migliore per il vostro caso d’uso, ecco perché ho preferito Arch Linux Arm:

• Sono totalmente convinto delle distribuzioni rolling release.
• Sono anche convinto di eseguire una distro all’avanguardia. Nel caso di un router, è bello essere vicini all’upstream quando vengono rilasciati aggiornamenti potenzialmente legati alla sicurezza.
• Arch ci fornirà una lavagna pulita su cui costruire senza alcun servizio estraneo. Questo significa che, con una base minima, possiamo sapere esattamente cosa avremo installato, esposto e funzionante dopo aver messo insieme i pezzi.
• Conosco e mi piace la gente di Arch Linux ARM. Ciao WarheadsSE!

Firewall

Alcuni nomi come PFSense mi vengono subito in mente, ma mi piacerebbe davvero far girare qualcosa su Linux dato che lo conosco molto meglio di un BSD (inoltre, le migliori opzioni OS per l’espressobin sono basate su Linux).

Il panorama dei firewall di Linux è piuttosto ampio; anche se quasi certamente useremo qualcosa basato su iptables, ci sono un sacco di servizi di livello superiore che stanno sopra iptables (ufw, firewalld, ecc.).Mentre potreste scrivere il vostro semplice set di regole di iptables e andare avanti, ho optato per usare un servizio di firewall poiché così facendo si acquisisce una bella conoscenza tribale che la comunità Linux ha promosso nel corso dei molti anni in cui ha gestito i firewall iptables.

In generale, un buon demone di firewalling dovrebbe:

• Eseguire il profilo del “progetto OSS sano”. Questo significa che dovrebbe essere attivamente mantenuto, essere in giro da un po’ e avere un’adozione decente.
• Evitare la complessità. I design semplici sono più facili da correggere, estendere e far funzionare.
• Supportano alcune caratteristiche piacevoli da avere, come il supporto per il traffic shaping e la facile configurazione del port forwarding.

Dopo aver rovistato per un po’, ho deciso di scegliere Shorewall.

• Il flusso di configurazione è compile-then-apply. Questo assicura che il nostro insieme di regole sia sano prima di applicarlo, il che significa anche che non c’è un demone residente che consuma le risorse del dispositivo, il che è rilevante su un piccolo computer a scheda singola.
• E’ dotato di un sacco di belle conoscenze storiche incorporate, così le regole iptables che vengono sputate fuori gestiscono molti casi limite a cui normalmente non penseresti.
• Più avanti ne parlerò, ma la marcatura dei pacchetti e il supporto nativo per il traffic shaping rendono facili i qdisc di classe.

Parte terza: La costruzione di base

Questo post non vuole essere una guida completa, ma ho voluto includere i punti principali in modo che sia evidente quanto sia facile da mettere insieme.

Installazione dell’OS

Questo è facile – basta seguire la pagina di Arch Linux Arm espressobin.è particolarmente importante notare le bandiere aggiunte sul comando mkfs.ext4 e la configurazione aggiuntiva di U-Boot.

OS Config

Generalmente, le installazioni di Arch Linux Arm sono abbastanza ben impostate fin dall’inizio.Naturalmente, vorrete impostare un utente non-root con cui amministrare che non sia l’account predefinito, quindi ricordatevi di disabilitare l’utente alarm, cambiare tutte le password e aggiornare il sistema.

Come nota a margine, consiglio vivamente di installare il pacchetto pacmatic e utilizzarlo al posto del normale pacman.Rileverà automaticamente gli aggiornamenti dei file di configurazione e aiuterà a unirli, così come inlineerà le notizie importanti per i cambiamenti dei pacchetti di rottura.

Inoltre, suggerirei di impostare etckeeper per tenere traccia della tua configurazione del firewall (il wiki di Arch ha una buona introduzione).Io ho impostato il mio per spingere automaticamente a un repo privato ospitato su gitolite.Per essere completamente onesto, non mi piacciono tutte le soluzioni di gestione della configurazione là fuori, e quasi tutte le nostre modifiche sono limitate a /etc, quindi questa è una soluzione di backup abbastanza buona almeno per me.

Nota che la configurazione di rete di default per espressobin funziona bene per il caso d’uso del router:

• Entrambe le interfacce lan, lan0 e lan1, sono collegate all’interfaccia br0. Questo ci permette di centralizzare le cose rivolte alla rete privata come dnsmasq su una singola interfaccia virtuale.
• L’interfaccia rivolta al pubblico è wan. Otterrà il suo indirizzo dall’ISP a monte tramite DHCP.

Le uniche modifiche necessarie per ottenere br0 e wan per il nostro router sono due aggiunte: in primo luogo, assegnare all’interfaccia LAN un IP statico dal momento che sarà il router, e abilitare il forwarding IP e il masquerading IP in /etc/systemd/network/br0.network:

Address=192.168.1.1/24IPForward=ipv4IPMasquerade=yes

E confermare che l’interfaccia WAN richiederà un indirizzo dall’ISP in /etc/systemd/network/wan.network:

DHCP=yesIPForward=ipv4UseDNS=no

Ho impostato UseDNS=no qui poiché preferisco usare i server OpenNIC invece di quelli del mio ISP a monte – dirò dove impostarli dopo.

Firewall

I repository di Arch Linux ARM aarch64 hanno l’ultima versione di Shorewall, che è quella che ho usato. Le mie configurazioni non sono così fantasiose, e se state seriamente considerando di implementare Shorewall con una connessione ad internet selvaggia, vi consiglio vivamente di leggere l’intera introduzione di Shorewall ad un firewall a due interfacce.Copre le basi di come dovresti impostare le cose con un bel riassunto del routing e del firewalling in generale.

Fondamentalmente, metterai l’interfaccia br0 e wan nelle zone giuste e imposterai qualsiasi regola necessaria in /etc/shorewall/rules.Ricordati di permettere agli host della tua LAN di usare il tuo server DNS:

DNS(ACCEPT) loc $FW

Confermerai che il DHCP è permesso sull’interfaccia LAN nel file interfaces.

Dovrei notare qui che ho colpito un bug con Shorewall durante la mia configurazione del firewall che ho scoperto essere patchato letteralmente il giorno prima – e Arch Linux ARM aveva già il pacchetto aggiornato nei repository upstream.

DHCP

dnsmasq è la misura perfetta per un router domestico; riunisce un server DNS e DHCP in un demone leggero che gestisce tutto ciò di cui si ha bisogno in una piccola rete, ed è abbastanza maturo che c’è molta documentazione che lo usa per questo esatto caso d’uso: Ho tentato di usare il server DHCP incorporato di systemd che si può impostare con DHCPServer= nei file .network, dato che sembrava un modo leggero per eseguire un server DHCP senza software extra.Senza essere troppo prolisso, non ne vale la pena, una ragione significativa è che non c’è modo di trovare i lease degli indirizzi correnti.

Ci sono molte opzioni che dovrebbero essere impostate qui, ma le più importanti sono:

# 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

Se hai bisogno di assegnazioni statiche o alias, anche queste sono facili da aggiungere.

Parte quarta: Interludio

Con l’espressobin che serve le richieste DHCP e DNS su br0, il firewalling tramite Shorewall, e l’instradamento dei pacchetti tra la LAN e la WAN, è un router funzionante. A questo punto, collegare la porta WAN all’upstream dell’ISP e le due porte lan0/lan1 ai dispositivi o a un altro switch è tutto ciò che serve.

Tuttavia, questo è solo un inizio. Se vogliamo davvero considerare questo un router sostitutivo, ci sono alcune cose veramente interessanti che possiamo fare per migliorare ulteriormente le sue capacità in modo che non sembri un downgrade da qualcosa come il mio vecchio Asus N66U.

Parte Cinque: Aggiornamenti

Ho aggiunto le seguenti caratteristiche al mio router espressobin vanilla, che coprirò ciascuna a turno:

• Monitoraggio Netflow
• Traffic shaping

Monitoraggio Netflow

La visibilità del traffico è qualcosa che ho trovato davvero prezioso con il mio firmware Asus Merlin per tracciare l’utilizzo.Netflow è lo standard de facto per questo genere di cose, e tra tutte le opzioni disponibili, mi piace molto ipt-netflow perché è un modulo nativo del kernel quindi c’è molto poco overhead ed è mantenuto molto attivamente.

Si è scoperto che sono probabilmente la prima persona ad usarlo sull’architettura aarch64, perché ho avuto un po’ di aiuto per farlo supportare sul chipset aarch64. Il manutentore del progetto era (ed è stato) super reattivo ai bugfix, quindi non ho avuto alcun problema a garantire che il modulo sia supportato sugli ultimi kernel su cui gira il progetto Arch Linux ARM.

Usarlo è una questione di installare il pacchetto ipt-netflow-dkms-git da AUR.Verrà compilato per il vostro kernel perché dkms è fantastico, e ho lasciato il seguente in /etc/modules-load.d/ipt-netflow.conf

ipt_NETFLOW

Questo lo caricherà, e lo configurerete in /etc/modprobe.d/ipt-netflow.conf:

options ipt_NETFLOW destination=$ip:2055 protocol=5

dove $ip è la vostra destinazione netflow.Alla fine, il traffico viene catturato facendo scorrere il flusso in uno speciale obiettivo iptables, che può essere fatto direttamente da shorewall, convenientemente.In /etc/shorewall/start:

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

Questo dirige tutti i pacchetti sul router per entrare prima nel target NETFLOW prima di qualsiasi altra cosa, che elabora i pacchetti e li fa passare attraverso le normali regole che Shorewall imposta.

Ovviamente, ipt-netflow ha bisogno di un posto dove inviare i log del netflow, ma questo è fuori dallo scopo di questo post.Nel mio caso, ho un’istanza di Logstash in esecuzione sulla mia rete con il modulo netflow in esecuzione e che aggrega gli eventi in un cluster Elasticsearch.Ci sono alcune dashboard predefinite:

Comprese alcune piuttosto belle, come una dashboard Geo-IP:

Tuttavia, la metrica più rilevante a cui sono interessato è il mio utilizzo totale della larghezza di banda perché ho un ISP antidiluviano che si preoccupa dei limiti di dati.Fortunatamente questo è facile con i dati netflow che sto raccogliendo: possiamo semplicemente chiedere a Elasticsearch di sommare alcuni campi e ottenere facilmente queste metriche.La seguente dashboard ha due visualizzazioni:

• L’indicatore confronta la somma nel periodo di tempo in questione con il limite che il mio ISP ha impostato per me, così posso facilmente vedere dove si trova il mio utilizzo attuale rispetto al limite.
• La serie temporale traccia la larghezza di banda in byte nel tempo per vedere quando sto usando quella larghezza di banda.

Una cosa particolarmente bella di questa configurazione è che, poiché stiamo memorizzando le metriche netflow in Elasticsearch invece di qualche altro datastore o database di serie temporali, posso effettivamente focalizzare le query per queste dashboard al fine di fare cose come sommare solo i byte totali per determinati intervalli CIDR perché il motore di archiviazione sottostante (Lucene) capisce gli indirizzi IP nativamente.Per esempio, la seguente query in Kibana:

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

Filtrerà efficacemente i potenziali grandi blocchi di larghezza di banda che avvengono tra gli host sulla mia LAN, come lo streaming tra il mio host Kodi e la macchina NAS.Cool.

Traffic Shaping

Questo si è trasformato in un’impresa piuttosto massiccia che è stata un’affascinante tana di coniglio in cui sparire.Alcuni firmware stock e la maggior parte dei router personalizzati offrono una qualche forma di QoS o traffic shaping, quindi speravo di fare lo stesso sul mio router personalizzato al fine di proteggere parte del mio traffico (come Overwatch) da alte latenze.

Il mondo della tecnologia QoS è un luogo affascinante.Mentre si potrebbe fare affidamento su alcuni schemi semplici come un filtro HTB (hierarchical token bucket), i progressi nel filtraggio dei pacchetti sono sorprendentemente attivi e ci sono un sacco di approcci interessanti.

Quello che alla fine ho scelto è un filtro HFSC (hierarchical fair-service curve).Sarò onesto: la matematica che c’è dietro è così fuori dalla mia portata che ho dovuto leggere diversi riassunti nel tentativo di renderla comprensibile alle persone normali, e la migliore spiegazione che aveva senso per me era un eccellente gist in cui mi sono imbattuto dall’utente GitHub eqhmcow che spiega i benefici e l’uso di HFSC nella pratica.

Il tl;dr è questo: con una classe di controllo del traffico HFSC, è possibile dare priorità al traffico in modo molto efficace e raggiungere un buon equilibrio tra i flussi che richiedono un’elevata larghezza di banda e basse latenze.Non è un proiettile magico – è ancora necessario contrassegnare quali tipi di traffico sono sensibili alla latenza – ma ha funzionato abbastanza bene per me.Senza le regole in atto, un download di Steam o Blizzard Launcher ucciderà i tempi di ping, mentre le regole HFSC attive taglieranno con grazia quelle porzioni di traffico pesante per assicurare che i flussi interattivi non siano impattati.è davvero fantastico!

Il gist menzionato sopra fa un buon lavoro su come impostare le classi tc da zero.Tuttavia, Shorewall può effettivamente gestire il controllo del traffico di classe nativamente, quindi possiamo impostare potenti regole QoS abbastanza facilmente.I seguenti file di configurazione sono basati sulle mie velocità di banda misurate, che sono circa 230 in giù e 10 in su.

Il primo passo è quello di impostare le classi tc rilevanti per ogni dispositivo nel file tcdevices:

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

Qui l’interfaccia br0 rivolta alla LAN ottiene un gigabit completo, ma l’interfaccia WAN wan ottiene il 97% della sua velocità in giù e il 90% della mia velocità in su disponibile.Il ragionamento per questi numeri è spiegato nel gist – stiamo essenzialmente ricreando questo insieme di regole in termini di Shorewall.

Poi, definiamo come le marcature dei pacchetti mapperanno alle classi tc nel file tcclasses:

# 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

Questo farà cadere il traffico importante/interattivo nelle classi che avranno priorità più alta.Naturalmente, abbiamo anche bisogno di marcare i pacchetti che dovrebbero avere una priorità più alta, cosa che viene fatta 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

Questo imposta i marchi ad alta priorità (1 e 2) che vengono gestiti dalla nostra classe tc.L’esempio include ping ICMP, ssh, alcuni giochi Blizzard, e traffico locale.

Ricaricare shorewall dovrebbe mettere in atto questi criteri; il risultato finale dovrebbe permettere il traffico di massa come i download o i flussi mentre non influisce negativamente sulla latenza del traffico interattivo come ssh, i tempi di ping dei giochi, e così via; i miei test informali hanno confermato questo – si noti che se si decide di verificare questo da soli, si possono osservare picchi di latenza immediatamente dopo un’esplosione iniziale di traffico di massa, ma HFSC interviene rapidamente per imporre limiti per mantenere basse le latenze per il traffico interattivo.

Ho un paio di serie di benchmark che mostrano HFSC in azione, ma ecco un piccolo esempio: come la latenza dei ping viene influenzata quando iperf viene eseguito in background.

Come potete vedere, senza alcuna regola di controllo del traffico in atto, le raffiche di traffico di massa possono avere impatti piuttosto negativi sul traffico interattivo sensibile alle alte latenze.Con HFSC, possiamo evitare questi problemi.

Conclusione

Ho usato il mio router fatto in casa per diversi mesi e sembra funzionare alla grande.Non ho sperimentato nessun misterioso calo di connessione, problemi di velocità o problemi hardware durante l’intero periodo di funzionamento continuo, quindi considero la costruzione un successo.Anche gli aggiornamenti vanno bene; dopo un normale sudo pacmatic -Syuriavvio il sistema torna online con tutte le regole iptables e altri servizi come previsto, quindi tenersi al passo con gli ultimi kernel e altri pacchetti è semplice.

Per riassumere:

• Per una persona esperta di operazioni o tecnicamente, un router personalizzato è molto fattibile. I computer ARM a scheda singola rendono economico e conveniente iniziare.
• Le soluzioniOSS per il firewalling, il traffic shaping e il monitoraggio della rete sono mature e facili da usare. In particolare, le soluzioni di vecchia data come Shorewall e dnsmasq sono molto ben documentate e hanno molti anni di lavoro nella loro documentazione e set di funzionalità.
• Mentre il routing + DNS + DHCP è una schiacciata, OSS WiFi può essere colpito o perso. Il tuo chilometraggio può variare, ma il mio espressobin semplicemente non è un buon punto di accesso.