Pomysł MI na minimalną prędkość Internetu.

Pomysł

Niedawno Ministerstwo Infrastruktury wpadło na pomysł kolejnej regulacji. W skrócie, tym razem sprowadza się to do: jeśli komuś Internet działa, ale z prędkością niższą niż 90% maksymalnej określonej w ofercie, przez 12h lub dłużej w skali miesiąca, to ten ktoś nie płaci rachunku za Internet za dany miesiąc. Interesujące, prawda? Pomysł jest tak skandalicznie zły, że nie mogę go zmilczeć. No to po kolei (bardziej ze strony ISP, bo jest mi jednak bliższa, choć i klientem jestem):

Problem istnieje

Nie ma co ukrywać, że biznes w dostarczaniu Internetu klientom indywidualnym opiera się na kupnie większej ilości pasma i skorzystania z tego, że nie wszyscy korzystają jednocześnie (czyli tzw. overbooking lub overselling). Jednak żaden normalny ISP nie oferuje z premedytacją prędkości takich, których w normalnych warunkach nie jest w stanie zapewnić. Chyba, że na danym obszarze nie ma konkurencji… Co innego operatorzy komórkowi (kto osiąga reklamowane 7,2Mbps)? U nich nawet rozmowy telefoniczne są overbookowane. Wystarczy spróbować zadzwonić w Sylwestra, by się o tym przekonać…

Jasne, trzeba klientów chronić przed nieuczciwymi praktykami typu: na łączu 10 Mbps jest 30 klientów po 10 Mbps. Czy też nawet 3 klientów z abonamentem 10 Mbps. Ale 30 z abonamentem 1 Mbps? Co miałoby źle działać (i jak często)? Ale czy na pewno w ten sposób? Zgadzam się, że klient powinien być zwolniony z „lojalki”, powinien posiadać możliwość rozwiązania umowy lub otrzymać rekompensatę, jeśli problem z prędkością występuje, ale nie na takich zasadach, jak proponowane.

Źródła niskiej prędkości

Dostęp do Internetu składa się z następujących składników:

  • Infrastruktura po stronie klienta. Komputer, router, modem, połączenia między sprzętami (potencjalnie źle skonfigurowane wifi, poniszczone kable).
  • Infrastruktura po stronie dostawcy: kable, światłowody, radia, switche, routery, modemy (potencjalnie poniszczone kable, zakłócone radia, błędy konfiguracji).
  • Infrastruktura po stronie pośredników – zasadniczo podobna jak u dostawcy – w końcu dostawca jest dla nich klientem. Osobno, bo ISP nie ma wpływu na jej funkcjonowanie (poza wyborem operator X lub Y).
  • Infrastruktura po stronie dostawcy treści – routery, switche, serwery, aplikacje. Dodatkowo możliwość nakładania limitów różnej maści (choćby ograniczanie prędkości per połączenie czy per IP; wiele różnych błędów możliwych).

Problem jest z jednoznacznym pomiarem (samym pomiarem! bo co to tak naprawdę jest prędkość Internetu?), problem jest też z jednoznacznym określeniem źródła problemu (często jest to właśnie sprzęt w domu klienta). Wszystkie elementy każdej powyższej infrastruktury (klient, ISP, operatorzy pośredni, dostawca contentu) mają realny i znaczący wpływ na ostateczny wynik. Dlaczego każe się ISP dostarczającemu usługę klientowi indywidualnemu odpowiadać za infrastrukturę w domu klienta, u dostawców pośredniczących i u dostawcy treści? I czemu karze się go za błędy nie leżące po jego stronie? Bo do tego się ten projekt sprowadza.

Wartości

