Bezpieczniejsze i wydajne łącze mobilne

Nieco ponad pół roku temu opisałem możliwe sposoby przyspieszania łącza internetowego. Znowu jestem na urlopie, bez dostępu do „normalnego” łącza i korzystam z Aero2. Jak pisałem, najbardziej, ze względu na łatwość uruchomienia, przynajmniej w środowisku Linux, odpowiada mi wariant z socks proxy i ssh.

Poza tym, mignęła mi ostatnio – zupełnie nie pamiętam przy jakiej okazji, ale niezwiązana z tym tematem – informacja o polipo, czyli cache’ującym serwerze proxy, pomyślanym o użytku osobistym, domowym lub małych grupach użytkowników. W stosunku do pełnoprawnego proxy WWW, czyli popularnego squida ma parę ciekawych cech: jest lekki i szybki, prosty w konfiguracji, może robić za mostek między sieciami IPv4 i IPv6, umie socks proxy, posiada pewne opcje umożliwiające łatwe filtrowanie reklam i zwiększanie prywatności.

W kombinacji z tunelem SSH z którego korzystam, polipo będzie pełnił rolę cache oraz translatora socks proxy na zwykłe proxy WWW. O ile większość przeglądarek jakoś obsługuje socks proxy, o tyle chyba tylko w Firefoksie można to po prostu wyklikać, pozostałe wymagają zabawy z wierszem poleceń w celu uruchomienia obsługi. Poza tym, mając proxy WWW w systemie można je wykorzystać nie tylko do przeglądarek, ale do wszystkich programów, które umożliwiają ustawienie proxy HTTP.

Czyli całe rozwiązanie składa się więc z dwóch elementów: tunelu SSH, zapewniającego szyfrowanie przesyłanych danych (bezpieczeństwo) oraz kompresję (wydajność), oraz polipo zapewniającego cache plików (wydajność). Ponieważ moje łącze mobilne jest wolne (Aero2; DOWN/UP 512/256 kbps), zdecydowałem się umieścić serwer proxy na laptopie, przed tunelem SSH (patrząc od strony przeglądarki). Wydaje mi się, że tak będzie wydajniej – część zapytań nie trafi w ogóle do tunelu. Możliwa jest też konfiguracja z proxy uruchomionym na serwerze terminującym tunel – patrz linki na końcu wpisu. Topologia rozwiązania wygląda zatem następująco:

Internet - serwer - tunel SSH - polipo - przeglądarka

Serwer to maszyna z Linuksem (może być VPS dowolnego typu), serwerem SSH i przyzwoitym (optymalnie: lepszym od naszego mobilnego łączem).

Uruchomienie tunelu:

ssh -CND 9000 user@serwer

Konfiguracja serwera polipo (bardzo podstawowa, dostępnych jest znacznie więcej opcji, ale ich opis wykracza poza tematykę tego wpisu; cat /etc/polipo/config):

logSyslog = true
logFile = /var/log/polipo/polipo.log
socksParentProxy = 127.0.0.1:9000
socksProxyType = socks5

Następnie ustawiamy w przeglądarce WWW jako HTTP proxy: adres 127.0.0.1 i port 8123 (domyślny port na którym słucha polipo). Gotowe.

Uwaga dotycząca bezpieczeństwa: z uwagi na to, że w ww. rozwiązaniu szyfrowany jest tylko ruch HTTP, i tylko ten przechodzący przez proxy, należałoby pewnie ograniczyć dostęp dla pozostałego ruchu wychodzącego na firewallu. Jeszcze lepszym rozwiązaniem pod względem bezpieczeństwa, z uwagi na ew. spoofing DNS i uniezależnienie się od DNSów dostawców sieci, byłby VPN. Ale w tym przypadku nie to jest priorytetem, poza tym, korzystam z lokalnego serwera DNS.

Linki:

  1. Opis konfiguracji Aero2, wvdial i modemu Huawei E3131.
  2. Alternatywna konfiguracja z polipo uruchomionym na serwerze.

Jazda z Yanosik.pl

Problemu z mandatami jakoś nigdy nie miałem, choć jeżdżę „po staremu”, czyli bez CB i bez gadżetów. Może niezupełnie przepisowo, ale bez brawury. Jakoś się ostatnio zaostrzyły przepisy, to co wyprawiają służby (ustawmy się 20 m od tablicy oznaczającej koniec miejscowości, gdzie od 200 m szczere pole i krzaki…) irytuje, fotoradarów przybyło, a ograniczenia prędkości są… różne. W pracy kumple rozmawiali niedawno o aplikacji Yanosik, aplikacji na telefony, chwalili, więc stwierdziłem, że zainstaluję i dam szansę. Tym bardziej, że jest bezpłatny (a byłem pewien, że nie jest, najwyraźniej go z czymś myliłem).

