Chiński router z marzeń

Routery są fascynującymi urządzeniami – magiczne pudełka bez których połączenie dwóch sieci nie jest możliwe. Te klasy SOHO stoją w każdym domu czy mniejszym biurze, inne Enterprise zawalają szafy rackowe – każdy z nich robi to samo przekazuje pakiety z jednej sieci do innej. Szczególnie intrygująca mnie perspektywa to router jako komputer embedded. Kilka lat temu miałem wyobrażenie, że są to zaawansowane maszyny, których poziom skomplikowania przerasta możliwości śmiertelników – konfigurując je czułem się jak Prometeusz kradnący ogień. Pełen zachwytu wpisywałem tajemnicze numery w wyskakujące okna przeglądarki… klik… klik… klik… gotowe, działa. Jednak taki najprostszy router można kupić za niewielkie pieniądze. Jak to możliwe? Czemu tak skomplikowana technologia jest tak tania? A może to jednak nie jest aż tak skomplikowane? Co zrobić żeby zajrzeć pod maskę takiego urządzenia? Może na początek je rozkręcić. Pod pokrywą taniego plastiku ukryta jest płyta główna, na niej jakiś procesor, trochę RAMu, jakaś pamięć, gniazda sieciowe – nic czego byśmy nie znaleźli w normalnym PC. Architektura procesora trochę inna, ale generalnie nie ma to takiego znaczenia. Skoro sekret nie kryje się w hardwarze to może oprogramowanie jest tym co wyróżnia je od komputerów, które obsługujemy na co dzień. Przełom w myśleniu o tych urządzeniach nastąpił, gdy zorientowałem się, że dostępny jest alternatywny firmware dla urządzeń SOHO.

Wygrzebałem z szafy nieużywany, tani router i zainstalowałem na nim OpenWrt – łatwo poszło - wgrałem plik binarny przez ładne okienko załadowane przez oficjalny firmware producenta, jakiś pasek mignął, zaświeciły się diody jak lampki na choince i tadam… ale zaraz, gdzie jest piękny interface? gdzie proste w obsłudze guziki? gdzie rozwijane menu? Cóż trzeba było przeczytać instrukcję -wtedy wiedziałbym na co się piszę. Po fakcie dowiedziałem się, że muszę się zalogować prze ssh i wpisywać jakieś komendy - cóż.. za wysokie progi. Resztę wieczoru spędziłem na próbie wgrania innego firmware'u, w którym mógłbym coś wyklikać. Po kilku godzinach musiałem przyznać się przed sobą do porażki - "mogę go wyrzucić nic z niego nie będzie", "szybciej kupię drugi i wgram coś innego…". Gdy kurier przekazał mi paczkę z innym routerem już miałem w głowie plan zakupu kolejnego, w końcu z dwoma mógłbym zrobić to i to… Ale przydałby się czwarty, bo ma to i to… Każdy ma jakieś hobby, jedni zbierają znaczki - ja routery. Ilość urządzeń rosła, cierpliwość żony malała. W końcu miałem zakaz kupowania nowych urządzeń. Moja luba nie jest specjalnie techniczna, więc sprawdzała tylko ilość sztuk pod biurkiem - jeden router znikał, na jego miejsce pojawiał się inny – ilość się zgadzała. Taka zabawa trwała w najlepsze aż nie znalazłem sobie innej obsesji, ale to opowieść na inny wpis. Problem był taki, że nie udało mi się poznać dogłębnie działania tych urządzeń sieciowych, a za modemem ISP miałem kilka urządzeń, które w nocy oświetlały pokój zieloną poświatą. Postanowiłem rozwiązać te dwa problemy za jednym razem – zbuduje swój własny router, który zaspokoi wszystkie moje wymagania..

Ze świecą taki router szukać