Sama wartość 90% prędkości jest wartością wysoką. Skrajnie wysoką. Rozumiałbym 1% czy też nawet w porywach 10%, ale nie 90%… Podobnie 12h – jest to wyśrubowane wymaganie. 1,6% czasu. Nawet przy łączach operatorskich i całkowitej awarii (zupełny brak działania łącza, chociaż często znacznie niewystarczająca prędkość jest traktowana jako awaria) przez taki okres czasu, niekoniecznie jest upust 100%. Przy wprowadzeniu zapisów proponowanym kształcie może okazać się, że państwo będzie narzucało operatorom świadczenie usługi z parametrami wyższymi, niż sami mają szansę ją zakupić. Jasne, ISP może (i większość to robi) korzystać z więcej niż jednego operatora, by niwelować skutki awarii. Tylko, że to kosztuje. I w sumie Kowalski- jeśli mu bardzo zależy – może sobie kupić redundantne łącze, którego będzie używał w czasie awarii (no dobrze, kto ma 2 niezależne łącza w domu? ja nie, jeśli nie licząc drogiego i wolnego dostępu przez komórkę…).

Pamiętać też trzeba o tym, ilu ludzi potrzebnych jest do obsługi łącz operatorskich, żeby zmieścić się w SLA i przywrócić usługę w pojedyncze godziny. Mówimy o pracy 24/7, dyżurach itd. stosunkowo dużej ilości ludzi w przeliczeniu na ilość łącz/urządzeń. Ilu „techników” byłoby potrzebnych, żeby dotrzeć do Kowalskiego do domu w przypadku (realnego) problemu w ciągu pojedynczych godzin? Jak wpłynęłoby to na cenę usługi? Ktoś w ministerstwie ma pojęcie, ile kosztuje megabit na warunkach operatorskich?

Niezależnie od proponowanej wartości (czy będzie to 1, czy 10, czy 90%) pozostają kwestie problemu technicznego wykonania rzetelnego pomiaru (zwł. określenia do czego mierzyć) oraz kwestie prawne, do których dojdę.

Technologia

Wygląda, że Ministerstwo Infrastruktury wykazało się też sporą nieznajomością technologii, którą się nadzoruje. Proponuję przedstawicielom wybrać się na prezentację dowolnego profesjonalnego (operatorskiego) sprzętu radiowego posłuchać, jak to działa i co dzieje się z pasmem (i w jakim zakresie) przy pogorszeniu się warunków transmisji. Proponuję też poczytać trochę o mechanizmach QoS, przyjąć do wiadomości istnienie ruchu klasy „best effort” itd. Oraz zapoznać się u operatorów, jakie procentowe wartości pasma ustawiane są jako gwarantowane (i czemu nie jest to 90%), dla jakich klas itd.

W tej chwili proponuje się stawianie całego funkcjonowania sieci (i paru pokrewnych nauk związanych z prognozowaniem i modelowaniem) na głowie. Danie klientowi indywidualnemu gwarancji pasma, na dodatek rzędu 90% kłóci się ze wszelkimi szkołami, skazuje na niebyt technologię radiową i powoduje, że mechanizmy QoS przestają mieć sens, bo i tak trzeba (a na pewno jest taniej) projektować sieć na 100% możliwego ruchu (powiedzcie to telefonistom, pękną ze śmiechu). Operator zamiast z punktu A do punktu B mieć dwa niezależne łącza wysycone po 70% (i w przypadku całkowitej awarii jednego z nich świadczenia usługi z zaniżoną prędkością), będzie miał jedno. Przecież i tak nikt nie zapłaci za czas awarii, więc po co płacić za drugie łącze? Szybsze w jednym przebiegu będzie tańsze.

Kwestie prawne

Moim zdaniem, Ministerstwo Infrastruktury ma chrapkę na totalną kontrolę rynku i chce jej funkcjonowania poza istniejącymi przepisami prawa, bez oglądania się nawet na możliwości techniczne. Pod hasłem ochrony odbiorców z jednej strony chce kontroli nad ISP, ale pod innymi hasłami chce kontroli nad użytkownikami (retencja danych, cenzurowanie stron). Oczywiście nie za swoje pieniądze. A przecież w opisywanym problemie z prędkością wystarczyłoby skorzystać z istniejących ogólnych przepisów i możliwości prawnych typu niezgodność towaru z umową, klauzule niedozwolone itp. Skąd zatem nieobecne w aktualnym prawie „nie podoba mi się, to nie płacę”, wyłączenie sądów i skazywanie ISP na (nie)łaskę użytkowników? Nie lepiej skupić się na egzekwowaniu istniejących zapisów prawnych i kontroli stanu faktycznego? Pewnie nie, bo wymagałoby to pracy urzędników…

