Plnog 13

Dziś wróciłem z trzynastej edycji PLNOG. Znacznie lepsze wrażenia, niż po edycji 11. Krótko i subiektywnie o wykładach, na których byłem.

Peering vs Tranzyt prowadzony przez Grzegorza Janoszkę z Booking.com. Zaskoczenia nie było; w skrócie: peering oznacza mniejsze opóźnienia, szybsze transfery i mniejsze odchylenia czasu transferu. Czyli – patrząc z punktu widzenia lepiej róbmy sieć/usługę – warto. Niestety, podobno nie przełożyło się to w żaden sposób na wyniki sprzedaży. Duży szacunek za kulturę pomiarów i weryfikację tez w praktyce, mimo trudnych warunków pomiaru (każdy okres jest inny, wzrost ruchu w czasie, zmienne środowisko).

James Kretchmar z Akamai mówił o obsłudze największych wydarzeń w Internecie. Czyli np. transmisje video z MŚ w piłce nożnej. Bez wielkich zaskoczeń, z grubsza tak to sobie wyobrażałem. Ciekawe wyzwania i mechanizmy przy tego typu skali. Największe wrażenie zrobiła właśnie skala i poziom poukładania.

O systemie ochrony przed atakami DDOS Wanguard mówił Piotr Okupski. Wykład ciekawy, praktyczny, przekonujący. Sporo namiarów i ciekawostek nt. wpływu optymalizacji systemu Linux i wyboru kart sieciowych na wydajność. Ogólnie sporo o wydajności, zwł. w kontekście przetwarzania informacji o ruchu sieciowym w większej skali live. Zdecydowanie będę musiał zgłębić temat. W tej chwili mam to rozwiązane nieco inaczej (i też działa i wystarcza), ale warto znać alternatywy.

Czy bezpłatne WiFi może być opłacalne? Chyba najbardziej marketingowy wykład, na jaki trafiłem. Paradoksalnie, cieszę się, że byłem, choć ze względu na ochronę prywatności. Z punktu widzenia użytkownika końcowego: nie ma darmowych obiadów. Zalogujesz się do darmowego WiFi przy pomocy konta FB/maila/numeru telefonów, to spodziewaj się reklam na wallu, spamu, SMSów. Darmowe WiFi w galerii[1]? Pomiar, gdzie chodzisz (dokładność do kilku m), ukierunkowane reklamy przy przejściu obok danego sklepu, na wallu itd. I wszechobecne parcie w kierunku big data. Trochę ciary, mocne skojarzenia z Rok 1984 i Wielkim Bratem.

O narzędziach open source w służbie ISP mówili ludzie z FiberRing. Wyniosłem głównie da się połączone z pewne rzeczy warto rozwijać samemu (bo nie ma alternatyw ;-)) i parę nazw narzędzi, którym chcę się bardziej przyjrzeć.

Mechanizmy ochrony anty-DDoS w Telekomunikacji Polskiej/Orange – taki był tytuł wykładu Andrzeja Karpińskiego. Fajny, poukładany, przemyślany wykład w formie, która bardzo mi się podobała, bo łączyła teorię z praktyką. Czyli z jednej strony co należy robić, a z drugiej jak my to robimy. Myślę, że dobry instruktaż, albo przynajmniej przypomnienie. Mam dość niewesołe przemyślenia w temacie security, niestety. Mianowicie: dużym jest łatwiej, a bezpieczeństwo coraz mniej jest sprawą community sieciowego, a coraz bardziej produktem. Dużą zmianę jakościową mogłaby przynieść dopiero zmiana mentalności end userów, ale na to się nie zanosi. Nawiasem, nie zdziwiłbym się, gdyby wykład okazał się też owocny handlowo (bo o produktach TP/Orange w tym zakresie też było).

Pierwszy dzień konferencji zakończyłem spotkaniem SP Security Community Working Group. Ustalenia są w skrócie takie, że nadal to będzie działać, ma być bardziej otwarte na nowych ludzi i bardziej lokalne. I chyba dobrze, bo IMO do tej pory formuła nie do końca się sprawdzała.

Dzień drugi zaczął Artur Pająk z Huawei wykładem o iSCSI i FCoE. Dobry przegląd technologii. FCoE wygląda jakby lepie w dłuższej perspektywie, ale obecnie barierą może być brak „wspólnego języka” między vendorami.

Mateusz Viste z Border 6 mówił o optymalizacji BGP w czasie rzeczywistym. Dobrze poprowadzony wykład typu co i jak można zrobić. Jeśli się trochę pomyśli i porzeźbi, oczywiście. I napisze trochę swojego kodu[2]. A firma dla tych, którym się nie chce/nie potrafią daje gotowca. Wyniki ciekawe, pewnie parę lat temu byłbym poważnie zainteresowany produktem. Teraz trochę się zmieniła pozycja – ceny hurtowego dostępu do internetu spadły, pojawiły się punkty wymiany ruchu, które też znacznie pomagają (patrz wykład z pierwszego akapitu), a dodatkowo capacity daje pewną odporność na DDoSy (przynajmniej teoretycznie). Może po prostu nie jestem odbiorcą docelowym w tym momencie, tzn. nie mam takich potrzeb.