Oczami wyobraźni widziałem już ten sprzęt - bezgłośny, mały komputer z przynajmniej dwoma portami Ethernet, idealny. Stanie w salonie, nie będzie irytował domowników hałasem ani przyciągał uwagi rozmiarem. Pierwsze na myśl wpadły mi modne ostatnio komputery NUC. Oryginał Intela - bardzo wydajny, nawet kompaktowy – niestety cena zaporowa jak na zabawkę, która ma przekładać pakiety z jednego portu na drugi. Brak drugiego portu powodował kolejny problem, potrzeby byłby dodatkowy switch z obsługą vlan, żeby ten problem rozwiązać – dodatkowy koszt, dodatkowe miejsce w salonie, poziom skomplikowania sieci domowej rośnie– ODPADA! Drugi port Ethernetowy okazał się dość sporym problemem. Długi czas nie mogłem znaleźć takiego urządzania na lokalnym rynku. W końcu sprawdziłem pewien popularny chiński sklep internatowy no i cóż… ilość ciekawych konstrukcji przeszła moje najśmielsze wyobrażenia. Widać projektanci z kraju środka mają znacznie większą fantazję, zwłaszcza w klasie mini pc. Po kilku godzinach wybierania upatrzyłem sobie model, zamówiłem i czekam. Paczka zawitała dość szybko, bo po 3 dniach. Po opłaceniu haraczu za przewiezienie przesyłki przez niewidzialną linię mogłem już cieszyć się z nowego nabytku.

Bohater drugiego planu

W tej opowieść sam hardware nie jest aż tak istotny – mógł być to dowolny komputer, a dalsza część tego wpisu dalej miałaby sens. Nie będę więc zbyt opisywał mojego zakupu, ale z kronikarskiego obowiązku przytoczę parę szczegółów na jego temat. Ów nabytkiem okazał się X30G firmy XCY MINI PC COMPUTER Co.,Ltd. Pierwszy raz słyszałem o tej marce. Przeglądając ich stronę już po zakupie miałem wrażenie, że ktoś ją na szybko stworzył, dorzucił zdjęcia ze stocka – pełno tam zadowolonych pracowników korporacji po zapewne udanym zakupie, część rubryk nie jest uzupełniona, a firmowa poczta jest w domenie qq.com - całość nie wróżyła najlepiej. Spodziewałem się marnej jakości komputera z tanimi podzespołami. Gdy otworzyłem paczkę trochę się zdziwiłem, gdyż całość była spakowana profesjonalnie i dodatkowo dołączony był uchwyt VESA.

Od razu zacząłem rozkręcać obudowę by spojrzeć jak konstrukcja wygląda od środka. Obudowa jest zrobiona z czarnego aluminium (chyba, choć pomalowana) i służy za radiator dla procesora – ciekawe rozwiązanie, zobaczymy czy się sprawdzi. Samym CPU jest Intel J1900 nic szykownego. Tani, energooszczędny procesor sprzed 4 lat. W środku było jeszcze 2GB RAMu, słaba karta sieci bezprzewodowej oraz tani chiński dysk SSD. Kartę od razu wymieniłem na coś lepszego co mi zalegało w szufladzie, a dysk – tyle się nasłuchałem o jakości tanich dysków SSD, że z ciekawości zobaczę kiedy wyzionie ducha. Na obudowie można uświadczyć sporą ilość portów mi 4x USB 3.0, 2x COM, 2x Ethernet HDMI, VGA oraz Audio.

Co tam będzie w środku ?

Zastanawiałem się jaki system operacyjny zainstalować na tej maszynie. Z początku skłaniałem się do jakiejś dystrybucji skupionej wokół routerów np. OpenWrt czy VyOS. Doszedłem jednak do wniosku, że to nie ma sensu i użyje tego co używam na co dzień. Zwłaszcza, że tak naprawdę nie ma to znaczenia, do celów jakich będzie wykorzystywany mój domowy router każdy Linux się nada. Podane tu ścieżki i nazwy pakietów mogą różnić się w innych dystrybucjach – ja użyłem Archa. Pominę samą instalację systemu – w założeniu mam gotową instalację z dostępem do sieci i możliwością logowania się po ssh.


Wstępna kosmetyka

Na początek zmieniłem nazwy interface'ów sieciowych – to kosmetyka, nie konieczność. W tym celu tworzę plik /etc/udev/rules.d/network.rules

vim /etc/udev/rules.d/network.rules

