Tag: howto

Opublikowane w

Orange, wvdial i modem Huawei E1752C

Ponieważ w ramach jednego projektu (hm, na razie nic nie nadaje się do publikacji) klikałem na dwa modemy GSM, to obok mojego Huawei E3131 w laptopie pojawił się pożyczony modem GSM Huawei E1752C z kartą sieci Orange. Dla pamięci i gdyby komuś miało się przydać – konfiguracja dostępu do internetu dla sieci Orange pod Linuksem.

W lsusb Huawei E1752C jest widoczny jako:

new high-speed USB device number 11 using ehci-pci
New USB device found, idVendor=12d1, idProduct=141b
New USB device strings: Mfr=3, Product=2, SerialNumber=4
Product: HUAWEI Mobile
Manufacturer: HUAWEI Technology

w dmesg jako:

Bus 002 Device 011: ID 12d1:141b Huawei Technologies Co., Ltd.

Sam modem działał od kopa (kernel 4.1.0-1-amd64, Debian unstable) i nie wymagał żadnych ingerencji, ale zaznaczam, że trafił do mnie jako używka, więc nie wiem, czy było grzebane.

Szybka przeróbka mojej konfiguracji dla Aero2, w oparciu o oficjalne instrukcje ze strony Orange nie zakończyła się sukcesem. Poszukiwania w sieci naprowadziły mnie na ten artykuł nt. konfiguracji modemu GPRS dla sieci Orange w Debianie. Potwierdzam, działa. Ale IMO trochę przydługie, więc postanowiłem skrócić do wersji mniej więcej minimalnej. Skończyłem z takim konfigiem do wvdial:

[Dialer orange-pin]
Modem = /dev/ttyUSB0
Init1 = ATZ
Init2 = AT+CPIN=1234

[Dialer orange]
Modem = /dev/ttyUSB0
Init3 = AT+CGDCONT=1,"IP","internet"
Username = "internet"
Password = "internet"
Phone = "*99#"
Dial Command = ATDTW
Stupid Mode = yes
Dial Attempts = 0

Najpierw trzeba wywołać wvidal orange-pin, a gdy się zakończy, można połączyć się z siecią przy pomocy wvidal orange. Jak widać, kluczową różnicą było ustawienie parametru Dial Command.

Samo połączenie z Orange można uruchomić na Linuksie prościej, ponieważ na desktopie da się wyklikać konfigurację w network manager. Sprawdzone na Debianie Jessie z kernelem w okolicach 4.0. Czasem jednak może przydać się wersja bardziej ręczna, szczególnie jeśli ktoś nie ma GUI w maszynce.

Opublikowane w

Korzystając z apt-dater – parę uwag

Od pewnego czasu korzystam z opisywanego kiedyś narzędzia apt-dater do aktualizacji hostów w środowiskach większych, niż kilka własnych testowych maszyn. Garść praktycznych uwag nt. używania w takich środowiskach.

  1. W okolicy wersji 1.0 zmienił się format pliku (teraz jest XML), przez co linkowany wyżej opis jest nieaktualny. Zmian wymagał też skrypt generujący konfigurację apt-datera na podstawie danych z Chefa.
  2. Warto podzielić hosty na grupy – raz, że łatwiej decydować, gdzie wykonujemy aktualizację w danym momencie, dwa, że każdy host to osobne procesy w momencie działań więc… może być tego za dużo, jeśli zaczniemy aktualizować listę pakietów wszędzie jednocześnie (tak, mam skonfigurowane limits na workstacji, tak walnąłem w limity, jak leciałem hurtem).
  3. Sama aktualizacja to nie wszystko, trzeba jeszcze zrestartować procesy korzystające ze starych bibliotek. Kiedyś był checkrestart, teraz jest bardziej popularny –  i nieźle współpracujący z apt-dater – needrestart.
  4. Niezależnie od podziału na grupy, można ad hoc zaznaczyć hosty do wykonania operacji (polecenie tag). Sposób niezbyt intuicyjny, bo najpierw zaznaczamy hosty [t], następnie zatwierdzamy je do wykonania [;], a na końcu wybieramy polecenie do wykonania.
  5. Apt-dater przyspiesza pracę, ale nie udało mi się (i nie tylko mi), uniknąć podłączania do każdej sesji po zakończeniu aktualizacji i zamykania jej. Nawet, jeśli cała aktualizacja przeszła pomyślnie, bez interaktywnych pytań i nie ma nic do restartu. Gdyby się komuś udało – proszę o komentarz.
  6. Odpowiednio ustawione hold lub apt_preferences to podstawa, jeśli ma się jakieś dziwne (czytaj: 3rd party) pakiety, których autorzy niezupełnie umieją paczkować Debian way.

W każdym razie apt-dater bardzo ułatwia i przyspiesza pracę. Generalnie polecam.

Opublikowane w

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.