Tyblog

” Construirea routerului meu ideal pentru 50 de dolari ”

După ce Asus-ul meu N66U s-a stricat, am luat în considerare câteva opțiuni: un alt router all-in-one, upgrade la ceva de genul unui EdgeRouter, sau să fac ceva personalizat.Când am citit articolul din Ars Technica care susținea virtuțile construirii propriului router, asta a cam rezolvat totul: Să fie DIY.

Am un oarecare complex psihologic atunci când vine vorba de crearea propriilor mele soluții de inginerie excesivă, dar mi-am stabilit câteva obiective generale: rezultatul final ar trebui să fie ieftin, cu consum redus de energie, bine susținut de Linux și extensibil.De altfel, plăcile ARM se potrivesc cu multe dintre aceste cerințe, iar unele, cum ar fi Raspberry Pi, au stârnit atât de multă activitate în cadrul comunității încât există un mare sprijin pentru platforma ARM, chiar dacă poate părea străină de x86.

Am reușit să pun laolaltă un dispozitiv care nu numai că este foarte ieftin pentru ceea ce face, dar este și extrem de capabil în sine.Dacă vă interesează să vă construiți propriul router de casă, voi demonstra aici că acest lucru nu numai că este fezabil, dar este și relativ ușor de făcut și oferă o cantitate uriașă de utilitate – de la modelarea traficului, la monitorizarea fluxului de rețea, la DNS dinamic.

L-am construit folosind espressobin, Arch Linux Arm și Shorewall.

Această imagine arată placa închisă într-o carcasă imprimată în 3d. Din păcate, espressobinul nu este suficient de popular pentru a se lăuda cu o mare varietate de carcase achiziționabile, așa cum are Raspberry Pi, dar există câteva modele bune pentru imprimare 3d.

Ca o notă secundară, documentația următoare nu este menită să fie un ghid complet pas cu pas pentru a face același lucru singur.Deși vreau să acopăr multe dintre alegerile care au stat la baza construcției, configurarea a ceva atât de important precum un router/firewall chiar nu ar trebui să fie o treabă de copy/paste și ar fi mai bine să fie ghidată liber de pașii de aici, cu o înțelegere temeinică a cum și de ce.

• De ce
• Prima parte: Hardware
  • Ce-i cu WiFi?
• A doua parte: Software
  • Sistemul de operare
  • Firewall
• A treia parte: The Basic Build
  • OS Install
  • OS Config
  • Firewall
  • DHCP
• Partea a patra: Interludiu
• Partea a cincea: Upgrades
  • Monitorizarea fluxului de rețea
  • Traffic Shaping
• Concluzie

De ce

Există o mulțime de routere solide pe care le puteți cumpăra și care nu sunt niște incendii de anvelope ISP și care ar fi probabil mai mult decât potrivite (mă uit la tine cu dragoste, EdgeRouter Lite).Deci, de ce să vă deranjați cu toate astea?Există câteva beneficii legitime aici:

• Este de fapt foarte accesibil. Routerul meu a trecut cu brio testele mele de referință și are toate caracteristicile pe care le-aș putea trage din Linux (ceea ce reprezintă o listă mare).
• Este sigur. Am impresia că în fiecare lună se anunță o nouă vulnerabilitate pentru vreun dispozitiv de margine de rețea de consum. Comparați asta cu un firewall autogestionat, iar eu știu exact ce servicii sunt expuse (și dacă iptables este stricat, lumea are probleme mai mari). Pentru orice contestatari, apropo, singurul port care ascultă pe firewall-ul meu este un port aleatoriu cu număr mare pentru autentificarea ssh numai cu cheie publică. Deci, da, cred că este mai sigur decât un router de consum Huawei.
• Are caracteristici excelente. Sigur, espressobinul meu poate să ruteze și să servească drept firewall, dar am introdus și alte capacități utile.
• Este performant. În testele de referință minore pe care le-am efectuat, espressobin poate într-adevăr să împingă traficul fără să transpire.
• A fost foarte distractiv de construit. Dacă a) aveți nevoie de un router nou sau b) doriți să vă tăiați dinții cu un proiect ARM cu o singură placă, acesta ar putea fi o alegere bună.