SUBSYSTEM=="net",ACTION=="add", ATTR{address}=="12:34:56:78:9a:bc",NAME="wan01"
SUBSYSTEM=="net",ACTION=="add", ATTR{address}=="12:34:56:78:9a:bd",NAME="lan01"
SUBSYSTEM=="net",ACTION=="add", ATTR{address}=="12:34:56:78:9a:be",NAME="wlan01"

Podałem mac istniejących interface'ów by zmienić ich nazwę. Tu uwaga -pomyłka w tym pliku może kosztować utratę sieci po restarcie :) Wiem, bo sprawdziłem!

Spiąłem port ethernetowy i wlan w jeden logiczny port – bridge. Nie było to konieczne, ale ułatwiło konfigurowanie innych usług, zwłaszcza że jest to dość prosty zabieg.

Utworzyłem plik konfiguracyjny z krótkim konfigiem

vim /etc/netctl/br01

Description="Opis ku pamieci"
Interface=br01
Connection=bridge
BindsToInterfaces=(lan01 wlan01)
IP='static'
Address=(192.168.1.1/24)

Pozostało mi tylko uruchomić bridge.

netctl start br01
netctl enable br01


Tam dom twój gdzie WiFi łączy się automatycznie

Z reguły domowej klasy routery dostarczają możliwość utworzenia na nich access pointa – też zapragnąłem taki skonfigurować na moim urządzeniu. W tym miejscu muszę przytoczyć kilka spostrzeżeń po tym doświadczeniu – nie ominie nikogo wertowanie dokumentacji, sprawdzanie jakie sztandary obsługuje karta sieciowa oraz zrozumienie, że nie zawsze producent deklarowane standardy wypełnia albo robi to w pokrętny sposób :) Mój AP uruchomiłem z zadowalającym skutkiem, ale nie było łatwo – przyznam, że pretensje mogę mieć tylko do siebie, gdyż popełniłem poważny błąd strategiczny przy kupowaniu sprzętu. Płyta główna obsługuje tylko dwie karty mini PCI, w tym jedną half size – to niestety odcina drogę do różnych ciekawych kart sieciowych. Dziś bogatszy o te doświadczenia szukałbym czegoś co obsługuje standard m.2 – byłoby pewnie drożej, ale ciekawiej. Udało mi się uruchomić AP przy pomocy HostAP. Trzeba zacząłem od instalowania odpowiednich pakietów hostapd oraz o rng-tools - ma on wzmocnić entropie liczb pseudolosowych.

pacman -S hostapd rng-tools 
systemctl enable rngd.service
systemctl start rngd.service

Konfiguracja samego hostap do łatwych nie należy dla osób niebędących na bieżąco z tym, co w WiFi piszczy. Sam standard IEEE 802.11 rozwija się bardzo dynamicznie i zaskoczyło mnie jak dużo się zmieniło, gdy nie interesowałem się nim prze parę lat - więc swoje na tym odsiedziałem.

Najłatwiej pobrać cały plik konfiguracyjny wraz z komentarzami, zaparzyć sobie duży kubek ulubionej używki i przystąpić do grzebania w nim :)

wget -P /etc/hostapd/ <span id=<span class="hljs-string">"<span id="https://w1.fi/cgit/hostap/plain/hostapd/hostapd.conf">https://w1.fi/cgit/hostap/plain/hostapd/hostapd.conf</span>"</span>>https://w1.fi/cgit/hostap/plain/hostapd/hostapd.conf</span>

Po dłuższym posiedzeniu i próbach dla mojej karty sieciowej plik wyglądał tak

##### hostapd configuration file ##########
interface=wlan01
bridge=br01
hw_mode=g
driver=nl80211
channel=0
ignore_broadcast_ssid=0
logger_syslog=-1
logger_syslog_level=2
country_code=PL
wmm_enabled=1
ieee80211d=1
ieee80211n=1

ht_capab=[HT40+]

acs_num_scans=5
acs_chan_bias=1:0.8 6:0.8 11:0.8
rsn_pairwise=CCMP



ssid=foo_bar
wpa_passphrase=foobarpassword
wpa_key_mgmt=WPA-PSK
wpa=2
auth_algs=1

Samą konfiguracje można uruchomić testowo w trybie debugowania za pomocą parametru -d im więcej d tym bardziej robi się szczegółowo