Ostatni wykład na którym byłem prowadził Adam Obszyński z Infoblox. Zupełnie niemarketingowy wykład o DNSSEC, czy warto, czemu warto, czemu nie warto i co to daje. Ogólnie IMO trochę poprawia bezpieczeństwo, zwł. w przypadku przejęcia ruchu (MITM), ale problemu nie rozwiązuje, w szczególności nie rozwiązuje go dla użytkownika końcowego. Bo ten nadal jest narażony na podmianę adresów serwerów DNS na swoim komputerze/routerze (i wtedy DNSSEC nic nie daje), ruch do DNS nadal jest widoczny (DNSSEC to podpisywanie, nie szyfrowanie) i ogólnie nadal musi ufać swojemu ISP[3]. Widać, że nie do końca się standard przyjął (w Polsce jest naprawdę słabo), wiele ostatnich artykułów jest z okolic 2010-2012, ale przyznam, że ja zostałem przekonany do włączenia (w tym: dla moich użytkowników, aktualnie testuję na sobie). Będzie odrobinę bezpieczniej, a włączenie jest trywialne.

Bo że z bezpieczeństwem DNS nie jest za dobrze, to wiadomo – niedawno dość modny (z braku lepszego określenia zostawię to słowo) stał się DNSCrypt, który robi zupełnie co innego, ale… ma inne wady, a jego uruchomienie to na ten moment porażająca rzeźba, niestety.

W każdym razie zupełnie prywatnie wykład inspirujący i planuję wkrótce wpis(y?) o DNSSEC.

[1] Obawiam się, że do samego pomiaru położenia wystarczy włączone WiFi w telefonie, nie trzeba podłączać się do sieci… A potem, kiedyś, jak już się podłączy na podstawie MAC karty sparuje się urządzenie z użytkownikiem i dołoży parę puzzli do układanki.

[2] Tak, kolejny wykład o tym, że DIY w sieciach ma rację bytu.

[3] I swojemu ISP od DNS też, jeśli przypadkiem nie jest to ten sam byt.

Dostępne wszystkie kody źródłowe dla Banana Pi

Developerzy postąpili zgodnie z zapowiedziami i udostępnili wszystkie kody źródłowe do Banana Pi. Są pierwsze doniesienia na forum o sukcesach z akceleracją GPU oraz potwierdzenia, że karta sieciowa działa na 1 Gbps na otwartym sterowniku. Nieoficjalnie słyszałem o prędkościach 520 Mbits/sec i 697 Mbits/sec (iperf; zależy czy serwer czy klient na bpi). Jak widać więcej, niż maksymalna przepływność USB. Czyli Raspberry Pi ma się coraz bardziej czego obawiać.

Biorę się do klonowania repozytoriów. 😉

Własna namiastka dyndns

Po ostatniej akcji Microsoftu z przejęciem i zablokowaniem domen należących do No-IP miałem przez moment umiarkowany problem z dostępem do jednej z moich maszyn, bo nie znałem IP. Nic krytycznego i szybko rozwiązałem, ale stwierdziłem, że warto by się zabezpieczyć na przyszłość. Początkowo chciałem uruchomić po prostu innego dostawcę dyndns, z inną domeną, co dałoby całkiem niezłą – jak mi się wydaje – redundancję w tym względzie, ale prowizorycznie uruchomiłem coś innego, własnego i znacznie prostszego. W komentarzu do poprzedniego wpisu padło pytanie co dokładnie zrobiłem, więc opisuję.

Tak się składa, że mam serwer dedykowany ze stałym IP (nie jest konieczne zamiast tego można skorzystać z domeny), na którym stoi serwer WWW (lighttpd). Na wszystkich maszynkach potrzebujących dyndns mam dostęp do crona (zresztą, korzystałem z crona już przy zwykłym koncie dyndns, patrz update wpisu). Rozwiązanie jest proste: klient wywołuje okresowo unikatowy URL na moim serwerze, serwer okresowo parsuje log w poszukiwaniu tego unikatowego ciągu znaków i zapisuje IP z którego nastąpiło odwołanie w określonym pliku.

Poniżej wklejki ze wszystkimi onelinerami (gotowiec dla lighttpd, w przypadku innego serwera WWW trzeba dostosować):

# po stronie klienta*/5 * * * * /usr/bin/wget -4 -q -O /dev/null http://mojadomena.com/losowyciagznakow4346456543324645 > /dev/null
 # po stronie serwera*/5 * * * * /usr/bin/awk '/losowyciagznakow4346456543324645/ {ip=$1} END {print ip}' /var/log/lighttpd/access.log > /var/www/dyndns_host1.txt
 # pobranie IPwget -O - http://mojadomena.com/dyndns_host1.txt

Po namyśle, rozwiązanie nawet lepsze niż drugi dostawca dyndns. Mniej kont, prostsza konfiguracja, mając stałe IP na upartego można całkowicie uniezależnić się od DNSów, jeśli ktoś odczuwa potrzebę.

Oczywiście nie od razu tak to wyglądało, w szczególności po stronie serwera był grep, awk, tail w użyciu. Ale skoro da się wszystko załatwić awk (a nie tylko wyświetlanie określonej kolumny, chyba najczęstsze zastosowanie awk…), to czemu nie? Tu polecam zbiór przydatnych onelinerów w awk.

UPDATE: IPv6 się popularyzuje. Okazało się, że mój skrypt nie działa poprawnie, bo łączenie między maszynami następuje po IPv6. Dodany parametr -4 do wget w celu naprawy tego problemu.