Mały disclaimer na początek: do tej pory w zupełności wystarczała mi zwykła mapa, ostatnio Google Maps w telefonie (czyli też mapa), zupełnie od niedawna korzystałem z nawigacji w Google Maps, więc z tym będę Yanosika porównywał. Przejechane ponad 300 km, głównie za miastem.

Instalacja

Instalacja aplikacji Yanosik z Google Play, bez problemu. Żeby korzystać w sposób z gamifikacją (zbieranie poziomów), trzeba się zarejestrować. Interfejs jak dla mnie prosty, choć rzuca się w oczy to, że aplikacja ma ambicję być kombajnem: rejestrator video, nawigacja, antyradar. Dałoby się prościej, gdyby kombajnu nie było, ale i tak jest OK.

Z pierwszej funkcji, czyli zapisu video w ogóle nie korzystam, więc oceniać/opisywać nie będę. Nawet testowo nie mam jak włączyć, a nie przy każdym montowaniu telefonu ma ona sens. U mnie nagrywałaby półeczkę w aucie. 😉

Nawigacja wygląda nieźle na pierwszy rzut oka (lepiej niż ta w Google Maps), ale po włączeniu niestety szybko traci. Pierwsze co mnie zirytowało, to teksty. Albo nawet samo cięcie głosu. Skręć w p… lewo. Sorry, ale ja po tym w zupełnie wyraźnie słyszę literę p. Z bólem bo z bólem, ale idzie ostatecznie przywyknąć. Gorzej, że sama nawigacja życzyła sobie wyraźnie, bym skręcał w lewo w miejscu, gdzie nie tylko nie było sensu, ale i możliwości. Trochę dziwne są też komunikaty typu skręć na rondzie w lewo drugi zjazd. Może jestem ortodoksem, ale na rondzie skręcam wyłącznie w prawo. Wyznaczanie tras OK, jest funkcja pomijania płatnych dróg (nie testowałem, ale już ją lubię). W porównaniu z Google Maps nawigacja w Yanosiku wypada jednak IMO gorzej. Gdyby zależało mi tylko na nawigacji, używałbym Google Maps.

Antyradar

Antyradar, czyli to, co tygrysy lubią najbardziej. Przyznaję się, że o ile ze zwalnianiem w terenie zabudowanym nie mam problemu, i fotoradary, i znaki ostrzegające o nich zwykle widzę, o tyle czasem zdarza mi się taki znak przeoczyć, a zmniejszenie prędkości jest do bezpiecznej moim zdaniem, co nie zawsze musi się pokrywać ze zdaniem stawiających fotoradar. Bo jak zwalniam na krajówce ze ~120 km/h o około połowę, to już naprawdę nie ma IMO wielkiego znaczenia, czy będzie to 10 km w tę czy w tamtą stronę. Choć oczywiście zależy od warunków, obecności ludzi, pojazdów itp. W każdym razie często łapałem się na tym, że OK, zwolniłem, OK, radar, ale… ile tu było? Na tę przypadłość Yanosik jest wyśmienity. Ostrzega dwa razy – kilkaset metrów przed zagrożeniem (niekoniecznie radar, o tym zaraz) i przy zagrożeniu. W przypadku fotoradarów podaje też maksymalną dozwoloną w danym miejscu prędkość.

Na początku miałem lekki problem, bo dostawałem za dużo – jak na mój gust – informacji. Doczytałem FAQ i najprawdopodobniej chodziło o to, że aplikacja nie rozpoznaje kierunków, czyli dostajemy dane dla obu pasów. Dodatkowo, zagrożeniem jest nie tylko kontrola prędkości czy fotoradar, ale także np. zatrzymany pojazd czy roboty drogowe. Być może można te informacje wyłączyć. Można też przywyknąć, co nie jest trudne (i tak zrobiłem). Wcześniej po prostu nie zwracałem uwagi na tego typu rzeczy.

Potem – bajka. Większość informacji prawidłowa, podawana zawczasu. Raz zdarzyło mi się, że nie dostałem w ogóle informacji o fotoradarze (o którym wcześniej, jadąc w drugą stronę dostałem informację – czyżby jednak działanie kierunkowe?), raz dostałem informację na mój gust za późno, tj. wcześniej sam zobaczyłem fotoradar i zacząłem zwalniać. Bez tego byłoby odrobinę zbyt gwałtowne hamowanie.

Interfejs