Partea întâi: Hardware

Tehnic, ați putea asambla un router folosind orice calculator cu două NIC-uri, dar ne putem descurca la fel de bine cu mai puțină energie, un factor de formă mai mic și la un preț mai accesibil.Plăcile ARM ating punctul ideal: sunt super ieftine, mai puternice decât ați crede și bine susținute cu atât de multe variante pe piață.

Cel mai cunoscut concurent este Raspberry Pi, dar fără două NIC-uri sau rețea gigabit, nu este o opțiune bună.În plus, plătiți pentru lucruri precum un GPU care nu sunt necesare într-un dispozitiv de rețea fără cap.

Veste bună este că anul trecut a fost lansat espressobinul, care este super capabil.Se simte construit special pentru acest tip de lucru: rețea gigabit, un comutator încorporat și nici un ornament de care altfel ați avea nevoie pentru ceva mai generalist (nu există nici măcar un display out, doar o consolă serială).

Deși placa este destul de tânără, atât Armbian cât și Arch Linux Arm suportă hardware-ul și ambele proiecte fac o treabă foarte bună.Dacă nu ați explorat lumea Linux pe ARM, nu aveți de ce să vă temeți aici.Armbian și Arch Linux Arm oferă tot ceea ce aveți nevoie pentru aarch64 în mod nativ în depozitele de distribuție, așa că sunt puține lucruri pe care le veți întâlni care să vi se pară străine pe un cip ARM pe 64 de biți și, cu siguranță, se pare că merită atunci când luați în considerare prețul accesibil al hardware-ului și amprenta energetică redusă.

Iată câteva dintre cele mai importante aspecte pentru mine:

• Cardul include un comutator de rețea Topaz încorporat. În testele mele de rețea, traficul care traversează doar interfețele LAN este imposibil de distins, din punct de vedere al vitezei, de traficul care trece printr-un switch vanilla. Dacă faceți streaming de pe un NAS sau dacă aveți altfel cerințe ridicate pentru comunicarea între dispozitive care traversează routerul, acest lucru poate face o mare diferență.
• Consolele seriale sunt cetățeni de primă clasă. Pe Raspberry Pis-urile mele, uneori deveneam frustrat fiind nevoit să întind mâna după ecranul HDMI atunci când depanam probleme, dar espressobin are un port serial micro USB pentru acces ușor la consolă.
• Cipul aarch64 a fost grozav. Nu numai că s-a descurcat cu tot ce am aruncat la el, dar știați că nu este afectat de meltdown? Cipurile Cortex-A53 nu sunt afectate de bug-ul de execuție speculativă, așa că acesta este un bonus în plus.

Cum rămâne cu WiFi?

Voi face o mică notă aici că am încercat să folosesc espressobin și ca punct de acces wireless.Placa are un slot mini PCIe foarte potrivit pentru o placă wireless și, deși ar fi trebuit să funcționeze, pot raporta definitiv că nu este o idee bună.

Fără a intra în detalii dureroase, există o serie de probleme care nu fac să merite efortul. nu am putut face ca benzile de 5Ghz să funcționeze în niciun scenariu, serviciul meu hostapd de 2,4Ghz a devenit insensibil la fiecare douăsprezece ore sau cam așa ceva, iar vitezele au fost șocant de proaste.

În general, cred că acesta este un eșec al hardware-ului espressobin.Carduri care altfel ar trebui să fie bine suportate în Linux (unele dintre cardurile pe care le-am testat erau bazate pe ath9k sau ath10k) pur și simplu nu funcționează cu interfața mPCIe a plăcii.Chiar și cardurile recomandate oficial au avut probleme – RTL8191SE ar funcționa intermitent, și chiar și cardul produs de Globalscale nu funcționează așa cum se anunță.Întâmplător, dacă găsiți un card bine suportat pe espressobin, vă rog să lăsați un răspuns pe firul de discuție de pe forumul aferent pe care l-am inițiat pentru a discuta această problemă.