PS. UKE chce w maju debaty na ten temat. Patrz Message-ID: fed39d94-4325-403b-a6c7-81aa770f4b6f@u3g2000vbe.googlegroups.com W URL jest (i będzie), że pomysł jest UKE, nie MI, co nie jest prawdą – nie we wszystkich miejscach poprawiłem od razu i… zostało.

Egipt.

Nie będę pisał o (dramatycznej) sytuacji politycznej Egiptu (celowo mirror, źródło oryginalne działa, ale…), skupię się tylko na aspekcie technicznym i przekazywaniu informacji. Po pierwsze, jak wiadomo, został odcięty cały dostęp Egiptu do Internetu. Z tego co wiadomo, na poziomie sesji BGP, bez wpływu na linie tranzytowe. Wygaszanie wygląda na zaplanowane, z upewnianiem się co do braku wpływu na zagranicznych operatorów. Wygląda, że dążą do tego, aby ukryć to, co dzieje się wewnątrz kraju, bez dawania powodów krajom zewnętrznym do angażowania się.

Dodatkowo, wyłączone zostały najpierw SMSy, a potem sieci komórkowe. W takiej sytuacji wszelkie tunelowania są bezużyteczne. Odcięcie na poziomie BGP oznacza, że TOR nic nie pomoże. Przez chwilę, nie znając dokładnie sytuacji, liczyłem, że wewnętrznie Internet działa z jakimś proxy dla zapytań DNS, co umożliwiłoby tunelowanie w zapytaniach DNS, ale nie.

Okazało się, że z działających rzeczy zostały tylko stare technologie: modemy dial-up (linie analogowe i wyjścia za granicę nie zostały odcięte, przynajmniej nie wszystkie) i ham radio. Pojawiły się oczywiście problemy z retransmisją odebranych sygnałów – poczynając od tego, że ktoś nie bardzo ma możliwość, bo jest w pracy, przez brak sprzętu lub możliwości (internet domowy w USA to jakaś pocięta parodia). Część transmisji była odbieranych alfabetem Morse’a, część głosowo. W przypadku odbieranych Morsem pojawiał się problem dekodowania (mało kto zna, jeszcze mniej zna płynnie). Istnieją automaty do tego, ale płatne i podobno słabo radzące sobie z zaszumionym sygnałem.

Większość ww. rzeczy robią ochotnicy, czasami z pomocą ISP, którzy zapewniają dostęp wdzwaniany. Z kolei TV, które są masowo dostępne, pokazują informacje tendencyjnie, często przeinaczając.

Podsumowując: mimo obecnej techniki (a może właśnie przez nią), szanse na wolne, nieocenzurowane przekazywanie informacji są niewielkie, jeśli rząd zechce coś wyciszyć. Na organizowanie niezależnej łączności jest za późno, gdy jest ona potrzebna – możliwości są niewielkie.

Dnsmasq – DHCP i DNS dla małych i średnich sieci i nie tylko.

DHCP od ISC, którego opis konfiguracji zamieszczono niedawno na jakilinux.org jest świetny, popularny, skalowalny, o bardzo szerokich możliwościach, ale… jest też stosunkowo skomplikowany, szczególnie dla kogoś, kto po prostu chce nadawać adresy w swojej sieci. Nie jest to jednak jedyna implementacja opensource’owego serwera DHCP. Do godnych uwagi rozwiązań należy dnsmasq, czyli prosty i lekki serwer DHCP oraz forwarder DNS (de facto – DNS cache’ujący). Na dodatek obsługujący IPv6 (tylko dla DNS). Klient TFTP gratis. Co prawda tylko read only, ale do bootowania po sieci z użyciem PXE wystarczy, poza tym, to celowy zabieg w założeniu zwiększający bezpieczeństwo.

