SLA na poziomie 99,5% robi wrażenie, prawda? Przy okazji dyskusji pod wpisem u Boniego poleciało 99.5% jako synonim jakości (czegoś tam). Co z kolei skłoniło mnie do sprawdzenia, jak to się ma do danych dotyczących dostępności łącza, które wystawiam przy pomocy PUM. No i w skrócie: 99,5% dostępności w skali miesiąca to żaden wyczyn.
Na początek disclaimer: nie jest to wyraźnie napisane w FAQ, ale z tego co się dowiedziałem od autorów/supportu. Uptime Robot w wersji darmowej nie zlicza (poprawnie?) uptime dla okresu powyżej jednego miesiąca. Co niestety nie przeszkadza mu zwracać jakichś wartości dla okresów powyżej 30 dni.
The Free Plan can return uptime ratios back to 1 month due to the limit of the logs kept. The Pro Plan supports back to 1 year. And, the alltimeuptimeratio variable in the API currently returns 1-month uptime (and it’ll be removed from the APIv2).
I jak widać z powyższego, All uptime to tak naprawdę, w przypadku planu darmowego, uptime dla poprzedniego miesiąca.
Spójrzmy na the domek. Komputer Linuksem, dokładnie, Seagate Dockstar robiący za router, więc trochę embedded w porównaniu z typowym PC, czyli bardziej niezawodny. Za to z dyskiem w kieszeni USB, bez jakiegokolwiek podtrzymania prądu przy pomocy UPS. Łącze przez wiekowy modem USB, 3rd party dostawca over linia TPSAOrange (BSA).
Aby było weselej: połączenie resetowane raz dziennie, skrypt podnoszący/sprawdzający uruchamiany co 4 minuty , a PPPoE trochę wstaje…
I cała ta rzeźba, łącznie z przerwami po stronie 3rd party usługodawcy, Orange, dostawcy monitoringu (czyli Uptime Robot), zwłoką przy odświeżaniu dyndns (monitoring jest po domenie) i problemami w globalnym internecie daje radę. Generalnie, bo oczywiście są miesiące, że nie da.
SLA 99,5% my ass… 😉
[1] Nie pamiętam już, czemu tak, zdaje się, że musiał mieć chwilę na sprawdzenie albo ubicie pppd. Albo nie chciało mi się pisać obsługi lockfile’a, bo parę minut przerwy w nocy i tak jest pomijalne w tym zastosowaniu…
Od dłuższego czasu myślałem o tym, by zmienić router. Problem w tym, że Linksys WRT54GL, którego miałem, działał. Do tego miał wrzucone OpenWrt, więc był bezpieczniejszy i wygodniejszy, niż większość dostępnego sprzętu. Koniec końców zracjonalizowałem sobie następująco. Po pierwsze 802.11n jest odporniejsze na zakłócenia bo trochę problem z zasięgiem/zakłóceniami owszem, był. Po drugie, szybsze – osiągnięcie maksymalnej prędkości netu możliwe było tylko teoretycznie. I w ogóle lepsze. No i jest sporo modeli, które pozwalają na wgranie OpenWrt.
Trochę poczytałem, trochę poklikałem TP-Linka u kumpla (na firmware producenta), popatrzyłem na ceny… I kupiłem TP-Link WR841-N (wyszło mi, że umie OpenWrt, niedrogi, wrażenie u kumpla – bdb) w markecie na jakiejś pseudopromocji. Nie pamiętam dokładnie ile zapłaciłem, ale jakoś 60-80 zł[1]. I leżał. Z kwartał. Bo nie chciało mi się wymienić routera, skoro stary działał…
Ostatnio zauważyłem, że pojawiają problemy z siecią okresowo. Pingi do routera rzędu 1000ms. Potem działało normalnie. Kanał ustawiony optymalnie, przynajmniej na tyle, na ile się dało. Stwierdziłem, że pora przetestować router.
Pierwsze co mi się rzuciło w oczy po otwarciu pudełka od TP-Link WR841-N, to informacja o licencji GPL wydrukowana na świstku papieru (po angielsku) i polska instrukcja. Miłe i sprawia dobre wrażenie. W instrukcji dla tych, którzy nie korzystają z dołączonej płyty CD zauważyłem ciekawą rzecz. Aby podłączyć się do routera polecają nie wpisanie adresu typu http://192.168.0.1 tylko… http://tplinklogin.net . Tak, domena nie istnieje i IMHO jest to bug security. Scenariusz, gdzie użytkownik łączy się z netem przy pomocy takiego routera (domyślne login i hasło to admin/admin), wchodzi na stronę i dostaje malware w postaci JS, który przejmie kontrolę nad routerem nie jest wcale trudny do wyobrażenia. Co prawda podobno TP-Linki w swoim DNS mają zaszytą tę domenę i same rozwiążą to zapytanie, jeśli tylko komputer pobiera zarówno adres IP, jak i konfigurację DNS z DHCP, ale… po co?
Oczywiście połączyłem się po IP, bo taka wersja też działa. Przy tym mam inną konfigurację i serwer cache DNS mam bezpośrednio na komputerze. Dalej było z górki. Przeklikałem wstępnie konfigurację (wyłączenie WDS, ustawienie preferencji WiFi). Potem pobrałem najnowszy firmware producenta (na OpenWrt przyjdzie jeszcze czas…) i wrzuciłem go na urządzenie. Wszystko zadziałało elegancko (ba, pierwszy firmware był nawet po polsku). Sympatycznie wygląda opcja, której włączenie pozwala routerowi samodzielnie wybierać kanał. Włączyłem, zobaczę jak to się w praktyce będzie sprawdzać. Inna miła rzecz to obsługa kilku dostawców dyndns, w tym no-ip.com, z którego korzystam. Nie skonfigurowałem, ale czuję, że może to być ten punkt, który pozwoli mi na długie nie wgrywanie OpenWrt. Wstępny test prędkości i… zamiast 15-18Mbps które widziałem do tej pory jest ~30Mbps.
Oczywiście nie wszystko mogło działać poprawnie. Windows na jednym z kompów stwierdził, że adres IP z DCHP owszem, pobierze, ale już sieć nie działała. Nawet router się nie pingował. Karta to Atheros AR5007EG (a/b/g, niestety nie ma n). Spróbowałem na szybko uruchomić „pchełkę” Mediateka na USB, ale wyszło jeszcze gorzej. Sieć co prawda ruszyła, ale przy restarcie nie chciał się uruchomić system – krzyczał o błąd w DLL. Możliwe, że przedobrzyłem z ustawieniami programu pomocniczego do karty pozwalając mu włączyć sieć przed zalogowaniem użytkownika. Parę prób zmian konfiguracji na routerze (szerokość kanału itp.) nie pomogło. Włączenie trybu bez n – też nie. W końcu stwierdziłem, że trzeba ustalić, czy problem jest z samą kartą, czy systemem/sterownikiem. Uruchomienie Linuksa i… karta jak najbardziej działa.
Szybkie przeszukanie sieci i znalazłem zalecenie, by zaktualizować sterownik. I faktycznie. Problem rozwiązało pobranie najnowszych sterowników do Atherosa (a wydawało mi się, że mam względnie nowe…). Po aktualizacji sterownika karty wszystko ruszyło od kopa. O stabilności TP-Linka nic nie piszę, bo działa raptem kilkadziesiąt godzin. Póki co, jestem zadowolony.
[1] Linksys kosztował w momencie kupna IIRC 180 zł, choć nie był najtańszym sprzętem z *Wrt. Fajny spadek cen, wzrost możliwości i poszanowania GPL daje się zaobserwować.
UPDATE Jeszcze o jednej sympatycznej cesze TP-Link WR841-N zapomniałem – mały apetyt na prąd. Kiedyś mierzyłem, ile prądu bierze Linksys i wahało się to od 2,5W (sam zasilacz, duży, transformatorowy jeszcze), przez 6,9W (router idle, 2 komputery podłączone) do 7,5W przy transferze danych między dwoma komputerami po WiFi). Nowy router nie był dokładnie testowany, ale po włączeniu routera i jednego komputera watomierz pokazał 2,5W, czyli tyle, ile poprzednio sam zasilacz. Myślę, że mogę przyjąć, że jest to 5W mniej, czyli 3,6 kWh w skali miesiąca. Czyli ok. 2 zł oszczędności. Czyli na samym prądzie nowy sprzęt zwraca się w jakieś 3 lata.
Jest powiedzenie, że nowe to dobrze zapomniane stare. Tak jest w przypadku DNS i ataków różnej maści. Niedawno głośno było o DDoSach z użyciem DNS amplification, potem o podmianie DNS (głównie na routerach, nie jak kiedyś na komputerach, ale cel ten sam), a od niedawna popularne stało się generowanie dużej ilości zapytań do serwerów DNS rekursywnych ISP (AFAIK też ostatecznie rodzaj DDoSu). Na tyle dużej, że niektórzy operatorzy mieli/mają problemy z obsłużeniem żądań pochodzących od swoich klientów na swoich serwerach cache’ujących.
Z różnych pokątnych źródeł (Facebook, IRC) wiem, że pierwszego dnia, gdy się to zaczęło, były problemy z dostępem do Internetu w sieciach należących do Inei i Multimedii. Nie znam przyczyny, ale biorąc pod uwagę, że jeszcze jednemu providerowi „kończyły się” maszyny obsługujące rekursywne DNS i że w przypadku Multimedii pomagała zmiana w systemie na np. serwery DNS Google, przypuszczam, że chodzi właśnie o niewydolność serwerów DNS dostarczanych użytkownikom tych sieci przez ISP.
Rozwiązanie jest dość proste – wystarczy uruchomić swój serwer DNS rekursywny lub forwarder na desktopie czy routerze w swojej sieci, by sieć zaczęła działać lepiej i być mniej zależna (lub nawet niezależna) od DNSów naszego ISP. Ja na swoich desktopach (oczywiście Linux) od dłuższego czasu mam uruchomionego unbound (pokłosie benchmarków DNS) – jest lekki i bezproblemowy. W obecnej sytuacji mamy podwójną korzyść z własnego cache: po pierwsze, jak zwykle odpowiedzi udzielane będą nieco szybciej[1], po drugie, uniezależniamy się od serwerów naszego ISP, który w związku z niewesołą sytuacją w sieci może mieć problemy z działaniem w ogóle.
Z kolei w przypadku sieci lokalnych i routerów sprzętowych działających pod kontrolą OpenWrt lub podobnego systemu warto zwrócić uwagę na mały i zgrabny dnsmasq, którego konfigurację opisywałem kiedyś dość dokładnie.
Niezależnie od wyboru, koniecznie pamiętajmy o zabezpieczeniu czyli poprawnej konfiguracji naszego serwera DNS. Obsługujmy zapytania rekursywne tylko z naszej zaufanej sieci (np. LAN). W przeciwnym razie nasz serwer może zostać wykorzystany do DDoS poprzez DNS amplification. Ograniczać można na wiele sposobów w zależności od użytego serwera i możliwości: firewall, ograniczenie nasłuchiwania do konkretnego interfejsu lub definicje obsługiwanych prefiksów w konfiguracji samego serwera.
[1] Nie zawsze jest to prawdą, liczy się nie tylko opóźnienie do serwera, ale także zawartość jego cache czy wydajność sprzętu, na którym działa. Pisałem kiedyś szerzej o wyborze serwera DNS.
