Gotowanie żaby

Dziś będzie o gotowaniu żaby, czyli jak my, obywatele, oddajemy bezczynnie coraz więcej swojej wolności państwu. Po małym kawałeczku. Wpis jest zainspirowany dyskusją na kanale IRC o tym, jak to my, społeczeństwo bez protestu przyjmujemy to, co wymyśla rząd AKA miłościwie nam panujący.

Poszło o rządową cenzurę stron przy pomocy DNS. O sprawie pisał DI, pisała też Fundacja Panoptykon. Oczywiście, sprawa nikogo nie dotyczy – mało kogo interesuje hazard przez Internet, poza tym, co to za zabezpieczenie przez blokadę w DNS, skoro można zmienić DNS? No i mamy Tora i VPNy, łatwo można obejść ustawę za parę euro miesięcznie, jak pisałem. Zresztą na innych portalach branżowych również są instrukcje dotyczące czy to zmiany serwerów DNS, czy zdobycia łatwego VPNa. Niby nie ma sprawy.

Tyle, że powstało pozwolenie na pewną czynność i pewien mechanizm. Czynność to blokowanie dostępu do stron WWW czyli informacji na rozkaz państwa. Przy pomocy centralnego rejestru. Oczywiście na razie to tylko hazard i tylko nieskuteczna blokada DNS, ale… jaki problem rozszerzyć za jakiś czas indeks stron zakazanych o strony porno? Porno złe! I nikt nie będzie protestował. Albo krytykujące miłościwie nam panującego prezydenta. Albo równie miłościwie nam panujący rząd? Krytyka zła! I nikt nie będzie protestował.

Na razie mechanizm blokady jest nieskuteczny i prosty do obejścia, więc się godzimy na niego. Ale jaki problem za jakiś czas poprawić go? Omijają kontrolowane przez rząd DNSy? Wymuśmy, by ISP – nieodpłatnie rzecz jasna – przekierowywał każdy ruch DNS na nie. Używają Tora? Wiadomo do czego! Zablokujmy Tora! Nikt nie zaprotestuje. Używają dnscrypt i VPNów? Wiadomo do czego! Zablokujmy! Nie da się w DNSach? To nic, doda się obowiązek utrzymywania blokowania po IP. Nawet prostszy w implementacji… Nikt nie zaprotestuje.

Zwrócono w dyskusji uwagę, że przy ACTA były protesty na ulicach i że ten język rządzący rozumieją. Bo czy ten wpis, czy linkowane wyżej artykuły Panoptykonu czy DI, czy opinie Ministerstwa Cyfryzacji spływają po miłościwie nam panujących jak po kaczce. Teraz nie ma żadnych działań.

Nie chodzi o tę jedną ustawę, oczywiście. Przypominam, że powstaje (albo już powstał) ogólnopolski projekt monitorowania ruchu internetowego. Oczywiście znowu w imię walki z przestępczością i terroryzmem. Potem wystarczy dorzucić, że próby obejścia rządowej blokady są przestępstwem, wytypować korzystających z Tora, VPNów itp. i… z głowy. A wiadomo, że służby muszą mieć sukcesy. I że jak się ma młotek, to wszystko wygląda jak gwóźdź…

Inne, podobne: pamiętacie obowiązek rejestracji kart SIM, wprowadzony w imię walki z terroryzmem? Niektórzy zastanawiali się, co z niezarejestrowanymi. Niektórzy nie wierzyli jak pisałem, że po prostu za jakiś czas każą operatorom zablokować wszystkie niezarejestrowane karty. Że prawo nie może działać wstecz, że umowa, że operator się nie zgodzi. Otóż Plus już zmienił regulaminy:

Klienci zawierający umowę o świadczenie usług telekomunikacyjnych od dnia 25 lipca 2016 r. będą zobowiązani do dokonania rejestracji powyższych danych oraz umożliwienia ich weryfikacji z dokumentem potwierdzającym tożsamość przed zawarciem umowy i rozpoczęciem korzystania z usług.

Abonenci Na Kartę, którzy zawarli umowę o świadczenie usług telekomunikacyjnych przed dniem 25 lipca 2016 r. obowiązani są podać powyższe dane i umożliwić ich weryfikację najpóźniej do dnia 1 lutego 2017 r. Zgodnie z ustawą o działaniach antyterrorystycznych niedokonanie rejestracji powyższych danych będzie skutkowało całkowitym zaprzestaniem świadczenia usług z dniem 2 lutego 2017 r.

Nikt nie protestuje, nikogo to nie dotyczy, jaki problem zarejestrować kartę?

Temperatura wody rośnie, żaba nie reaguje…

NLNOG RING – zdiagnozuj sobie sieć

Odwieczny problem administratorów sieci to mogę sprawdzić trasę od siebie do danego hosta, ale jak wygląda w drugą stronę? Próbą rozwiązania tego zagadnienia były looking glass, pozwalające na wykonanie od określonego operatora ping czy traceroute. Czasem potrzeba jednak czegoś więcej – sprawdzenia resolvowania DNS, zbadanie stabilności transferu itp. Ogólnie przydałby się shell.

