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.

BitlBee czyli ostateczny klient CLI do… wszytkiego.

BitlBee to multikomunikator czyli klient… wszystkiego (o czym dalej), działający jak stary, dobry IRC. Filozofia jest specyficzna, bo multikomunikatorem jest demon, z którym komunikujemy się jak z serwerem IRC. Czyli bierzemy dowolnego klienta IRC (np. konsolowe irssi), którym podłączamy się do serwera BitlBee. Potem już w zasadzie analogicznie – mamy kanał (z użytkownikiem @root, który z systemowym root nie ma nic wspólnego), a kontakty dodane przez serwisy są nickami na tymże kanale. Rozmowa jak z każdym innym użytkownikiem IRC – można w osobnym oknie (domyślne i IMO najwygodniejsze), można w oknie wspólnym…

Rozstrzał wersji jest ogromny – w nowowydanym Squeeze jest bitlbee jest w wersji 1.2.8-1, w unstable – 3.0.1-1. Szybka lektura changeloga na stronie projektu i okazuje się, że zaliczyli przeskok numeracji z 1.3 na 3.0, przy czym wersja 1.3 zaliczyła całkowite przepisanie kodu IRC i tyle zmian, że w changelogu nie wymieniają. Dodatkowo, zarówno bitlbee-libpurple, czyli transport do innych sieci, jak i bitlbee-plugin-otr, czyli implementacja OTR, nie występują w wersji dla Squeeze, więc wybór był prosty – 3.0.1.

Oczywiście nie jest idealnie – już na starcie zgłosiłem buga z nieustawianiem haseł domyślnie, ale to łatwo poprawić samodzielnie. Poza tym, ma to średni wpływ, bo domyślnie demon dostępny jest tylko lokalnie, a do dostępu do samych serwisów i tak wymagane jest kolejne uwierzytelnianie.

Kolejny bug, również zgłoszony (w sumie do upstreamu), to korzystanie jedynie z niesolonych MD5 (i jedynie z nich) do przechowywania skrótów haseł. Okazało się, że błędnie, bo MD5 są solone (ale nadal tylko z MD5 można korzystać, co zbyt fajne nie jest, ale wystarczy mocne hasło do głównego konta).

W czasie testu opierałem się na tych dwóch opisach BitlBee. Nie twierdzę, że są najlepsze, ale mi wystarczyły w zupełności. Do wyboru jest sporo innych w sekcji External docs na stronie projektu. Tak naprawdę sam program posiada bardzo dobry, dostępny w każdej chwili tutorial i pomoc.

I to w zasadzie tyle. Korzystanie jest równie dobre i wygodne, na jakie wygląda z opisu. Oczywiście, jeśli komuś pasuje ircowy sposób rozmowy i obsługi. Obsługiwany jest nie tylko Jabber, ale także Twitter (czyli też identi.ca), MSN, OSCAR (AIM/ICQ). Wygląda, że BitlBee potrafi korzystać z libpurple, więc liczba protokołów raczej będzie szybko rosnąć. Teoretycznie obsługiwane są także GG, IRC (trochę nie widzę sensu, ale jest…), bonjur i wiele innych protokołów.

Na deser smaczek: BitlBee jest leciutkie. Lżejsze od centerim (dawniej centericq), z którego korzystałem do tej pory. Testy na laptopie zdane na piątkę (tylko jabber), jak tylko zrobię upgrade routera do Squeeze, to na pewno zmieniam centerim na BiltBee + irssi.

PS. Dla nieangielojęzycznych: mój krótki tutorial konfiguracji BitlBee po polsku.