Co prawda na stronie projektu wspomina się o działaniu dnsmasq nawet na 1000 hostach, ale osobiście odradzam – cache DNS nie jest specjalnie pojemny (limit w kodzie, poza tym, co można skonfigurować) i przy większej ilości zapytań demon nie wyrobi się z odpowiedziami DNS (źródło: doświadczenia własne, kilka lat temu…) i trzeba będzie przeprosić się z czymś standardowym (bind, djbdns itp.). Natomiast dla kilkudziesięciu czy nawet małych kilkuset hostów powinien działać bardzo dobrze, przy minimalnym nakładzie pracy, a dając sporo opcji i możliwości (cache DNS, przygotowanie do IPv6), kosztem minimalnego tylko zużycia zasobów.

Główna zaleta dnsmasq to moim zdaniem prostota konfiguracji. Cały konfig, z definicjami zakresu, z jakiego ma przydzielać IP w DHCP, interfejsami, na których ma słuchać i określeniem wielkości cache DNS to… trzy linie. Mimo prostoty, rozwiązanie jest dość elastyczne i pozwala na parę przydatnych w sieci lokalnej tricków.

Wszystkie opcje są bardzo dobrze, z przykładami, opisane w pliku konfiguracyjnym /etc/dnsmasq.conf (Debian), do którego lektury, podobnie jak do man dnsmasq oczywiście odsyłam, poniżej przegląd kilku niezbędnych, podstawowych opcji i dodatkowo kilka najciekawszych.

Nieśmiertelna instalacja:

apt-get install dnsmasq 

Interfejs (inny, niż loopback, na którym słucha domyślnie), na którym demon ma słuchać zapytań DHCP i DNS:

interface=eth0

Oczywiście można zdefiniować więcej niż jeden, wystarczy dodać kolejne, analogiczne linie.

Zakres przyznawanych IP z DHCP, maska, czas dzierżawy:

dhcp-range=192.168.0.50,192.168.0.150,255.255.255.0,1h

Ustawienie rozmiaru cache DNS:

cache-size=150

To ustawienie (domyślne) raczej dla małej sieci, ale dzięki temu użytkownicy będą mieli kilka-kilkadziesiąt ms mniej na każdym zapytaniu DNS. I tak naprawdę te trzy linie w konfigu to wszystko, co jest potrzebne, by po prostu działało przydzielanie IP z DHCP na wskazanym interfejsie oraz cache DNS, czyli to, czego będzie potrzebować 99% korzystających. W takiej – domyślnej – konfiguracji zapytania kierowane są do serwerów DNS określonych w /etc/resolv.conf (można to zmienić).

Pora na parę troszeczkę bardziej zaawansowanych, ale przydatnych opcji (czyli nadchodzi przepisywanie manuala ;-)). Wyłączenie nasłuchu DHCP na wskazanym interfejsie (DNS nadal działa):

 no-dhcp-interface=eth1 

Oczywiście wcześniej musiałaby istnieć linia interface=eth1, żeby zadziałało.

Popularne bindowanie, czyli przypisanie IP do MAC (dany MAC zawsze otrzyma dany adres IP):

dhcp-host=11:22:33:44:55:66,192.168.0.60

Wykluczenie hosta o danym MAC z DHCP (nigdy nie otrzyma dzierżawy):

dhcp-host=11:22:33:44:55:66,ignore

Inna przydatna funkcja to umożliwienie manipulowania odpowiedziami uzyskiwanymi z serwerów DNS. Przykładowo, jeśli chcemy, by wszystkie zapytania o daną domenę były resolvowane na adres lokalny:

address=/doubleclick.net/127.0.0.1

Oczywiście linii może być więcej, czyli de facto można zrobić mały, lokalny DNS blackholing. Odpowiadać można zarówno adresami IPv4, jak i IPv6. Powyżej rozwiązanie dla reklam, ale równie dobrze można tym sposobem popsuć trochę szyki malware’owi, albo dać znać użyszkodnikom, że admin czuwa i NK w trakcie pracy to niekoniecznie dobry pomysł…