Projekt NLNOG RING jest odpowiedzią na to zapotrzebowanie. Opiera się na prostej zasadzie wzajemności: udostępniamy maszynę wirtualną (administrowaną przez opiekunów projektu) dla projektu, w zamian otrzymujemy dostęp do pozostałych maszyn projektu, w różnych częściach świata i – co ważniejsze – w wielu różnych ASN.

Wymagania co do maszyny są naprawdę niewielkie – 1 GB RAM, 20 GB dysku, 1 core 64bit procesora, adresy IPv4 oraz IPv6. Musi stać w naszym AS i na naszej adresacji. Myślę, że w tej chwili większość operatorów, nawet niewielkich sieci radiowych jest w stanie sprostać. Pozostałe wymagania stawiane organizacji (usługa jest kierowana do firm) to m.in.: bycie operatorem sieciowym, własne ASN, prefiksy IPv4 i IPv6, zgoda organizacji na uczestnictwo w projekcie.

Możliwe jest zarówno połączenie po SSH do wybranej maszyny, jak i wykonywanie, przy pomocy dostępnych narzędzi, operacji na wszystkich maszynach projektu jednocześnie. Generalnie potrafi bardzo pomóc w diagnostyce.

Projekt działa od wielu lat, ale dziś dowiedziałem się, że nawet w środowisku sieciowym niekoniecznie jest znany, więc uważam, że warto przypomnieć o jego istnieniu. Teoretycznie istnieje ryzyko nadużyć, ale użytkownikami są administratorzy sieci, polityka to zero tolerancji dla nadużyć i nie kojarzę jakichkolwiek problemów związanych z udostępnianiem maszyny. Korzystałem, polecam.

Przyspieszanie łącza internetowego

Wpis, który przeleżał jako szkic ponad rok. I bardziej go już nie skończę, więc publikuję, jak jest. Miały być testy i dokładne konfiguracje, ale z braku czasu będzie czysta teoria. Tak czy inaczej myślę, że przyda się ludziom z wolnymi łączami lub korzystającym z WWW (i nie tylko…), a chcącym zminimalizować ilość przesłanych danych do urządzenia końcowego. Do rzeczy.

Na podstawie doświadczeń z Aero2, czyli łącza zarówno wolnego (niska przepływność) jak i zlagowanego (duże opóźnienia pakietów), postanowiłem popełnić krótki poradnik, jak przyspieszyć działanie sieci na wolnym łączu internetowym. Zwykle zakładam w tym poradniku, że użytkownik korzysta z Linuksa, ale nie zawsze i część sposobów przyda się niezależnie od systemu.

Krok pierwszy – przyspieszanie zapytań DNS

Ważna sprawa, bo serwery DNS odpytywane są coraz częściej. Otwarcie pojedynczej strony internetowej to w dzisiejszych czasach często kilkanaście, a nawet kilkadziesiąt zapytań do serwerów DNS. W przypadku zlagowanego połączenia do każdego zapytania dochodzi opóźnienie łącza. Można sobie pomóc poprzez wykorzystanie lokalnego cache DNS. Z prostych w konfiguracji polecam opisany kiedyś dnsmasq lub lekki i wydajny unbound. Cache DNS działa dla całego systemu, nie tylko dla stron WWW, ale w ich przypadku różnica powinna być najbardziej widoczna. Dodatkowa zaleta to uniezależnienie się od potencjalnych problemów z serwerami DNS naszego dostawcy łącza.

Krok drugi – kompresja danych

Mechanizm kompresji danych na wolnym odcinku nie jest niczym nowym. Od dawna z powodzeniem stosuje go Opera w swojej funkcji turbo. Pierwsza obróbka strony odbywa się na ich serwerach, które dysponują szybkimi łączami. Dodatkowo może się odbywać redukcja zbędnych elementów. Zaletą rozwiązania jest łatwość uruchomienia – wystarczy kliknąć przycisk w Operze. Wadą rozwiązania jest to, że wymaga korzystania z Opery i działa tylko dla stron WWW.

Kompresja danych – DIY

ziproxy

Jeśli mamy dostęp do serwera (może być VPS) z Linuksem, możemy w prosty sposób stworzyć podobne rozwiązanie samodzielnie, korzystają z programu ziproxy. Instalujemy je na serwerze, konfigurujemy, jak bardzo mają być redukowane grafiki (60-70% wygląda znośnie), ustawiamy adres IP i port serwera jako proxy w przeglądarce i.. tyle. Od tej pory przez wolne łącze przesyłane są zredukowane (stratnie, zatem gorzej wyglądające) obrazy. Reszta danych jest przesyłana w postaci skompresowanej.

Zaleta jest taka, że działa z każdą przeglądarką i – dla paranoików – że nasze dane nie błądzą po serwerach Opery.

Wady: działa tylko dla WWW, stopień redukcji obrazów ustala się raz, nie ma możliwości dynamicznej zmiany jakości (np. obejrzenie wybranych obrazów w lepszej jakości).

sshuttle

