Pomiary Internetu – RIPE Atlas probe

Jakiś czas temu pisałem o pomyśle MI na minimalną prędkość Internetu. Niedawno sonda z projektu RIPE Atlas dotarła i została uruchomiona. Wydaje mi się, że to dobry pomysł, żeby wrócić do tematu, bo jest parę analogii.

Sama sonda to prosty komputer, wielkości mniej więcej pudełka zapałek (określenie „beczułka” do łączenia kabli ethernetowych jest bliższe, ale pewnie większość ludzi nie będzie wiedziała o co chodzi), zasilany przez USB, z gniazdem na wtyczkę sieciową. Otrzymać go (za darmo, zarówno sprzęt – który pozostaje własnością RIPE, jak i wysyłka) może teoretycznie każdy. Ale póki co chyba głównie do ISP wysyłają. I tego szpiega trzeba umieścić w sieci, z dostępem do Internetu, żeby robił pomiary.

W zamian dostajemy dostęp do danych (wykresy) zebranych przez naszą sondę. Co może pomóc w monitorowaniu sieci (nic, czego nie dałoby się zrobić samodzielnie, ale jest ładny gotowiec). W chwili obecnej mierzone są głównie opóźnienia od „ważniejszych miejsc” w Internecie. Poza tym, właściciel może oznaczyć sondę jako publiczną i wtedy każdy, kto założy konto, będzie mógł oglądać jej wykresy. Publicznych sond całkiem sporo, jeśli ktoś ma nadmiar czasu to może sobie pooglądać.

Analogii z pomysłem MI jest sporo – są pomiary, jest „niezależny” sprzęt. Cudzysłów, bo wiadomo, że wyniki z centralnego punktu sieci nijak muszą się mieć do tego, co dostanie Kowalski, kreatywny QoS też jest możliwy… Ładnie widać, jakie są koszta (kupno i wysłanie sond, system do zbierania danych), widać, jakie są efekty („obiektywny” pomiar). Nie jestem przekonany, czy Kowalski będzie w stanie wyciągnąć jakiekolwiek sensowne wnioski z danych prezentowanych przez sondę.

Faktem jest, że w chwili obecnej sonda mierzy głównie dostępność sondy i opóźnienia do określonych hostów w sieci, nie przepływności. Docelowo będzie prawdopodobnie mierzyć jedno i drugie, w panelu jest opcja – obecnie nieużywana – pozwalająca na określenie przydzielonego pasma. Ale chodzi o sensowność interpretacji wyników – dla kogo istotne są opóźnienia do USA czy Japonii? Jasne, można zebrać wyniki, jakoś uśrednić i zrobić ranking, ale… Do obiektywnego pomiaru jakości sieci u Kowalskiego, który chciało zrobić MI nadal bardzo daleko.

Obowiązki przedsiębiorcy telekomunikacyjnego, czyli kolejne genialne pomysły rządzących.

Po projekcie rozporządzenia w sprawie retencji danych, wejściu tego rozporządzenia w życie oraz pomyśle na minimalną prędkość Internetu, przyszła kolej na kolejny genialny pomysł pomysł rządzących. Chodzi o projekt rozporządzenia dotyczącego wymagań i sposobu zapewnienia przez przedsiębiorcę telekomunikacyjnego warunków dostępu i utrwalania. Znaczy – normalnie mówiąc – podsłuchu i rejestracji rozmów telefonicznych i transmisji internetowych.

Czemu projekt jest fatalny? Po pierwsze, czasy reakcji. W wariancie najbardziej ręcznym są 2h w dzień od 6 do 22 i 4h od 22 do 6. W wariancie najbardziej automatycznym (odpowiednio 15 i 30 minut w wariancie najbardziej automatycznym). Od czasu zgłoszenia zapotrzebowania do umożliwienia podsłuchu/nagrywania. W piątek, świątek, niedzielę. Proponowałbym, żeby miłościwie nam panujący autorzy projektu zapoznali się z czasami reakcji obowiązującymi w branży. I może z prawem pracy jeszcze. I policzyli, ile potrzeba osób, by obsadzić w ten sposób 24/7 jeden „slot”.