Cu toate acestea fiind spuse, intenția mea de la începutul acestui proiect a fost de a separa AP-ul meu de router, indiferent dacă am ajuns să folosesc un espressobin sau nu.Păstrarea sarcinilor de firewalling/rutare separat de wireless este o separare plăcută a preocupărilor, și puteți obține dispozitive AP dedicate foarte bune, fără nicio funcție în afara transmiterii unui semnal, pentru a-l păstra simplu și puternic.

Pentru ceea ce merită, am ajuns să achiziționez un dispozitiv Ubiquity UniFi și am fost total mulțumit de el.

Partea a doua: Software

Există două mari opțiuni aici: Sistemul de operare și software-ul de firewalling.

Sistemul de operare

Prima alegere care trebuie făcută este dacă doriți să derulați manual acest lucru de la o distribuție care suportă aarch64 sau să folosiți o soluție pre-construită de tip firmware, cum ar fi OpenWRT.Personal, am constatat că, ori de câte ori folosesc o soluție înfășurată ca Tomato/OpenWrt sau FreeNAS pentru un build, de obicei mă simt frustrat fără să pot intra cu adevărat înăuntru și să modific lucrurile, așa că voi folosi o distribuție Linux de uz general pentru sistemul de operare.

Cum am menționat anterior, Armbian și Arch Linux ARM suportă placa, iar espressobin are documentație oficială pentru Ubuntu (precum și pentru Yocto, pe care nu-l cunoșteam până acum).Deși nu vă voi spune care este cea mai bună pentru cazul dvs. de utilizare, iată de ce am preferat Arch Linux Arm:

• Sunt total convins de distribuțiile rolling release.
• Sunt, de asemenea, convins de rularea unor distribuții de ultimă generație. În cazul unui router, este bine să fii aproape de upstream atunci când sunt lansate actualizări potențial legate de securitate.
• Arch ne va oferi o tablă curată pe care să construim fără servicii străine. Acest lucru înseamnă că, cu o bază minimă, putem ști exact ce vom avea instalat, expus și în funcțiune după ce punem piesele laolaltă.
• Cunosc și îmi plac cei de la Arch Linux ARM. Bună WarheadsSE!

Firewall

Îmi vin imediat în minte unele nume precum PFSense, dar mi-ar plăcea foarte mult să ruleze ceva pe Linux, deoarece îl cunosc mult mai bine decât un BSD (în plus, cele mai bune opțiuni de sistem de operare pentru espressobin sunt bazate pe Linux).

Peisajul firewall-ului Linux este destul de larg. deși aproape sigur vom folosi ceva bazat pe iptables, există o mulțime de servicii de nivel superior care stau deasupra iptables (ufw, firewalld, etc.)Deși ați putea să vă scrieți propriul set de reguli iptables simplu și să mergeți cu el, am optat pentru a folosi un serviciu de firewall, deoarece făcând acest lucru ne cumpără niște cunoștințe tribale frumoase pe care comunitatea Linux le-a promovat de-a lungul numeroșilor ani în care a gestionat firewall-uri iptables.

În general, un daemon de firewalling bun ar trebui:

• Se încadrează în profilul „proiect OSS sănătos”. Aceasta înseamnă că ar trebui să fie întreținut în mod activ, să existe de ceva timp și să aibă o adopție decentă.
• Evitați complexitatea. Proiectele simple sunt mai ușor de depanat, de extins și de operat.
• Suportați unele caracteristici de dorit, cum ar fi suportul pentru modelarea traficului și configurarea facilă a redirecționării porturilor.

După ce am cercetat o vreme, am optat pentru Shorewall.Iată câteva dintre cele mai notabile motive pentru care am ales-o:

