Tyblog

” Building my ideal router for $50 ”

Po tym, jak mój Asus N66U kopnął wiadro, rozważałem kilka opcji: inny router all-in-one, uaktualnić do czegoś takiego jak EdgeRouter, lub warzyć coś niestandardowego.Kiedy przeczytałem artykuł Ars Technica espousing cnót budowania własnego routera, że całkiem dużo rozstrzygnęła go: DIY to jest.

Mam trochę psychologiczny kompleks, jeśli chodzi o toczenie moje własne rozwiązania over-engineered, ale ja ustawić kilka ogólnych celów: wynik końcowy powinien być tani, low-power, dobrze obsługiwane przez Linux, i extensible.Incidentally, ARM deski pasują wiele z tych wymagań, a niektóre jak Raspberry Pi wzbudziły tyle aktywności społeczności, że jest wielkie wsparcie dla platformy ARM, nawet jeśli może czuć się obcy z x86.

I’ve managed to cobble together a device that is not only dirt cheap for what it does, but is extremely capable in its own right.If you have any interest in building your own home router, I’ll demonstrate here that doing so is not only feasible, but relatively easy to do and offers a huge amount of utility – from traffic shaping, to netflow monitoring, to dynamic DNS.

I built it using the espressobin, Arch Linux Arm, and Shorewall.

To zdjęcie pokazuje płytkę zamkniętą w obudowie wydrukowanej w 3d. Niestety espressobin nie jest na tyle popularny, aby mógł pochwalić się szeroką gamą obudów do kupienia jak Raspberry Pi, ale jest tam kilka dobrych modeli do druku 3d.

Jako uwaga poboczna, poniższa dokumentacja nie jest przeznaczona jako kompleksowy przewodnik krok po kroku, aby zrobić to samo samemu.Chociaż chcę pokryć wiele z wyborów, które poszły do budowy, konfigurowanie czegoś tak ważnego jak router / firewall naprawdę nie powinno być kopiuj / wklej pracy i lepiej być luźno kierowane przez kroki tutaj z dokładnym zrozumieniem jak i dlaczego.

• The Why
• Część pierwsza: Sprzęt
  • What About WiFi?
• Część druga: Oprogramowanie
  • Operating System
  • Firewall
• Część trzecia: The Basic Build
  • OS Install
  • OS Config
  • Firewall
  • DHCP
• Część czwarta: Interlude
• Część piąta: Upgrades
  • Netflow Monitoring
  • Traffic Shaping
• Conclusion

The Why

Jest mnóstwo solidnych routerów, które można kupić, a które nie są ogniskami ISP i prawdopodobnie byłyby bardziej niż odpowiednie (patrzę na ciebie z miłością, EdgeRouter Lite).Więc po co zawracać sobie głowę tym wszystkim? Istnieje kilka uzasadnionych korzyści tutaj:

• Jest to rzeczywiście bardzo przystępne. Mój router przeszedł moje benchmarki z latającymi kolorami, i ma każdą funkcję, którą mógłbym ewentualnie wyciągnąć z Linuksa (co jest dużą listą).
• Jest bezpieczny. Mam wrażenie, że co miesiąc ogłaszana jest nowa luka w zabezpieczeniach jakiegoś urządzenia brzegowego sieci konsumenckiej. Porównaj to z samozarządzającym się firewallem, i wiem dokładnie, które usługi są narażone (a jeśli iptables jest uszkodzony, świat ma większe problemy). Dla wszystkich naiwniaków, przy okazji, jedynym portem nasłuchującym na moim firewallu jest losowy, wysoko numerowany port do uwierzytelniania ssh tylko za pomocą klucza publicznego. Więc tak, myślę, że jest to bardziej bezpieczne niż niektóre Huawei router konsumentów.
• To ma świetne funkcje. Jasne, mój espressobin może routować i służyć jako firewall, ale wrzuciłem też kilka innych przydatnych funkcji.
• Jest wydajny. W drobnych benchmarkach, które przeprowadziłem, espressobin może naprawdę zwiększać ruch sieciowy, nie pocąc się przy tym ani trochę.
• Budowanie go było naprawdę przyjemne. Jeśli a) potrzebujesz nowego routera lub b) chcesz ostrzyć sobie zęby na jednopłytkowym projekcie ARM, to może być dobry wybór.