Jeśli mamy dostęp do serwera z Linuksem i dodatkowo ma on zainstalowanego Pythona, to możemy skorzystać z VPN over SSH, czyli shuttle. Rozwiązanie powstało jako namiastka VPN i miało pierwotnie bardziej zapewniać bezpieczeństwo transmisji (szyfrowanie) w przypadku otwartych hotspotów. Można je jednak skonfigurować tak, aby ruch był kompresowany (wykorzystanie kompresji SSH).

Zaletą jest to, że działa dla całego ruchu (TCP), nie tylko dla WWW. Można określić, do których sieci ruch ma być obsługiwany przez to rozwiązanie.

Wada: działa tylko dla TCP (oraz zapytań DNS), wymaga zainstalowanego Pythona na maszynie pełniącej rolę serwera.

ssh + socks proxy

Jeśli nie chcemy instalować dodatkowego oprogramowania, a mamy dostęp do serwera z Linuksem, możemy w prosty sposób wykorzystać tunelowanie SSH oraz – podobnie jak w poprzednim przypadku – wykorzystać kompresję oferowaną przez SSH. W tym celu ustawiamy socks proxy w przeglądarce na localhost oraz port 9000, oraz uruchamiamy ssh -CND 9000 user@serwer. Od tej pory ruch WWW tunelowany jest przez SSH do serwera. Jeśli zależy nam nie tylko na wydajności, ale i na prywatności, warto sprawdzić ustawienia przeglądarki dotyczące przesyłania zapytań DNS przez proxy.

Zaleta: łatwość uruchomienia (na systemach *nix).

Wady: działa tylko dla ruchu WWW (lub jawnie przetunelowanego z innych aplikacji), wymaga przeglądarki WWW ze wsparciem dla socks proxy (praktycznie każda sensowna ma tę opcję dostępną w ten lub inny sposób).

OpenVPN

Ostatni sposób to wykorzystanie OpenVPN oraz wbudowanej kompresji. Wymaga skonfigurowanego OpenVPN zarówno po stronie klienta jak i serwera.

Zalety: działa dla wszystkich rodzajów ruchu.

Wady: wymaga zainstalowania i skonfigurowania OpenVPN. Dochodzi narzut CPU na szyfrowanie (domyślnie będzie włączone, zwł. u zewnętrznych providerów).

Oczywiście cudów nie ma i ww. sposoby pomogą jedynie dla treści, które przesyłane są jako nieskompresowane i dobrze się kompresują. Nie ma co liczyć, że filmy na YouTube zaczną działać szybciej. Osobiście idę na łatwiznę i korzystam zwykle z ssh i socks proxy.

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.

Dyn.com kończy świadczenie darmowych usług

Dla mnie konto na dyn.com skończyło się wcześniej, dziś ogłosili na blogu, dlaczego zdecydowali się zaprzestać świadczenia darmowych usług w ogóle. Przyznam, że byłem zadowolony w tym wąskim zakresie, w jakim korzystałem, ale dopiero sposobem wyłączenia i rozłożeniem go w czasie mnie ujęli. PRowo jak dla mnie wzorowo: mocno rozłożone w czasie, narastający poziom trudności w utrzymaniu darmowych usług, możliwość łatwego przejścia na wariant płatny, dobra informacja (OK, to w ich interesie). Last but not least: utrzymanie obiecanych wiecznych darmowych kont wczesnym użytkownikom. Naprawdę uważam za ładnie rozegrane.

Pozostało mi życzyć im powodzenia i podziękować, zatem: thank you, dyn.com. 🙂

Własny DNS cache jako lekarstwo na problemy z siecią

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.

Koniec konta w dyndns.com

Usługa dyndns w dyndns.com – czyli chyba najpopularniejszego dyndns w ogóle; pamiętam, że nawet w niektórych routerach w swoim czasie był wbudowany i to w firmware producenta – od dawna zmierzała do tego, by być płatną. A to skończyły się rejestracje nowych darmowych kont, a to wprowadzono wymóg korzystania z kont, a to – ostatecznie – wymóg logowania się przez WWW raz na miesiąc.

Ponieważ aż cały miesiąc na zalogowanie był, to stwierdziłem, że zawsze zdążę. Tym bardziej, że przysyłali powiadomienia parę dni wcześniej. I wystarczyło kliknąć linka. Więc nawet nie ustawiłem crona, który sam by się logował – w końcu link taki wygodny… O koncie płatnym nie myślałem – 15 dolców na rok to trochę dużo jak za „zamień zmienne IP na coś możliwego do zapamiętania”. Jakąś dotację co łaska (np. via Flattr) pewnie bym rzucił, ale tak z góry narzucona opłata – niekoniecznie, tym bardziej, że mogę sobie odpalić własny zastępnik w jakieś 30 minut. No ale nie lubię takich rzeźb i wolę coś, co jest wspierane szerzej i ma już infrastrukturę.

Dziś stwierdziłem, że nie mogę się zalogować. Błąd rozwiązywania nazwy. Hm, bywa, może awaria. Potem coś mnie tknęło. Sprawdziłem maile. Tak jest. 30.10 dostałem przypomnienie. Oczywiście zostało oznaczone jako spam przez providera poczty, w programie pocztowym, a pewnie i podświadomie angielski tytuł sklasyfikowałem jako spam.