• Fluxul de configurare este compilați-apoi-aplicați. Acest lucru asigură că setul nostru de reguli este sănătos înainte de a-l aplica, ceea ce înseamnă, de asemenea, că nu există un demon rezident care să consume resursele dispozitivului, ceea ce este relevant pe un computer mic cu o singură placă.
• Vine cu o mulțime de cunoștințe istorice frumoase încorporate, astfel încât regulile iptables care sunt scuipate să gestioneze o mulțime de cazuri limită la care nu v-ați gândi în mod normal.
• Voi acoperi mai multe despre acest lucru mai târziu, dar marcarea pachetelor și suportul nativ pentru modelarea traficului fac ca qdiscurile de clasă să fie ușoare.

Partea a treia: Construcția de bază

Această postare nu este menită să fie un ghid cuprinzător, dar am vrut să includ punctele generale, astfel încât să fie evident cât de ușor este de asamblat.

Instalarea sistemului de operare

Aceasta este ușoară – trebuie doar să urmați pagina Arch Linux Arm espressobin.Este deosebit de important să rețineți stegulețele adăugate la comanda mkfs.ext4 și configurația suplimentară U-Boot.

OS Config

În general, instalațiile Arch Linux Arm sunt destul de bine configurate de la bun început. desigur, veți dori să configurați un utilizator non-root pentru a administra cu care să nu fie contul implicit, așa că nu uitați să dezactivați utilizatorul alarm, să schimbați toate parolele și să actualizați sistemul.

Ca o notă secundară, vă recomand cu căldură să instalați pachetul pacmatic și să îl folosiți în loc de obișnuitul pacman.Acesta va detecta automat actualizările fișierelor de configurare și va ajuta la fuzionarea acestora, precum și la punerea în linie a noutăților importante pentru modificările de ultimă oră ale pachetului.

În plus, aș sugera să configurați etckeeper pentru a urmări configurația firewall-ului (Arch wiki are o bună introducere). eu l-am configurat pe al meu pentru a împinge automat către un repo gitolite găzduit privat.Pentru a fi complet sincer, nu-mi plac toate soluțiile de gestionare a configurației existente și aproape toate modificările noastre sunt limitate la /etc, așa că aceasta este o soluție de rezervă suficient de bună cel puțin pentru mine.

Rețineți că configurația de rețea implicită pentru espressobin funcționează bine pentru cazul de utilizare a routerului:

• Ambele interfețe LAN, lan0 și lan1, sunt conectate prin punte la interfața br0. Acest lucru ne permite să centralizăm lucrurile orientate spre rețeaua privată, cum ar fi dnsmasq, pe o singură interfață virtuală.
• Interfața orientată spre public este wan. Aceasta își va prelua adresa de la ISP-ul din amonte prin DHCP.

Unele modificări necesare pentru a configura br0 și wan pentru routerul nostru sunt două adăugiri: în primul rând, atribuirea unui IP static interfeței LAN, deoarece aceasta va fi routerul, și activarea redirecționării IP și a mascării IP în /etc/systemd/network/br0.network:

Address=192.168.1.1/24IPForward=ipv4IPMasquerade=yes

Și confirmați că interfața orientată spre WAN va solicita o adresă de la ISP în /etc/systemd/network/wan.network:

DHCP=yesIPForward=ipv4UseDNS=no

Am setat UseDNS=no aici deoarece prefer să folosesc serverele OpenNIC în loc de cele ale ISP-ului meu din amonte – voi menționa unde să le setez mai târziu.

Firewall

Depozitele Arch Linux ARM aarch64 au cea mai recentă versiune de Shorewall, care este cea pe care am folosit-o. Configurațiile mele nu sunt atât de fanteziste, iar dacă vă gândiți serios să implementați Shorewall cu o conexiune la internetul sălbatic, vă recomand să citiți în întregime introducerea Shorewall la un firewall cu două interfețe.Acoperă elementele de bază ale modului în care ar trebui să configurați lucrurile, cu un rezumat frumos despre rutare și firewalling în general.