Część pierwsza: Sprzęt

Technicznie można złożyć router używając dowolnego komputera z dwoma NIC, ale możemy zrobić to równie dobrze z mniejszą mocą, mniejszą obudową i bardziej przystępnie.Płyty ARM hit słodki punkt: są super tanie, bardziej wydajne niż myślisz, i dobrze obsługiwane z tak wielu wariantów na rynku.

Najbardziej znanym rywalem jest Raspberry Pi, ale bez dwóch NIC lub sieci gigabitowej, to nie jest dobra opcja.Plus, płacisz za rzeczy takie jak GPU, które nie są konieczne w bezgłowym urządzeniu sieciowym.

Dobrą wiadomością jest to, że w zeszłym roku, espressobin został wydany i jest super zdolny.Czuje się specjalnie zbudowany dla tego typu rzeczy: gigabitowa sieć, wbudowany przełącznik, i nie ma żadnych bajerów, które w przeciwnym razie trzeba by dla czegoś bardziej ogólnego przeznaczenia (nie ma nawet wyświetlacza, tylko konsola szeregowa).

Pomimo, że płyta jest dość młoda, zarówno Armbian jak i Arch Linux Arm wspierają sprzęt, a oba projekty wykonują świetną robotę w tym zakresie.Jeśli nie zbadałeś świata Linuksa na ARM, nie ma się czego obawiać.Armbian i Arch Linux Arm zapewniają wszystko, czego potrzebujesz dla aarch64 natywnie w repozytoriach dystrybucji, więc nie ma nic, że natkniesz się, że czuje się obcy na 64-bitowym układzie ARM, i to na pewno czuje się warto, gdy czynnik w przystępnej cenie sprzętu i niskiej mocy footprint.

Oto niektóre z najważniejszych dla mnie:

• Płyta zawiera wbudowany przełącznik sieciowy Topaz. W moich testach sieciowych ruch, który przechodzi tylko przez interfejsy LAN jest nie do odróżnienia pod względem szybkości od ruchu przechodzącego przez waniliowy przełącznik. Jeśli strumieniujesz z NAS lub masz w inny sposób wysokie wymagania dla komunikacji między urządzeniami, które przekraczają router, może to zrobić dużą różnicę.
• Seryjna konsola jest obywatelem pierwszej klasy. Na moich Raspberry Pis, czasami byłem sfrustrowany sięgając po wyświetlacz HDMI podczas debugowania problemów, ale espressobin ma port szeregowy micro USB dla łatwego dostępu do konsoli.
• Układ aarch64 był świetny. Nie tylko poradził sobie ze wszystkim, co na niego rzuciłem, ale czy wiesz, że nie jest dotknięty przez meltdown? Chipy Cortex-A53 nie są dotknięte błędem speculative execution, więc to dodatkowy bonus.

Co z WiFi?

Postaram się tu dodać małą wzmiankę, że próbowałem wykorzystać espressobin jako punkt dostępowy sieci bezprzewodowej.Płyta posiada gniazdo mini PCIe dobrze przystosowane do karty bezprzewodowej, i choć powinno to zadziałać, mogę definitywnie stwierdzić, że nie jest to dobry pomysł.

Bez wchodzenia w bolesne szczegóły, jest mnóstwo problemów, które nie czynią go wartym wysiłku.Nie mogłem uzyskać pasm 5Ghz działających w każdym scenariuszu, moja usługa hostapd 2.4Ghz stawała się nieresponsywna co dwanaście godzin lub tak, a prędkości były szokująco złe.