W każdym razie nie mam już konta na dyndns.com. W zamian wybrałem no-ip.com. Też zasłużony w temacie serwis, też zdaje się był na routerach SOHO wspierany. I też mocno zmierzający w stronę komercji, ale nie przejmuję się – rejestracja tego typu serwisu plus setup to dosłownie 5 minut. No i w końcu uruchomiłem też dyndns na moim OpenWrt.

Niezbyt łatwo znaleźć przykłady konfiguracji ddclient dla no-ip.com (choć jest trywialna, a protokół noip wbudowany), więc:

cat /etc/ddclient.conf
pid=/var/run/ddclient.pid
protocol=noip
use=if, if=ppp0
login=login
password=haslo
domena.no-ip.biz

Wersja dla Dockstara z PPPoE, publiczny IP na ppp0.

PS Wpisu by nie było, ale ładnie wpisuje się w trend „używałem tego od lat, a teraz zamknęli„.

UPDATE Z tym ddclientt to pochwaliłem za wcześnie. Nie tylko nadal występuje coś, co miało miejsce od dawna, czyli obecność wiszących procesów ddclient, ale – co gorsza – przyrastają w zastraszającym tempie. Load 30 na biednym routerku był dziś za ich przyczyną. Ledwo zdołałem ubić. Sam ddclient okazał się skryptem w Perlu (przychodzi mi na myśl taki rozwinięty smsender.pl), a rozwiązanie jest proste – nie korzystam już z demonizacji, tylko wywołuję co 10 minut z crona. Okazało się, że ma jakiś problem z cache, a konkretnie z odczytem wartości z niego. Rozwiązanie wygląda tak (po wyłączeniu demonizacji w /etc/default/ddclient):

*/10 * * * * /bin/rm /var/cache/ddclient/ddclient.cache; /usr/sbin/ddclient -quiet > /dev/null

Wiem, dirty hack. Ostatnio mam niestety tendencję do tego. Przyznam, że myślałem w pierwszej chwili o cyklicznym killowaniu procesów ddclient.

UPDATE: Wygląda, że albo z tym wyłączaniem usług to ściema, albo coś im nie poszło – dostaję kolejne maile z linkami, których kliknięcie aktywuje konto. Nie sprawdzałem działania, ale wygląda, że mogę dodawać kolejne hosty i normalnie dalej korzystać za free. Raczej ciekawostka, bom już przeniesiony.

Debian, Huawei E3131 od Play i Aero2.

Będzie krótko o tym, jak uruchomić i korzystać z modemu Huawei E3131 od Play na Debianie (unstable). Dokładny opis dotyczący Aero2 z Huawei E3131 jest na DUG, tu najważniejsze rzeczy i parę zmian.

Modem Huawei E3131 od Play

Źródło: http://www.play.pl/telefony/huaweie3131_white/img/gal/big/1_1100x1100.png

Instalacja potrzebnych programów:

wajig install usb-modeswitch wvdial

Ustawienie trybu automatycznego (domyślnie jest tylko Play). Wykonanie na rozłączonym modemie, tylko raz, po kupnie modemu:

echo "AT^SYSCFG=2,0,3FFFFFFF,1,2\r" >/dev/ttyUSB0

Zawartość pliku konfiguracyjnego wvdial.conf:

$ cat /etc/wvdial.conf 
[Dialer aero2]
Modem = /dev/ttyUSB0
Init1 = AT+CGDCONT=1,"IP","darmowy"
Phone = *99#
Stupid mode = yes
Username = "aero"
Password = "aero"
Dial Attempts = 0
Auto DNS = "off"

[Dialer power]
Modem = /dev/ttyUSB0
Init1 = AT+CSQ

Gwoli wyjaśnienia – opcja Auto DNS nie działa, ani wywołana w powyższy sposób, ani jako Auto DNS = 0 – zawsze ustawia serwery DNS w /etc/resolv.conf. Nadpisuję ręcznie przez

echo "nameserver 127.0.0.1" > /etc/resolv.conf

Aby faktycznie wvdial nie ustawiał serwerów DNS oferowanych przez dostawcę, tylko korzystał ze statycznie ustawionych w /etc/resolv.conf, należy, poza powyższymi ustawieniami, w pliku /etc/ppp/peers/wvdial zakomentować opcję usepeerdns. Info z wpisu static DNS with wvdial.

I tu pierwszy trick – lokalny cache DNS powinien znacznie przyspieszyć odczuwalne działanie sieci, zwł. na tak wolnym łączu.

Trick drugi – używam tunelowania SSH z kompresją (ssh -CND 9000 user@host_z_lepszym_łączem)i socks proxy 5 (localhost:9000) w przeglądarce. Na oko, łącząc się do hosta 1/0,25 Mbps jest minimalnie szybciej, niż na gołym Aero2, w przypadku VPS z porządnym łączem jest znacznie szybciej. Warto zwrócić uwagę, by zapytania DNS nie były tunelowane, jeśli korzystamy z lokalnego cache’ującego serwera DNS.

Połączenie z siecią nawiązuję przez wvdial aero2 – w tym przypadku nie zależy mi na automagicznym wznawianiu w tym przypadku.