În principiu, veți pune interfața br0 și wan în zonele corecte și veți seta orice reguli necesare în /etc/shorewall/rules.Nu uitați să lăsați gazdele din LAN să folosească serverul DNS:

DNS(ACCEPT) loc $FW

Vă veți confirma că DHCP este permis pe interfața LAN în fișierul interfaces.

Am dori să notez aici că în timpul configurării firewall-ului m-am lovit de un bug cu Shorewall, pe care am descoperit că a fost corectat literalmente cu o zi înainte – iar Arch Linux ARM avea deja pachetul actualizat în depozitele upstream. 1 punct pentru folosirea unor distribuții actualizate.

DHCP

dnsmasq se potrivește perfect pentru un router de casă.Acesta reunește un server DNS și DHCP într-un daemon ușor care gestionează tot ceea ce ați avea nevoie de la o rețea mică și este suficient de matur încât există o mulțime de documentație care îl folosește exact pentru acest caz de utilizare.

Nota: Am încercat să folosesc serverul DHCP încorporat în systemd, pe care îl puteți seta cu DHCPServer= în fișierele .network, deoarece părea o modalitate ușoară de a rula un server DHCP fără software suplimentar.Fără a fi prea prolific, nu merită, un motiv important fiind faptul că nu există nicio modalitate de a găsi contractele de închiriere a adreselor curente.

Există o mulțime de opțiuni care ar trebui setate aici, dar cele mai importante sunt:

# 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

Dacă aveți nevoie de atribuiri statice sau alias-uri, acestea sunt de asemenea ușor de adăugat.

Partea a patra: Interludiu

Cu espressobinul care servește cereri DHCP și DNS pe br0, firewalling prin Shorewall și rutarea pachetelor între LAN și WAN, acesta este un router funcțional. în acest moment, conectarea portului WAN la ISP în amonte și a celor două porturi lan0/lan1 la dispozitive sau la un alt switch este tot ce este necesar.

Cu toate acestea, acesta este doar un început. dacă vrem cu adevărat să considerăm că acesta este un înlocuitor al routerului, există câteva lucruri cu adevărat interesante pe care le putem face pentru a-i spori și mai mult capacitățile, astfel încât să nu se simtă ca un downgrade față de ceva precum vechiul meu Asus N66U.

Partea a cincea: Îmbunătățiri

Am îmbinat următoarele caracteristici la routerul meu espressobin de vanilie, pe care le voi aborda pe rând:

• Monitorizarea fluxului de rețea
• Traffic shaping

Monitorizarea fluxului de rețea

Vizibilitatea traficului este un lucru pe care l-am găsit foarte valoros cu firmware-ul meu Asus Merlin pentru a urmări utilizarea.Netflow este standardul de facto pentru acest tip de lucru și, dintre toate opțiunile disponibile, îmi place foarte mult ipt-netflow, deoarece este un modul nativ al kernelului, astfel încât există foarte puțin overhead și este întreținut foarte activ.

Se pare că sunt, probabil, prima persoană care îl folosește pe arhitectura aarch64, deoarece am primit ajutor pentru a obține suport pentru chipset-ul aarch64. întreținătorul proiectului a fost (și a fost) foarte receptiv la corecturile de erori, așa că nu am avut probleme în a mă asigura că modulul este suportat pe cele mai recente nuclee pe care rulează proiectul Arch Linux ARM.

Utilizarea lui este o chestiune de instalare a pachetului ipt-netflow-dkms-git din AUR.Se va construi pentru nucleul vostru pentru că dkms este grozav, iar eu am scăpat următoarele în /etc/modules-load.d/ipt-netflow.conf

ipt_NETFLOW

Acesta îl va încărca, iar voi îl configurați în /etc/modprobe.d/ipt-netflow.conf:

options ipt_NETFLOW destination=$ip:2055 protocol=5

Unde $ip este destinația netflow-ului vostru.În cele din urmă, traficul este capturat prin curgere într-o țintă specială iptables, ceea ce se poate face direct din shorewall, în mod convenabil.În /etc/shorewall/start:

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