Wszystko to zostało powiedziane, moim zamiarem na początku tego projektu było oddzielenie mojego AP od mojego routera, niezależnie od tego czy skończę używając espressobin czy nie.Trzymanie zadań firewalla/routingu z dala od sieci bezprzewodowej jest miłą separacją obaw, i możesz dostać bardzo dobre dedykowane urządzenia AP bez żadnych funkcji poza nadawaniem sygnału, aby utrzymać je prostymi i potężnymi.

Dla tego co jest warte, skończyłem kupując urządzenie Ubiquity UniFi i byłem z niego całkowicie zadowolony.

Część druga: Oprogramowanie

Są tu dwa duże wybory: OS i oprogramowanie firewall.

Operating System

Pierwszym wyborem jest to, czy chcesz to zrobić ręcznie z dystrybucji, która obsługuje aarch64 lub użyć gotowego rozwiązania podobnego do firmware, takiego jak OpenWRT.Osobiście odkryłem, że zawsze gdy używam kurczowo zawijanego rozwiązania jak Tomato/OpenWrt lub FreeNAS do budowy, zazwyczaj jestem sfrustrowany nie mogąc naprawdę dostać się tam i podrasować rzeczy, więc będę używał dystrybucji Linuksa ogólnego przeznaczenia dla systemu operacyjnego.

Jak wspomniałem wcześniej, Armbian i Arch Linux ARM wspierają płytę, a espressobin ma oficjalną dokumentację dla Ubuntu (jak również Yocto, którego do tej pory nie znałem).Chociaż nie powiem ci, co jest najlepsze dla twojego przypadku użycia, oto dlaczego wolałem Arch Linux Arm:

• Jestem całkowicie sprzedany na toczeniu dystrybucji release.
• Jestem również sprzedany na uruchomienie atop krwawienie najnowocześniejszych distro. W przypadku routera, miło jest być blisko upstreamu, kiedy potencjalnie związane z bezpieczeństwem aktualizacje są wydawane.
• Arch zapewni nam czystą bazę do budowania bez żadnych obcych usług. Oznacza to, że mając minimalną bazę, możemy dokładnie wiedzieć, co będziemy mieli zainstalowane, odsłonięte i działające po złożeniu elementów razem.
• Znam i lubię ludzi z Arch Linux ARM. Cześć WarheadsSE!

Firewall

Niektóre nazwy jak PFSense natychmiast przychodzą mi na myśl, ale naprawdę chciałbym uruchomić coś na Linuksie, ponieważ znam go znacznie lepiej niż BSD (plus, najlepsze opcje OS dla espressobin są oparte na Linuksie).

Ogólnie, dobry demon firewall powinien:

• Pasować do profilu „zdrowego projektu OSS”. Oznacza to, że powinien być aktywnie utrzymywany, istnieć przez jakiś czas i mieć przyzwoite przyjęcie.
• Unikać złożoności. Proste projekty są łatwiejsze do debugowania, rozszerzania i obsługi.
• Obsługuje pewne miłe dla oka funkcje, takie jak obsługa kształtowania ruchu i łatwa konfiguracja przekierowania portów.

Po rozejrzeniu się przez chwilę, zdecydowałem się na Shorewall.Oto niektóre z bardziej godnych uwagi powodów, dla których wybrałem to rozwiązanie:

• Przepływ konfiguracji jest kompiluj-i-stosuj. Zapewnia to, że nasz zestaw reguł jest zdrowy przed jego zastosowaniem, co oznacza również, że nie ma demona zużywającego zasoby urządzenia, co jest istotne w przypadku małego komputera jednopłytkowego.
• Wbudowana jest w to duża ilość wiedzy historycznej, więc reguły iptables, które są wypluwane, obsługują wiele przypadków brzegowych, o których normalnie byśmy nie pomyśleli.
• Więcej na ten temat powiem później, ale oznaczanie pakietów i natywne wsparcie dla kształtowania ruchu sprawiają, że klasowe qdisc jest łatwe.

Część trzecia: The Basic Build