Drugi wpis, czyli power służy do określania siły sygnału GSM (znowu sprawdzanie siły sygnału GSM opisane jest szerzej na DUG). Wywołanie to wvdial power, otrzymujemy dwie cyfry oddzielone przecinkiem, interesuje nas pierwsza cyfra. 2 km od nadajnika (strona z rozmieszczeniem nadajników GSM poszczególnych operatorów z możliwością pomiaru odległości od nich), w budynku, na parterze, bez żadnej anteny mam 7-10 i wystarcza to do bezproblemowego działania sieci. Ogólnie jestem bardzo zadowolony z Huawei E3131 i jego działania pod Linuksem.

UPDATE: W związku z tym, że od 1 kwietnia 2014 do nawiązania połączenia przez Aero2 wymagane jest rozwiązanie CAPTCHA, należy uważać ze zmianą DNSów. Jeśli zmienimy z serwerów DNS Aero2 na inne, to nie nastąpi automatyczne przekierowanie żądania HTTP na stronę z CAPTCHA. Dla porządku: adres, na który następuje przekierowanie to http://bdi.free.aero2.net.pl:8080/ (uwaga na port!), a resolvuje się to – tylko z sieci Aero2 przed uzyskaniem pełnego dostępu do internetu – na http://10.2.37.78:8080/

Jaki serwer DNS wybrać?

Wybór serwera DNS z którego korzystamy na urządzeniu końcowym jest ważny z kilku powodów:

  • Szybkość serwera DNS. Czas oczekiwania na odpowiedzi z serwerów DNS może być istotną częścią czasu ładowania stron Jest to szczególnie widoczne na stronach z dużą ilością wklejek z różnych domen. W przypadku szybkości serwera DNS nie chodzi jedynie o opóźnienie sieci (to można sprawdzić przy pomocy ping), ale o czas udzielenia odpowiedzi. Zależy on już od większej liczby czynników: opóźnienie sieci, posiadanie bądź nie odpowiedniego spisu w cache (oczywiście lepiej, jeśli odpowiada z cache), wydajność sprzętu i oprogramowania na którym działa DNS.
  • Poprawność odpowiedzi. Nic po szybkiej odpowiedzi z serwera DNS, jeśli będzie ona błędna. W skrajnym przypadku możemy paść ofiarą spoofingu DNS i trafić na podstawioną stronę.
  • Neutralność, czyli brak cenzury. Trochę wiąże się z poprzednim zagadnieniem, ale w tym przypadku chodzi o to, że do pewnych stron w ogóle nie będzie można się dostać. O ile działanie takie ma sens przy ograniczaniu zasięgu szkodliwego oprogramowania, to może być także służyć jako ograniczenie dostępu do treści.

 

Co warto zrobić w kwestii DNS?

Jeśli posiadamy sieć lokalną z kilkoma (i więcej) komputerami, to prawie na pewno warto postawić lokalny cache DNS – dzięki temu powtarzające się nazwy będą rozwiązywane lokalnie. Dobrym i prostym rozwiązaniem dla małej sieci jest dnsmasq, dostępny także dla OpenWrt.

Poza tym, warto wybrać te serwery DNS, które odpowiadają najszybciej. Zwykle nie popełnimy dużego błędu, jeśli wybierzemy serwery zalecane przez naszego dostawcę sieci lub wskazane automatycznie.

Czy zawsze lokalny serwer DNS lub oferowany przez naszego dostawcę Internetu jest najlepszy? Niestety nie. Prawie zawsze będzie on najszybszy pod względem opóźnienia sieci, ale już zawartość cache bywa różna. Szczególnie w przypadku lokalnego serwera może się okazać, że jego cache jest pusty dla większości zapytań. Na szczęście zwykle narzut lokalnego serwera nie jest duży.

Jeśli nasz komputer łączy się z internetem za pośrednictwem wielu sieci (wifi, połączenia GSM), można pomyśleć o postawieniu lokalnego cache DNS bezpośrednio na nim.

Jak najprościej znaleźć najlepsze serwery DNS?

Istnieje do tego darmowy i wolny program o nazwie namebench, służący do benchmarku serwerów DNS. Działa na wszystkich systemach, wersję dla Windows i Mac OS X można pobrać ze strony, w przypadku Linuksa zapewne jest w dystrybucyjnym repozytorium. Domyślnie działa z GUI, ale nie jest ono niezbędne – program daje się również uruchomić w konsoli. Ważne jest, żeby nie uruchamiać testu od razu, tylko najpierw przeczytać jak program działa i zastanowić się, co chcemy zrobić. Dlaczego? Ano dlatego, że pierwsze uruchomienie jest najbardziej zbliżone do rzeczywistych warunków ze względu na oryginalną, niezakłóconą poprzednimi testami zawartość cache testowanych serwerów DNS, czyli najbardziej miarodajne.

Jak korzystać z namebench?