Po drugie, ilości ludzi. W najgorszym, czyli najmniej zautomatyzowanym wariancie jest to 1 pracownik na 1500 numerów telefonicznych oraz adresów IP. Przydzielonych ISP. Czyli taki dostawca sieci, który ma nieszczęście mieć IPv6 (minimalnie /48, mniej się nie przydziela) ma – mówiąc kolokwialnie, ale inaczej się nie da – przejebane. Bo klasa /48 to 2 do potęgi 80, czyli 1208925819614629174706176 (1,209 razy 10 do potęgi 24, będzie czytelniej). Nawet ten z pełną automatyką i tylko jednym pracownikiem na 45000 adresów IP będzie musiał mieć 2,68 razy 10^19 pracowników.

Nie wiem, czy wymagana na maturze powinna być bardziej matematyka, czy geografia, bo nie wiem czy rządzący nie orientują się, ilu jest ludzi na świecie, czy po prostu nie policzyli tego. W każdym razie ten wariant likwiduje bezrobocie na Ziemi na parę wieków. Obawiam się jednak, że mają świadomość, co czynią, bo w uzasadnieniu (wpływ regulacji na rynek pracy) piszą o korzystnym wpływie na rynek pracy…

Nawet, jeśli zmienią powyższe z przydzielonych ISP na przydzielone klientom końcowym – niewiele to wnosi. Przy IPv6 klient końcowy dostaje /64 czyli 1,8 razy 10^19 adresów IP… Zresztą, nie potrzeba IPv6. Nawet nędzne 1,6 do 2,5 mln klientów Neostrady w TPSA (znalezione przy okazji tego wpisu, pewnie się zmieniło) to – najbardziej optymistycznie – minimalnie 35 do 55 osób. W samej tylko TPSA, do samej tylko Neostrady. Licząc po klientach, nie IP przydzielonych ISP, czyli bardzo, ale to bardzo skromnie (na to w projekcie nie wpadli jeszcze)…

Najbardziej martwi mnie to, że prawo jest z założenia martwe, niespecjalnie potrzebne (chyba, że u nietypowych ISP pracowałem – pytanie do adminów sieci – jak często u was robią zrzuty/zapisy transmisji, licząc na 1k abonentorok?), daje spore pole do nadużyć (konkurs bez nagród: kto może zlecić w Polsce założenie podsłuchu tego typu?) i będzie służyło zapewne głównie ochronie rządzących, czego przykład mieliśmy podczas użycia ABW do interwencji w sprawie z strony ośmieszającej(?) prezydenta. Aha, gdyby ktoś miał wątpliwości, to Kowalski za góra 5 euro miesięcznie obejdzie to wszystko przy pomocy VPN i silnej kryptografii, podobnie jak przy pomocy ustawy antyhazardowej.

Inne ciekawostki z dokumentu: przedmiot projektowanego aktu prawnego nie jest objęty prawem Unii Europejskiej. Faktycznie, bardziej pachnie Białorusią.

PS Czuję, że na pl.internet.polip znów będzie wrzało…

Źródło, czyli projekt dokumentu.

Quagga, czyli czemu czasem warto zerwać z kompatybilnością wsteczną.

Tak się złożyło, że w użyciu jest sobie Quagga. Złożyło się też tak, że pobierane z niej są pewne dane przy pomocy polecenia vtysh. W postaci:

vtysh -c "show ip bgp neighbors  advertised-routes"

Następnie wynik polecenia jest parsowany skryptem. Generalnie chodzi o pobranie sieci w notacji CIDR. I wszystko byłoby fajnie, ale Quagga w ramach kompatybilności wstecznej (it’s not a bug, it’s a feature!) zwraca czasem samo IP. Niejednoznacznie, przez co z prostego w założeniu skryptu powinien zrobić się automat domyślający się, czy chodzi o /8, /16 czy /24.

Szukałem informacji czy można coś z tym zrobić na kanałach IRCowych, dostałem dane, że nie ma opcji, by zmienić takie zachowanie, tzn. aby Quagga zwracała jednoznacznie (np. uruchomienie z jakąś opcją). Za to było zainteresowanie ew. znalezionym rozwiązaniem. Nie znalazłem. Wygląda, że po prostu się nie da (tak, wiem, zawsze można pogrzebać w kodzie…).

Nie znalazłem też prostej koncepcji na określanie, o jaką długość prefiksu chodzi w danym przypadku. Akurat w przypadku, w którym używam średnio mi na tym zależy, ale elegancko byłoby móc jednoznacznie określić o jaki prefiks chodzi. Pomysły mile widziane. Przychodzi mi do głowy sprawdzanie, czy dla /8 i /16 nie ma nakładających się sieci z prefiksami określonymi wprost. Wtedy wiadomo, że chodzi o /24.

PS. Wiem, że jest BIRD. Jest rozważany, ale to trochę inny temat.