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.

Marne ficzery Opery.

Fani Opery zwykli pisać, jaka to wspaniała i bogata w ficzery przeglądarka jest. Że praktycznie wszystko, co w Firefoksie robi się za pomocą rozszerzeń, tu jest wbudowane. Cud miód. Dziś chciałem sprawdzić, jak wygląda jedna rzecz pod Operą, w tym celu musiałem się przetunelować. Tradycyjnie robię to po SSH, bo najwygodniej – zestawienie tunelu to jedno polecenie, potem Edit -> Preferences -> Network -> Settings, a następnie wybranie konfiguracja SOCKS host. I już.

To oczywiście wersja dla Firefoksa bez dodatków. W Operze patrzę, szukam… Nie ma. No dobrze, szybki gógiel… Lekkie zdziwienie, bo znajduję wyłącznie rozwiązania oparte o zewnętrzne programy (już nawet nie rozszerzenia). Następnie dowiaduję się, co piszą autorzy Opery o wsparciu SOCKS (dead link)…

Podsumowanie zamieszczone na forum Ubuntu idealnie oddaje sprawę: Its hard to believe that a major browser like opera does not support socks