hostapd /etc/hostapd/hostapd.conf -d

Gdy wszystko gotowe i przetestowane wystarczyło uruchomić usługę

systemctl start hostapd.service
systemctl enable hostapd.service


Serwer dhcp

Mój router powinien mieć serwer dhcp – męczące byłoby ustawianie wszystkiego ręcznie :) Ja preferuje dhcpd - prostota i elegancja.

pacman- S dhcp

Edytowałem plik konfiguracyjny

vim /etc/dhcp

I doprowadziłem go do poniższego stanu

shared-nietwork foobar {

# siec foobar network
subnet 192.168.1.0 netmask 255.255.255.0 {
  option domain-name "foo.bar";
  option routers                  192.168.1.1;
  option subnet-mask              255.255.255.0;
  option broadcast-address        192.168.1.255;
  option domain-name-servers	  1.1.1.1, 1.0.0.1;
  default-lease-time 86400;
  max-lease-time 86400;

range 192.168.1.100 192.168.1.200;

  }
}

W Archu nie ma domyślnie stworzonej usługi w systemd dla dhcpd – stworzyłem plik /etc/systemd/system/dhcpd4@.service, który prezentował się jak poniżej

vim /etc/systemd/system/dhcpd4@.service

[Unit]
Description=IPv4 DHCP server on %I
Wants=network.target
After=network.target

[Service]
Type=forking
PIDFile=/run/dhcpd4.pid
ExecStart=/usr/bin/dhcpd -4 -q -pf /run/dhcpd4.pid %I
KillSignal=SIGINT

[Install]
WantedBy=multi-user.target

I voila serwer dhcp działa - można podłączać tostery do sieci :)


Maskarada

Jak na razie moje urządzanie daje dostęp do sieci LAN dla wszystkich chętnych. Wepniesz się kablem - dostajesz IP, połączysz się przez WiFi również przydzielone zostanie IP. Nie mamy jednak dostępu do sieci podłączonej do portu WAN. Żeby schować naszą sieć za NATem utworzyłem reguły w iptables – nie filtruje na razie żadnego ruchu - na to przyjdzie czas później - na razie niech tylko pakiety przechodzą z jednego interfaceu na drugi wraz z podmianą adresu źródłowego oraz portów. Utworzyłem plik iptables.rules wraz z poniższymi regułami oraz uruchomiłem usługę.

vim /etc/iptables/iptables.rules

*nat
-A POSTROUTING -o wan01 -j MASQUERADE
COMMIT


*filter
-A FORWARD -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -i br01 -o wan01 -j ACCEPT
COMMIT

systemctl start iptables.service
systemctl enable iptables.service

W tym momencie routing się jeszcze nie odbywał - pakiety nie mogły przemieszczać się pomiędzy interfaceami. Żeby temu zaradzić należy zmienić parametr jądra przez wydanie polecenia

sysctl net.ipv4.ip_forward=1

Oczywiście to będzie przynosiło efekt do ponownego uruchomienia maszyny. By przy każdym restarcie ten parametr miał wartość 1 utworzyłem plik /etc/sysctl.d/ipforward.conf i tam wprowadziłem wartość z jaką system ma się uruchamiać.

vim /etc/sysctl.d/ipforward.conf

net.ipv4.ip_forward=1

Bieda router

W tym momencie router działa - mogę spokojnie przeglądać dobreprogramy.pl! Konfiguracja wymaga jeszcze wielu szlifów nim będę mógł powiedzieć o tym urządzeniu "router marzeń". Czy było warto? Pod względem finansowym na pewno nie, za dużo mniejszą sumę mógłbym kupić gotowe urządzenie z półki w sklepie, które pewnie na dziś dzień byłoby wydajniejsze i prostsze w konfiguracji. Zbudowanie tego urządzenia pozwoliło mi w pewien sposób spełnić się i sprawdzić czy po prostu dam radę zrobić takie rzeczy, które kiedyś były dla mnie niewyobrażalne. Nie zamierzam spocząć na laurach i mam już kilka pomysłów jak udoskonalić serce mojej domowej sieci – szykuje się mnóstwo zabawy!


  

linux internet serwery

Komentarze