Ten post nie ma być wyczerpującym przewodnikiem, ale chciałem zawrzeć w nim najważniejsze punkty, aby było widać, jak łatwo jest to wszystko złożyć.

Instalacja systemu operacyjnego

Ta jest łatwa – wystarczy postępować zgodnie ze stroną Arch Linux Arm espressobin.Szczególnie ważne jest zwrócenie uwagi na dodane flagi w poleceniu mkfs.ext4 i dodatkową konfigurację U-Boot.

Konfiguracja systemu operacyjnego

Ogólnie, instalacje Arch Linux Arm są całkiem dobrze ustawione od samego początku.Oczywiście, będziesz chciał ustawić użytkownika nie-roota do administrowania, który nie jest kontem domyślnym, więc pamiętaj, aby wyłączyć użytkownika alarm, zmienić wszystkie hasła i zaktualizować system.

Jako uwaga poboczna, gorąco polecam zainstalowanie pakietu pacmatic i używanie go zamiast zwykłego pacman.Automatycznie wykryje on aktualizacje plików konfiguracyjnych i pomoże je scalić, jak również inline ważne wiadomości dla łamiących zmiany pakietów.

W dodatku, sugerowałbym skonfigurowanie etckeeper do śledzenia konfiguracji firewalla (wiki Archa ma dobre wprowadzenie).Ja skonfigurowałem mój do automatycznego pchania do prywatnie hostowanego repo gitolite.Aby być całkowicie szczerym, nie lubię każdego rozwiązania do zarządzania konfiguracją, a prawie wszystkie nasze zmiany są ograniczone do /etc, więc jest to wystarczająco dobre rozwiązanie zapasowe przynajmniej dla mnie.

Zauważ, że domyślna konfiguracja sieci dla espressobin działa dobrze dla przypadku użycia routera:

• Oba interfejsy lan, lan0 i lan1, są zmostkowane do interfejsu br0. To pozwala nam scentralizować rzeczy związane z prywatną siecią, takie jak dnsmasq, na jednym wirtualnym interfejsie.
• Interfejsem publicznym jest wan. Będzie on pobierał swój adres od dostawcy usług internetowych poprzez DHCP.

Jedyne zmiany konieczne do skonfigurowania br0 i wan dla naszego routera to dwa dodatki: po pierwsze, przypisanie interfejsowi LAN statycznego IP, ponieważ będzie to router, oraz włączenie przekierowania IP i maskarady IP w /etc/systemd/network/br0.network:

Address=192.168.1.1/24IPForward=ipv4IPMasquerade=yes

I potwierdzenie, że interfejs WAN będzie żądał adresu od ISP w /etc/systemd/network/wan.network:

DHCP=yesIPForward=ipv4UseDNS=no

Ustawiłem tutaj UseDNS=no, ponieważ wolę używać serwerów OpenNIC zamiast serwerów mojego upstreamowego ISP – o tym gdzie je ustawić wspomnę później.

Firewall

W repozytoriach Arch Linux ARM aarch64 znajduje się najnowsza wersja Shorewall, której właśnie użyłem. Moje konfiguracje nie są zbyt wymyślne, a jeśli poważnie rozważasz wdrożenie Shorewall z połączeniem do dzikiego Internetu, gorąco polecam przeczytanie całości wstępu Shorewall do dwuinterfejsowego firewalla.Obejmuje on podstawy tego, jak powinieneś skonfigurować rzeczy z ładnym podsumowaniem routingu i firewalli w ogóle.

Podstawowo, umieścisz interfejsy br0 i wan w odpowiednich strefach i ustawisz wszelkie niezbędne reguły w /etc/shorewall/rules.Pamiętaj, aby hosty w sieci LAN mogły korzystać z Twojego serwera DNS:

DNS(ACCEPT) loc $FW

Potwierdzisz, że DHCP jest dozwolony na interfejsie LAN w pliku interfaces.