W polu nameservers warto podać, oddzielone spacjami przynajmniej: DNS lokalny w sieci (jeśli posiadamy), serwery DNS naszego ISP. W przypadku Polski dodatkowo warto podać serwery DNS Orange (najpopularniejsze to 194.204.159.1 i 194.204.152.34) – kiedyś były dostępne tylko dla klientów TPSA, ale obecnie wyglądają na otwarte – działają z każdej sieci, z której testowałem – i osiągają dobre wyniki. W moim przypadku były szybsze, niż serwery DNS mojego ISP.

Namebench - ekran startowy
Ekran startowy namebench. Źródło: strona domowa programu namebench.

Poza tym, zaznaczamy globalne publicznie dostępne serwery cache’ujące oraz serwery regionalne. Można zaznaczyć sprawdzanie pod kątem cenzury i podzielenie się uzyskanymi wynikami. Lokalizacja to oczywiście Polska, query data source – możemy skorzystać z historii stron którejś z naszych przeglądarek, wyniki będą wówczas bardziej zbliżone do realnych.

Następnie uruchamiamy test i na kilka-kilkanaście minut zostawiamy komputer w spokoju. Po tym czasie otrzymamy wyniki: propozycję trzech najlepszych dla nas – zdaniem programu – serwerów DNS (kolejność ma znaczenie) oraz szczegółowe dane i wykresy. Kluczowy dla szybkości działania sieci jest oczywiście średni czas odpowiedzi z serwera DNS.

Na koniec uwaga: jeśli najszybsze serwery nie należą do naszego ISP ani nie są otwartymi, publicznymi serwerami, może się zdarzyć, że ich właściciel ograniczy za jakiś czas do nich dostęp.

 

Benchmark DNS cache – problemy.

Jakiś czas temu zainteresowałem się, głównie za sprawą prezentacji Infoblox na 9 PLNOG nt. DNS, tematem DNS cache i jego wydajności. Nie jest to zupełnie nowa sprawa, bo kiedyś otarłem się o problem wydajności DNS cache (albo raczej sprzętu, na którym działało to jako jedna z wielu usług…). Skończyło się tak, że mały i lekki dnsmasq jest za mały dla większej osiedlówki, choć nadal fajny w rozwiązaniach domowych.

Pierwsze skojarzenie z DNS to oczywiście bind, którego „wszyscy znają, wszyscy używają i nadaje się do wszystkiego”. Autorzy unbound przekonują, że to niekoniecznie dobre podejście, więc – zachęcony tym, co znalazłem w sieci – postanowiłem przetestować wydajność bind vs. unbound.