Aceasta direcționează toate pachetele de pe router să intre mai întâi în ținta NETFLOW înainte de orice altceva, care procesează pachetele și le trece înapoi pentru a curge prin regulile normale pe care Shorewall le stabilește.

Desigur, ipt-netflow are nevoie de un loc unde să trimită jurnalele de netflow, dar asta nu face parte din scopul acestei postări.În cazul meu, am o instanță Logstash care rulează în rețeaua mea cu modulul netflow care rulează și agregă evenimentele într-un cluster Elasticsearch. în acest fel, obțin niște tablouri de bord convenabile și posibilitatea de a vizualiza o mare varietate de informații despre rețeaua mea.Există câteva tablouri de bord implicite:

Inclusiv unele destul de interesante, cum ar fi un tablou de bord Geo-IP:

Cu toate acestea, cea mai relevantă măsurătoare care mă interesează este utilizarea totală a lățimii de bandă, deoarece am un ISP antediluvian care se preocupă de plafoanele de date.Din fericire, acest lucru este ușor de realizat cu datele netflow pe care le colectez: putem pur și simplu să cerem Elasticsearch să însumeze unele câmpuri și să obținem cu ușurință acești parametri.Următorul tablou de bord are două vizualizări:

• Galonul compară suma pe perioada de timp în cauză cu plafonul pe care ISP-ul meu l-a stabilit pentru mine, astfel încât să pot vedea cu ușurință unde se situează utilizarea mea actuală în raport cu plafonul.
• Seria de timp trasează lățimea de bandă în octeți în timp pentru a vedea când folosesc această lățime de bandă.

Un lucru deosebit de mișto în legătură cu această configurație este că, deoarece stocăm măsurătorile netflow în Elasticsearch în loc de un alt depozit de date sau o bază de date cu serii de timp, pot de fapt să focalizez interogările pentru aceste tablouri de bord pentru a face lucruri precum însumarea doar a numărului total de octeți pentru anumite intervale CIDR, deoarece motorul de stocare subiacent (Lucene) înțelege adresele IP în mod nativ.De exemplu, următoarea interogare în Kibana:

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

Filtrează în mod eficient bucăți potențial mari de lățime de bandă care se întâmplă între gazdele de pe LAN-ul meu, cum ar fi streamingul între gazda mea Kodi și mașina NAS.Cool.

Traffic Shaping

Aceasta s-a transformat într-o întreprindere destul de masivă în care a fost o gaură de iepure fascinantă în care să dispară.Unele firmware-uri stock și cele mai multe firmware-uri de routere personalizate oferă o formă de QoS sau de modelare a traficului, așa că speram să fac același lucru pe routerul meu personalizat pentru a proteja o parte din traficul meu (cum ar fi Overwatch) de latențele ridicate.

Lumea tehnologiei QoS este un loc fascinant.În timp ce v-ați putea baza pe unele scheme simple, cum ar fi un filtru HTB (hierarchical token bucket), progresele în filtrarea pachetelor sunt surprinzător de active și există o mulțime de abordări interesante.

Ceea asupra căreia m-am decis în cele din urmă a fost un filtru HFSC (hierarchical fair-service curve).Voi fi sincer: matematica din spatele acestuia este atât de departe de mine încât a trebuit să citesc mai multe rezumate care încercau să o descompună pentru oamenii normali, iar cea mai bună explicație care a avut sens pentru mine a fost un gist excelent de care am dat peste el de la utilizatorul GitHub eqhmcow care explică beneficiile și utilizarea HFSC în practică.

Tl;dr este următorul lucru: cu o clasă de control al traficului HFSC, puteți prioritiza foarte eficient traficul și obține un echilibru bun între fluxurile care necesită o lățime de bandă mare și latențe scăzute. nu este un glonț magic – va trebui în continuare să marcați ce tipuri de trafic sunt sensibile la latență – dar a funcționat destul de bine pentru mine.Fără reguli în vigoare, o descărcare Steam sau Blizzard Launcher va distruge timpii de ping, în timp ce regulile HFSC active vor tăia în mod grațios acele porțiuni grele de trafic pentru a se asigura că fluxurile interactive nu sunt afectate.Este cu adevărat grozav!