Zauważę tutaj, że podczas konfiguracji firewalla natrafiłem na błąd w Shorewallu, który okazał się być załatany dosłownie dzień wcześniej – a Arch Linux ARM miał już zaktualizowany pakiet w repozytoriach upstream. Jeden punkt za używanie aktualnych distro.

DHCP

dnsmasq jest idealnym rozwiązaniem dla domowego routera. Łączy w sobie serwer DNS i DHCP w lekkiego demona, który obsługuje wszystko czego można potrzebować w małej sieci, i jest na tyle dojrzały, że istnieje wiele dokumentacji na jego temat.

Uwaga: Próbowałem użyć wbudowanego w systemd serwera DHCP, który można ustawić za pomocą DHCPServer= w plikach .network, ponieważ wydawało się, że jest to lekki sposób na uruchomienie serwera DHCP bez dodatkowego oprogramowania.Nie będąc zbyt dokładnym, nie jest to warte zachodu, jednym z istotnych powodów jest to, że nie ma sposobu na znalezienie bieżących dzierżaw adresów.

Jest wiele opcji, które powinny być tutaj ustawione, ale najważniejsze to:

# 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

Jeśli potrzebujesz statycznych przydziałów lub aliasów, są one również łatwe do dodania.

Część czwarta: Interludium

Z espressobin obsługującym żądania DHCP i DNS na br0, zaporą ogniową przez Shorewall i routingiem pakietów między LAN i WAN, jest to działający router. W tym momencie, podłączenie portu WAN do ISP upstream i dwóch portów lan0/lan1 do urządzeń lub innego przełącznika jest wszystkim, co jest konieczne.

Jednakże, to dopiero początek.Jeśli naprawdę chcemy rozważyć ten zamiennik routera, jest kilka naprawdę fajnych rzeczy, które możemy zrobić, aby dalej podnieść jego możliwości, tak, że nie czuje się jak downgrade z czegoś takiego jak mój stary Asus N66U.

Część piąta: Upgrades

I przykręcony na następujących funkcji do mojej wanilii espressobin routera, który będzie każdy cover po kolei:

• Monitorowanie przepływu sieci
• Kształtowanie ruchu

Netflow Monitoring

Widoczność ruchu jest coś, co znalazłem naprawdę cenne z mojego Asus Merlin firmware do śledzenia wykorzystania.Netflow jest de facto standardem dla tego rodzaju rzeczy, a wśród wszystkich dostępnych opcji, naprawdę lubię ipt-netflow, ponieważ jest to natywny moduł jądra, więc jest bardzo mały narzut i jest bardzo aktywnie utrzymywany.

Okazuje się, że jestem prawdopodobnie pierwszą osobą, która używa go na architekturze aarch64, ponieważ uzyskałem pomoc w jego obsłudze na chipsecie aarch64. Opiekun projektu był (i jest) bardzo wyczulony na poprawki błędów, więc nie miałem żadnych problemów z zapewnieniem, że moduł jest obsługiwany na najnowszych jądrach, na których działa projekt Arch Linux ARM.

Używanie go jest kwestią zainstalowania pakietu ipt-netflow-dkms-git z AUR.Zbuduje się on dla twojego jądra, ponieważ dkms jest niesamowity, a ja wrzuciłem poniższe do /etc/modules-load.d/ipt-netflow.conf

ipt_NETFLOW

To go załaduje, a ty skonfigurujesz go w /etc/modprobe.d/ipt-netflow.conf:

options ipt_NETFLOW destination=$ip:2055 protocol=5

Gdzie $ip jest twoim miejscem docelowym netflow.Wreszcie, ruch jest przechwytywany przez przepływ do specjalnego celu iptables, co można zrobić bezpośrednio z shorewalla, wygodnie.W /etc/shorewall/start:

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

To kieruje wszystkie pakiety na routerze najpierw do celu NETFLOW przed czymkolwiek innym, który przetwarza pakiety i przekazuje je z powrotem do przepływu przez normalne reguły, które Shorewall ustawia.