Nie ma lekko. W Debianie nie znajdziemy gotowego pakietu z narzędziem do testowania wydajności serwera DNS. W ogóle nie ma (nie znalazłem) wydajnego narzędzia do tego. Jest queryperf, dostępny w źródłach bind (do samodzielnej kompilacji), ale do wydajności mu daleko – często obciąża maszynę porównywalnie, jeśli nie bardziej, niż sam testowany program. W prezentacji (http://www.infoblox.nl/content/dam/infoblox/documents/solution-notes/infoblox-note-ib-2000-performance-test.pdf – dead link) znalazłem skrypt:

#!/b in/sh
SECS=5
INPUT=qp.forward.master.cached
SERVER=10.34.31.2
# SECS is number of seconds to run test
# INPUT is input file
# SERVER is server IP
queryperf -s $SERVER -d $INPUT -l $SECS > out1 2>&1 &
queryperf -s $SERVER -d $INPUT -l $SECS > out2 2>&1 &
queryperf -s $SERVER -d $INPUT -l $SECS > out3 2>&1 &
queryperf -s $SERVER -d $INPUT -l $SECS > out4 2>&1 &
queryperf -s $SERVER -d $INPUT -l $SECS > out5 2>&1 &
queryperf -s $SERVER -d $INPUT -l $SECS > out6 2>&1 &
wait
grep ‘Queries per’ out? | awk ‘BEGIN { sum=0;}{ sum += $5;}
END {printf(“Total: %.1f qps\n”, sum);}’


Szybkie zapytanie na kanale IRC i… jedna osoba zgłasza, że przesiadła się na unbound i jest zadowolona; sugestii co do oprogramowania testującego brak, za to pojawia się koncert życzeń: jak już to jeszcze przetestować pnds_recursor, djbdns… i może bind10, bo podobno poprawiona wydajność. Robi się tego sporo, bo i lab z paroma maszynami wysyłającymi zapytania by się przydał, i testowanych demonów większa ilość. A miało być szybkie i proste zagadnienie na 1-2h.

Do tego problem danych testowych – każdy ma u siebie nieco inną charakterystykę ruchu, wyniki mogą się różnić dość znacznie, więc skąd wziąć dane? Jasne, można benchmarkować na podstawie własnych, rzeczywistych danych i będzie to najbliższe optymalizacji w danym przypadku, ale czy wartościowe dla innych? No i na pewno nie opublikuję takiego testowego zestawu danych. Jest też problem dostosowania konfiguracji do konkretnej platformy, na której uruchamiane będzie oprogramowanie (np. ilość wątków). Domyślny konfig jest różny dla różnych demonów, przy czym domyślny debianowy dla unbound ma się nijak do maszyny wieloprocesorowej. No i przydał by się tuning samego systemu pod kątem wydajności sieci, bo default w Linuksie jest raczej słaby.

Więcej pytań, niż odpowiedzi. Stanęło na tym, że pełnego testu nie zrobiłem. Za to puściłem szybki test na jakimś małym zestawie danych (kilkanaście wpisów). W ww. skrypcie zmieniłem liczbę procesów na 4, czas na 60 sekund i testowałem na laptopie (Intel Core i5). Nie do końca optymalnie, ale cóż, lepiej, niż pojedynczy proces. Poprzestałem więc na tym pseudobenchmarku na domyślnym konfigu – zabawa w optymalizację to grubsza sprawa, jeśli ma być zrobiona porządnie. Unbound wypadł bardzo dobrze. Mimo, że działał tylko na pojedynczym rdzeniu, wypadł dwukrotnie lepiej, niż bind.

Nie ukrywam, że chętnie poznam sugestie dot. danych testowych (takich, które można opublikować) i ew. doświadczeń z benchmarkowaniem DNS (cache). Jeśli się zbiorę i zrobię benchmark, to dane i wyniki będą opublikowane. Na razie stanęło na tym, że na moich dekstopach zmieniłem bind na unbound (tak, mam lokalne cache na desktopach od jakiegoś czasu, raczej eksperyment, kiedyś napiszę na ten temat).

Jak zdobyć certyfikat IPv6 i fajną koszulkę za darmo.

No i udało się. Szczerze mówiąc myślałem, że będzie trudniej i nie przypuszczałem, że cel jest tak blisko. Blokada IRC przez HE o której pisałem niedawno okazała się świetnym motywatorem do skończenia testu, czyli osiągnięcia poziomu Sage, który pozwala na odblokowanie dostępu do IRC. No i okazuje się, że prawdą jest to, co chciałem sprawdzić, czyli że certyfkiat IPv6 od HE da się zrobić, nie wydając ani złotówki i korzystając wyłącznie z zasobów (domeny, serwery DNS), dostępnych zupełnie za darmo w Internecie.

Nie zamierzam robić tutoriala krok po kroku – sam proces certyfikacji jest prosty i w sumie daje sporo frajdy (pod warunkiem, że nie trzeba powtarzać kroków kilka razy jak w moim przypadku…), poza tym samo HE daje tutoriale video, ale parę wskazówek się przyda, żeby się nie frustrować niepotrzebnie.

Adresację (tunel) IPv6 za darmo dostaniemy na przykład od samego HE. Z kolei domeny (dobra, subdomeny) za darmo daje na przykład afraid.org w ramach usługi FreeDNS. Niestety, ich NSy nie posiadają adresów IPv6 (żaden!). Można to jednak obejść delegując subdomenę na takie NSy, które posiadają obsługę IPv6. Na przykład te od HE.

Żeby nie było za prosto – wygląda, że jest jakiś problem z cache’owaniem(?) wpisów DNS po stronie HE – w pewnym momencie panel żadną miarą nie chciał przyjąć obsługi domeny, mimo, że powinien (support też tak twierdził). Rozwiązaniem jest dodanie delegacji na wszystkie ns1 do ns5 na he.net. Potem, przy którymś teście co prawda trzeba usunąć ns1, bo test wymaga (IMHO błędnie, powinien sprawdzać czy minimum 1 ma), żeby wszystkie NSy miały adresy IPv6, ale to insza inszość.

I tyle. Warto dodać, że ukończenie certyfikatu IPv6 od HE daje nie tylko możliwość odblokowania dostępu do IRC. Dodatkowo (a może przede wszystkim?) każdy, kto uzyska poziom Sage może otrzymać fajną, geekową, unikatową koszulkę za darmo (wysyłka też) – wystarczy podać rozmiar w panelu HE i potwierdzić adres do wysyłki. Taki – podobno bardzo udany – pomysł HE na popularyzację IPv6.

Zachęcam do zabawy. Mi pozostało wymaksowanie punktów. Osobną kategorią zabawy jest znalezienie błędów (implementacyjnych, nie rzeczowych) w samym teście (można udawać, że się zrobiło pewne rzeczy, nie robiąc ich, ale nie o to oczywiście chodzi). 😉

UPDATE: Szczerze mówiąc, myślałem, że Sage jest więcej, szczególnie, że sporo spotkałem na IRCu. Tymczasem na PLNOG dowiedziałem się, że jest raptem 87 osób w Polsce i ok. 4600 na całym świecie. Więcej statystyk.

Tunele IPv6 od Hurricane Electric i IRC – uwaga przy przeniesieniach!

Od dłuższego czasu byłem – powiedzy, że szczęśliwym, chociaż przy dynamicznym IP miałem uwagi – użytkownikiem IPv6. Jednym źródłem jest tunel od HE, drugim jest tunel IPv6 od czeskiego virtio.cz. Z HE byłem zadowolony, ale AFAIK wymagają publicznego IP na końcówce tunelu (lub zabawy z przekierowywaniem portów – głowy nie dam, czy w ogóle się da, ale powinno się dać). Natomiast rozwiązanie Czechów korzysta z Tunnel6, który bez problemu, OOTB, bez zabaw z przekierowaniem portów przechodzi przez NAT (a akurat taką miałem potrzebę). I tak sobie to wszystko działało parę lat, służąc głównie do połączeń SSH, zapewniając stały adres IP służący dla dostępu IRCa i – w drugim przypadku – robiąc za przejście NAT bez przekierowywania portów na routerze.

Wszystko działało dobrze, do czasu… Niedawno uruchomiony został PoP HE w Warszawie, więc postanowiłem przenieść tam terminowanie tunelu. Pełna treść ogłoszenia wyglądała następująco. Nic nie wróży problemów, prawda? Trochę może boleć konieczność usunięcia i założenia nowego tunelu, ale rozumiem powody. Postępuję zgodnie z instrukcją, tj. usuwam stary tunel (to był błąd! powiadam wam, nie idźcie tą drogą!) i tworzę nowy, terminowany w W-wie. Niby bliżej, ale szału nie ma – opóźnienia do docelowych hostów podobne jak były. Ogólnie – wiele hałasu o nic, spokojnie mogło zostać po staremu, czyli z terminowaniem w Holandii. No ale skoro już zmieniłem, odwrotu nie ma, skoro wszystko działa, to niech tak zostanie…

Wszytko działało. Do czasu. Parę dni temu zauważyłem, że nie mogę się połączyć do serwerów IRC. Co gorsza, i co bardziej podejrzane, w żadnej sieci. Nie działał ani IRCnet, ani Freenode, ani OFTC. Szybka diagnostyka (ogólnie łączność do serwerów jest, wygląda na blokadę portów i to na pierwszym hopie), ticket do HE, ale zanim odpowiedzieli, znalazłem już przyczynę:

Due to an increase in IRC abuse, new non-BGP tunnels now have IRC blocked by default.  If you are a Sage, you can re-enable IRC by visiting the tunnel details page for that specific tunnel and selecting the ‚Unblock IRC’ option. Existing tunnels have not been filtered.

Pewnie nawet kiedyś to przeczytałem i zdążyłem zapomnieć. Oczywiście – to już informacja z odpowiedzi z ticketa – przeniesione tunele traktowane są jak nowe, będą miały zablokowany dostęp do IRC (do momentu uzyskania Sage) i tyle. Czyli chwilowo „odwyk” od IRCa.

Cóż, z jednej strony jest to jakiś motywator do powrotu do zrobienia certyfikatu IPv6 od HE (który polecam, bo bawiąc uczy, ucząc bawi), z drugiej strony jest to wylewanie dziecka z kąpielą, bo co to za popularyzowanie przez blokowanie? Zrobienie certyfikatu nie jest problemem (ale – póki co – okazało się niemożliwe w pierwotnie zakładanym wariancie, czyli „bezinwestycyjnie”, opierając się tylko na dostępnych za darmo usługach w sieci, stąd opóźnienie w jego robieniu). Być może skończy się po prostu zakupem domeny…

PS. Tak, wiem, mogę wziąć kolejny tunel od Czechów. Albo od SixXS (który AFAIK też zza NAT od kopa działa). Ale HE obok wad ma zalety. Choćby aktualizacja endpointa wgetem, co sprawia, że wszędzie (*wrt) zadziała.

Twitter/Identi.ca DNS hack, czyli jak obejść zabezpieczenie Wi-Fi.

Przyjeżdżasz na konferencję, wpadasz do pokoju hotelowego, znajomi już powinni być, ale czy faktycznie dojechali? Jeśli poruszasz się bez mobilnego internetu, masz mało wygodny Internet w telefonie, uruchomionego laptopa i nie spięte te dwa urządzenia z jakiegoś powodu, czy recepcja hotelowa jest daleko lub przeżywa oblężenie, to można to sprawdzić wykorzystując fakt, że zwykle hotelowe systemy dostępu przepuszczają zapytania (i odpowiedzi) DNS. Teraz jest to jeszcze prostsze, bo nie trzeba samemu ustawiać tunelu DNS. O ile tylko znajomi korzystają z Twittera lub Identi.ca…

Prostą w użyciu, nie wymagającą logowania i publicznie dostępną bramkę Twitter/Identi.ca -> DNS zapewnia serwis Any.IO. Można pobrać ostatni status użytkownika, ostatnich 10 statusów, informacje o użytkowniku i… to w zasadzie tyle (przykłady na stronie). Wszystko w trybie tylko odczyt – nie ustawimy swojego statusu (dziwnym nie jest, wymagałoby podania hasła), ale czasem może być przydatne.

Oczywiście to tylko namiastka tunelu i ciekawostka (ale bardzo wygodny gotowiec), jeśli ktoś szuka więcej informacji to więcej o tunelowaniu ruchu w zapytaniach DNS jest tutaj (ang.; nie bawiłem się, ale wygląda sensownie i sporo przydatnych linków).

PS. Wszyscy piszą disclaimery nt. legalności tego typu rozwiązań. IANAL, ale IMVHO jeśli jesteśmy klientem hotelu, a zapytania DNS są przepuszczane, to nie jest to nieuprawniony dostęp. A już na pewno nie pojedyncze zapytanie w formie prezentowanej przez Any.IO.

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.