Interfejs – zdecydowanie mam mieszane uczucia. Yanosik ma interfejs niby z sensem, prosty i ergonomiczny, ale żeby zgłosić coś w czasie jazdy – nie jest fajnie. Nie jestem pewien, czy wykorzystuje maksymalny kontrast (na pewno warto podkręcić jasność ekranu przy włączaniu Yanosika). Pewnie brak uchwytu na telefon też nie pomaga (pracuję nad tym… ;-)). Nie znalazłem opcji, by ETA było w jednostkach czasu, nie odległości. Na pewno dałoby się coś uprościć w interfejsie, choć sam pomysł potwierdzania/odwołania dla już zgłoszonych zagrożeń jest bardzo fajny.

Social

Social – leży i kwiczy. Niby jest gamifikacja na zasadzie poziomów, niby jest podawanie polecającego ale… po co? Poziomy wyglądają na stworzone jakby na siłę (patrząc po opisach), sprowadzają się wyłącznie do przejechanych kilometrów, a można było tak fajnie rozwinąć, typu zgłoś minimum 3 zagrożenia lub potwierdź minimum 10 zagrożeń czy przejedź minimum X km z nawigacją. Widzę w tym parę zalet, ale może obecnie(?) twórcom nie zależy. W każdym razie, social w aplikacji jest, ale go nie ma. Nie udało mi się nawet ustalić co miałaby zyskać osoba, którą wpiszę jako polecającego.

Podobnie z podziękowaniami. Wydaje mi się, że aplikacja Yanosik pokazuje moje „podziękowania” (bardziej: potwierdzenia), ale czy coś z tego wynika? Nie wiem. Brakuje mi info, ilu osobom przydała moja informacja, tj. ilu potwierdziło.

Inne

Inne – apetyt na baterię bardzo umiarkowany. Co prawda jeżdżę z telefonem podpiętym do ładowarki, na dodatek miałem ustawione wygaszanie ekranu (duży plus za możliwość wyboru trybu), ale w trybie antyradaru, bez nawigacji zdecydowanie się ładował. W przypadku Google Maps ładował się… ledwo. Ostatecznie zmieniłem na włączony ekran (wygodniej) i zobaczę jak będzie.

Bardzo umiarkowane zużycie transferu. Dla ponad 300 przejechanych km zużytych było – wg danych systemu Android – raptem ponad 6 MB transferu. Większość jazdy w trybie samego antyradaru, ponad 100 km z nawigacją. Wychodziłoby jakieś 2 MB/100 km, czyli nawet najmniejszy pakiet z netem powinien do Yanosika spokojnie wystarczyć. Nie mam dokładnych pomiarów, ale wydaje mi się, że Google Maps zużywa sporo więcej.

Ogólnie – polecam. Jeśli znacie coś podobnego (czy to nawigacja, czy antyradar), chętnie poznam.

UPDATE: Dodany akapit o podziękowaniach.
UPDATE: Popełniłem stronkę z zestawieniem ilości kilometrów koniecznych do przejechania na dane poziomy w Yanosiku.
UPDATE: Przestałem korzystać z Yanosika. Zirytował mnie, tu więcej o wadach Yanosika w nawigacji.

PUM

Jakiś czas temu zacząłem korzystać z Uptime Monitor. Przyznaję, że jestem zadowolony, do pełni szczęścia brakowało mi czegoś, co wystawi moje uptime’y na WWW. Tzn. jest sporo fajnych narzędzi, rysujących ładnie i live, tzn. z autoodświeżaniem, ale… nie byłem przekonany do pomysłu publikacji kluczy API. Tym bardziej, że w niektórych przypadkach udostępnienie klucza wiąże się z z podaniem danych hosta, loginu i hasła do htpasswd itp.

Wolałbym mieć możliwość ukrycia nazwy/IP i ogólnie nie podawania zbyt wielu informacji, zwł. klucza API. Zauważyłem też, że nie ma (a przynajmniej nie znalazłem) nic do obsługi Uptime Monitora w Perlu. Stwierdziłem, że generowanie statycznego HTML (docelowo) z crona jest zupełnie wystarczające, a ew. autoodświeżanie prosto można załatwić JSem czy IIRC nawet polem META w HTML (koła nie odkrywam, „konkurencja” też tak robi.

I w ten sposób powstał PUM czyli Perl Uptime Monitor. 😉 Jest możliwość nadpisania nazwy, jest możliwość generowania uptime dla danego okresu (ilość dni wstecz). Brakuje opakowania wyniku w HTML (wyniki na STDOUT póki co…), ale to wkrótce… W sumie nie ma problemu z pobraniem danych do wykresu czasu odpowiedz, ale nie planuję póki co. Zachęcam do forkowania i zgłaszania pull requestów, ew. pomysłów w komentarzach.