Oczywiście, ipt-netflow potrzebuje miejsca do wysyłania logów netflow, ale to jest poza zakresem tego postu.W moim przypadku, mam instancję Logstash działającą w mojej sieci z modułem netflow działającym i agregującym zdarzenia w klastrze Elasticsearch.To daje mi kilka wygodnych dashboardów i możliwość wizualizacji szerokiej gamy informacji o mojej sieci.Istnieje kilka domyślnych pulpitów nawigacyjnych:

W tym kilka całkiem fajnych, takich jak Geo-IP dashboard:

Jednakże najbardziej istotną metryką, którą jestem zainteresowany, jest moje całkowite wykorzystanie pasma, ponieważ mam antediluvian ISP, który dba o limity danych.Na szczęście jest to łatwe z danymi netflow, które zbieram: możemy po prostu poprosić Elasticsearch o zsumowanie niektórych pól i uzyskać te metryki w prosty sposób.Poniższy pulpit ma dwie wizualizacje:

• Wskaźnik porównuje sumę w danym okresie czasu z limitem, który ustawił dla mnie mój dostawca usług internetowych, więc mogę łatwo zobaczyć, gdzie moje bieżące wykorzystanie leży w stosunku do limitu.
• Czasomierz przedstawia przepustowość w bajtach w czasie, aby zobaczyć, kiedy używam tej przepustowości.

Coś szczególnie fajnego w tej konfiguracji jest to, że ponieważ przechowujemy metryki netflow w Elasticsearch zamiast jakiegoś innego magazynu danych lub bazy danych szeregów czasowych, mogę faktycznie skoncentrować zapytania dla tych pulpitów w celu zrobienia takich rzeczy, jak tylko suma całkowitych bajtów dla pewnych zakresów CIDR, ponieważ bazowy silnik przechowywania (Lucene) rozumie natywnie adresy IP.Na przykład, następujące zapytanie w Kibana:

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

Będzie skutecznie filtrować potencjalnie duże kawałki pasma, które zdarzają się między hostami w mojej sieci LAN, takie jak strumieniowanie między moim hostem Kodi i maszyną NAS.Cool.

Traffic Shaping

Zmieniło się to w dość duże przedsięwzięcie, które było fascynującą króliczą norą, w której można było zniknąć.Niektóre akcje i większość niestandardowych firmware routerów oferują jakąś formę QoS lub kształtowania ruchu, więc miałem nadzieję zrobić to samo na moim niestandardowym routerze, aby chronić niektóre z mojego ruchu (jak Overwatch) z wysokich latencji.

Świat technologii QoS jest fascynującym miejscem.Podczas gdy można polegać na niektórych prostych schematów, takich jak HTB (hierarchical token bucket) filtr, postępy w filtrowaniu pakietów są zaskakująco aktywne i istnieje wiele ciekawych podejść.

Co w końcu osiadłem na był HFSC (hierarchical fair-service curve) filtr.Będę szczery: matematyka za nim jest tak poza moją ligą, że musiałem przeczytać kilka streszczeń próbujących rozbić go dla normalnych ludzi, a najlepszym wyjaśnieniem, które miało dla mnie sens, był doskonały gist, na który natknąłem się od użytkownika GitHub eqhmcow, który wyjaśnia korzyści i zastosowanie HFSC w praktyce.

Tl;dr jest taki: z klasą kontroli ruchu HFSC, możesz bardzo skutecznie nadawać priorytety ruchowi i osiągnąć dobrą równowagę między strumieniami, które wymagają wysokiej przepustowości i niskich opóźnień.To nie jest magiczna kula – nadal będziesz musiał zaznaczyć, jakie rodzaje ruchu są wrażliwe na opóźnienia – ale to działało całkiem dobrze dla mnie.Bez tych reguł, pobieranie Steam lub Blizzard Launcher zabije czasy pingów, podczas gdy aktywne reguły HFSC z wdziękiem przytną te ciężkie porcje ruchu, aby zapewnić, że interaktywne strumienie nie zostaną naruszone.To naprawdę świetne!