Gistul menționat mai sus face o treabă bună în ceea ce privește modul de configurare a claselor tc de la zero.Cu toate acestea, Shorewall poate de fapt să gestioneze controlul traficului pe clase în mod nativ, astfel încât putem configura reguli QoS puternice destul de ușor.Următoarele fișiere de configurare se bazează pe vitezele de lățime de bandă măsurate de mine, care sunt de aproximativ 230 în jos și 10 în sus.

Primul pas este să setați clasele tc relevante pentru fiecare dispozitiv în fișierul tcdevices:

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

Aici interfața br0 orientată spre LAN primește un gigabit complet, dar interfața WAN wan primește 97% din viteza sa în jos și 90% din viteza mea disponibilă în sus.Raționamentul pentru aceste numere este explicat în gist – în esență, recreăm acest set de reguli în termeni Shorewall.

În continuare, definiți modul în care marcajele pachetelor vor fi mapate pe clasele tc din fișierul 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

Aceasta va scădea traficul important/interactiv în clasele care primesc o prioritate mai mare.Desigur, trebuie, de asemenea, să marcăm pachetele care ar trebui să primească această prioritate mai mare, ceea ce se face în 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

Aceasta stabilește marcajele de înaltă prioritate (1 și 2) care sunt gestionate de clasa noastră tc.Exemplul include ICMP pings, ssh, unele jocuri Blizzard și trafic local.

Încărcarea shorewall ar trebui să le pună în aplicare.Rezultatul final ar trebui să permită traficul masiv, cum ar fi descărcările sau fluxurile, în timp ce nu afectează negativ latența traficului interactiv, cum ar fi ssh, timpii de ping în jocuri și așa mai departe.Testele mele informale au confirmat acest lucru – rețineți că, dacă vă decideți să verificați acest lucru singur, este posibil să observați vârfuri de latență imediat după o explozie inițială de trafic masiv, dar HFSC intervine rapid pentru a impune limite pentru a menține latențele scăzute pentru traficul interactiv.

Am câteva seturi de teste de referință care arată HFSC în acțiune, dar iată un mic exemplu: cum sunt afectate latențele ping atunci când iperf este rulat în fundal.

După cum puteți vedea, fără reguli de control al traficului, rafalele de trafic masiv pot avea un impact destul de negativ asupra traficului interactiv sensibil la latențe ridicate. cu HFSC, putem evita aceste probleme.

Concluzie

Am folosit routerul meu de casă timp de câteva luni și pare să funcționeze foarte bine.Nu am avut parte de nicio cădere misterioasă a conexiunii, probleme de viteză sau probleme hardware pe întreaga perioadă de funcționare continuă, așa că aș considera construcția un succes.Actualizările sunt, de asemenea, în regulă; după o sudo pacmatic -Syu normală și o repornire, sistemul revine online cu toate regulile iptables și alte servicii, așa cum era de așteptat, așa că menținerea la zi cu cele mai recente nuclee și alte pachete este simplă.

Pentru a rezuma:

• Pentru o persoană pricepută la operații sau cu cunoștințe tehnice, construirea unui router personalizat este foarte ușor de realizat. Calculatoarele cu o singură placă ARM permit un început ieftin și convenabil.
• SoluțiileOSS pentru firewalling, modelarea traficului și monitorizarea rețelei sunt mature și ușor de utilizat. În special, soluțiile cu vechime fină, cum ar fi Shorewall și dnsmasq, sunt foarte bine documentate și au mulți ani de muncă depusă în documentația și setul lor de caracteristici.
• În timp ce rutarea + DNS + DHCP este un slam dunk, OSS WiFi poate fi lovit sau ratat. Kilometrajul dvs. poate varia, dar espressobinul meu pur și simplu nu este un punct de acces bun.

.