Pomiędzy bitami

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.

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.

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.

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.

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.

UPDATE: Dodane info i przykłady dla TFTP.

Licencja wpisu: CC BY-NC-SA (wyjątkowo, specjalnie dla jakilinux.org z okazji dyskusji nt. wpisu o DHCP od ISC).

Jak wiadomo, 5 maja tego roku szykuje się mała rewolucja związana ze zmianą funkcjonowania root serwerów DNS (wprowadzenie DNSSEC), która dla części użytkowników może się skończyć brakiem dostępu do Internetu.

Jeśli chodzi o użytkowników PowerDNS, to autorzy zapewniają, że zmiana nie ma wpływu na funkcjonowanie serwerów, a zmiana na wersję wspierającą DNSSEC nie jest konieczna do zachowania działania w dotychczasowej formie.