Wspomniany wcześniej gist wykonuje dobrą robotę, określając, jak skonfigurować klasy tc od zera.Jednak Shorewall może faktycznie obsługiwać klasową kontrolę ruchu natywnie, więc możemy skonfigurować potężne reguły QoS całkiem łatwo.Poniższe pliki konfiguracyjne są oparte na moich zmierzonych prędkościach pasma, które wynoszą około 230 w dół i 10 w górę.

Pierwszym krokiem jest ustawienie odpowiednich klas tc dla każdego urządzenia w pliku tcdevices:

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

Tutaj interfejs LAN br0 dostaje pełny gigabit, ale interfejs WAN wan dostaje 97% swojej prędkości w dół i 90% mojej dostępnej prędkości w górę.Rozumowanie dla tych liczb jest wyjaśnione w gist – zasadniczo odtwarzamy ten zestaw reguł w kategoriach Shorewall.

Następnie definiujemy, w jaki sposób znaczniki pakietów będą mapowane do tc klas w pliku 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

To spowoduje zrzucenie ważnego/interaktywnego ruchu do klas, które otrzymają wyższy priorytet.Oczywiście, musimy również oznaczyć pakiety, które powinny otrzymać wyższy priorytet, co robimy w 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

To ustawia znaczniki wysokiego priorytetu (1 i 2), które będą obsługiwane przez naszą klasę tc.Przykład zawiera pingi ICMP, ssh, niektóre gry Blizzarda i ruch lokalny.

Reloading shorewall powinien wprowadzić je w życie.Wynik końcowy powinien pozwolić na ruch masowy, taki jak pobieranie lub strumienie, nie wpływając negatywnie na opóźnienia w ruchu interaktywnym, takim jak ssh, czasy pingów w grze, i tak dalej.Moje nieformalne testy potwierdziły to – zauważ, że jeśli zdecydujesz się zweryfikować to samemu, możesz zaobserwować skoki opóźnień bezpośrednio po początkowym wybuchu ruchu masowego, ale HFSC szybko wprowadza ograniczenia, aby utrzymać niskie opóźnienia dla ruchu interaktywnego.

Mam kilka zestawów benchmarków, które pokazują HFSC w akcji, ale oto mały przykład: jak wpływają na opóźnienia pingów, gdy iperf jest uruchamiany w tle.

Jak widać, bez żadnych reguł kontroli ruchu w miejscu, wybuchy ruchu masowego mogą mieć bardzo negatywny wpływ na interaktywny ruch wrażliwy na wysokie opóźnienia.Z HFSC, możemy uniknąć tych problemów.

Wnioski

Używam mojego domowego routera od kilku miesięcy i wydaje się, że działa świetnie.Nie doświadczyłem żadnych tajemniczych spadków połączenia, problemów z prędkością lub problemów sprzętowych przez cały okres ciągłej pracy, więc uznałbym budowę za sukces.Aktualizacje są w porządku, jak również; po normalnym sudo pacmatic -Syu i restart systemu wraca online z wszystkich reguł iptables i innych usług zgodnie z oczekiwaniami, więc utrzymanie się z najnowszych jąder i innych pakietów jest proste.

Podsumowując:

• Dla operacyjnie-savvy lub technicznie zorientowanych osób, niestandardowe router zbudować jest bardzo do zrobienia. Komputery jednopłytkowe ARM sprawiają, że rozpoczęcie pracy jest tanie i wygodne.
• RozwiązaniaOSS dla firewalli, kształtowania ruchu i monitorowania sieci są dojrzałe i łatwe do pracy. W szczególności, starsze rozwiązania takie jak Shorewall i dnsmasq są bardzo dobrze udokumentowane i mają wiele lat pracy włożonej w ich dokumentację i zestaw funkcji.
• While routing + DNS + DHCP to strzał w dziesiątkę, OSS WiFi może być hit lub miss. Twój przebieg może się różnić, ale mój espressobin po prostu nie jest dobrym punktem dostępu.

.