W przypadku IPv4 można też „naprawiać” odpowiedzi otrzymywane z nadrzędnych serwerów DNS:

alias=1.2.3.4,5.6.7.8

Dzięki powyższemu odpowiedź 1.2.3.4 zostanie przetłumaczona na 5.6.7.8.

Działa także dla całych zakresów:

alias=1.2.3.0,5.6.7.0,255.255.255.0

Powyższe powoduje, że każdy adres 1.2.3.x jest mapowany do 5.6.7.x

Teraz bonus dla wytrwałych czytelników, czyli opcja zwiększająca bezpieczeństwo, której nie ma w przykładowym konfigu (jest w manie, daje się dodać do konfiga).

stop-dns-rebind 

Chodzi o blokadę (i logowanie) odpowiedzi z nadrzędnych DNSów, które są adresami prywatnymi (stosowane do ataków na sieci lokalne, np. do zmiany konfiguracji routerów). Warto jednak doczytać o pozostałych opcjach typu rebind w manualu, żeby np. nie zepsuć DNS blackholingu na upstreamowych DNS…

Podstawowe opcje związane z TFTP

enable-tftp

powoduje włączenie TFTP. Można podać interfejs, na którym ma słuchać TFTP

enable-tftp=eth0

Można też ustawić różne katalogi TFTP obsługiwane na różnych interfejsach. W tym celu należy użyć

tftp-root=/katalog,eth0
tftp-root=/katalog2,eth1

Ostatnia przydatna opcja to

log-queries

które spowoduje logowanie zapytań DNS do pliku. Przydatne np. przy debugu, statystyce odpytywanych domen i przy permanentnej inwigilacji.

I tak naprawdę to koniec popularniejszych opcji (choć opcji jest dużo więcej). Moim zdaniem tyle wystarczy, by zachęcić do przyjrzenia się temu rozwiązaniu na mniejszych sprzętach i/lub sieciach. W wielu przypadkach nie ma sensu stosowania „dużych” rozwiązań typu dhcpd od ISC czy „pełny” serwer cache’ujący DNS.

Z innych, bardziej systemowych zastosowań dnsmasq – może być przydatny dla środowisk chroot z nieskonfigurowanym /etc/resolv.conf. Jeśli w /etc/resolv.conf nie ma żadnego działającego nameserwera, to odpytywany jest loopback. Dnsmasq domyślnie słucha na loopbacku, więc zapewni działające DNSy systemom w chrootach. Źródło: Simple DNS in chroots.

Jeszcze inną – ciekawą z punktu widzenia sysadminów – właściwością dnsmasq jest fakt, że domyślnie zapytania DNS kierowane są jednocześnie do wszystkich serwerów DNS. Bez żadnego, najmniejszego opóźnienia (czego AFAIK nie da się uzyskać przy korzystaniu wyłącznie z /etc/resolv.conf). Dla tych zastosowań, dla których działanie DNS jest krytyczne i nawet 1 sekunda w odpytaniach jest niedopuszczalna, dnsmasq być sposobem na zrównoleglenie odpytań serwerów DNS.

Na koniec odpowiedź na pytanie, jak sprawdzić, czy dnsmasq w ogóle działa. Należy wydać polecenie kill -USR1 `pidof dnsmasq`, następnie można sprawdzić w syslogu, co się pojawiło – grep dnsmasq /var/log/syslog. Powinny tam się znaleźć linie w stylu (nie ma hitów, bo niski uptime):

wielkość pamięci podręcznej: 2000; 0 z 212 miejsc aktualnych wpisów użyto ponownie.
171 zapytań przesłanych dalej, 467 odpowiedzi udzielonych samodzielnie

UPDATE: Dodane info i przykłady dla TFTP.

UPDATE: Dodany przykład jak uzyskać statystyki wykorzystania pamięci cache.

Licencja wpisu: CC BY-NC-SA (wyjątkowo, specjalnie dla jakilinux.org z okazji dyskusji nt. wpisu o DHCP od ISC). W związku ze zmianą licencji globalnie, w dodatku na bardziej liberalną, zapis ten nie ma już sensu.