Internet Mobilny - Jak zaoszczędzić cenne kilobajty.

marzec 23rd, 2008 by Maciejowy | Drukuj

Witam!
Dziś przedstawię krok po kroku jak zaoszczędzić cenne kilobajty w usługach prepaid: Simdata, Orange Free… etc. Na wstępie uprzedzam że sposób zaoszczędzenia kilobajtów, a co za tym idzie naszych pieniędzy jest… Banalnie prosty! W kolejnych etapach przedstawię w jaki sposób skonfigurować tunel między nami a siecią gadu-gadu dzieki któremu zaoszczędzimy od 30 do nawet 40%! Jako że GG w standardzie nie ma opcji wyboru serwera, posłużymy się multikomunikatorem jakim jest Miranda-IM. Serdecznie zapraszam do lektury oraz testowania!

Co będzie nam potrzebne?

  1. Konto SSH (Shell)
  2. Aplikacja Mirand-IM
  3. Aplikacja Putty
  4. Odrobina chęci oraz czasu ;)

1. A więc zaczynajmy!

  1. Wchodzimy na stronę >KLIK< i ściągamy najnowszą wersję putty dla naszego systemy (plik putty.exe)
  2. Po ściągnięciu ‘odpalam’ Putty’ego, czas na konfigurację

Naszym oczom powinien ukazać się…

2. Zacznijmy od konfiguracji połączenia z serwerem SSH .


  1. W pierwsze pole (1) wprowadzamy adres IP bądź domenę naszego serwera SSH
  2. W drugim polu (2) wpisujemy port naszego serwera SSH
  3. Trzecie pole (3) to nazwa naszego połączenia, możemy ustawić dowolne.
  4. Czwarte (4), pole wyboru zostawiamy niezmienione.
  5. Po wypełnieniu pól klikamy przycisk [Save].

3. Brawo! właśnie skonfigurowaliśmy nasz serwer SSH, teraz możemy wykonać próbne połączenie z serwerem.

  1. Zaznaczamy wcześniej utworzony profil połączenia, w moim przypadku jest to “Tunel SSH”
  2. Klikamy na przycisk [Open]
  3. Jeżeli wszystko poszło dobrze to powinien ukazać się nam poniższy screen:

  1. W miejscu login as wpisujemy login do naszego konta na shellu
  2. Password chyba nie trzeba tłumaczyć :)
  3. Zatwierdzamy klawiszem ENTER
  4. Jeżeli wszystko poszło dobrze, zalogowałeś sie poprawnie i twoim oczom ukazał się ‘znak zachęty’… to możesz zamknąć połączenie poleceniem exit.

4. Ok, sprawę konfiguracji oraz próbnego połączenia mamy za sobą, czas na konfigurację Tunelu SSH.

  1. Ponownie uruchamiamy aplikację Putty.
  2. Po lewej stronie (1) klikamy na zakładkę SSH.
  3. Zaznaczamy opcję “Enable Compression(2)

W tej chwili ustawiliśmy opcję kompresowania danych, to właśnie ta opcja zaoszczędza nasze ‘cenne kilobajty’ :)

5. Skoro mamy już skonfigurowane połączenie oraz ustawioną opcję kompresji danych, możemy przejść do konfiguracji aplikacji które ‘przepuścimy’ przez nasz tunel.

Jak już wcześniej wspominałem, jako że Gadu-Gadu (bez dodatków) nie ma możliwości wyboru własnego serwera, skorzystamy z multi-komunikatora jakim jest Miranda-IM .

Zaczniemy od konfiguracji tunelu dla Mirandy w Putty.

  1. W zakładce SSH (1) klikamy na + , zostanie rozwinięta lista, Nas interesuje tylko i wyłącznie opcja “Tunnels” (2), klikamy na tą zakładkę. Naszym oczom ukażą się pola tekstowa oraz wyboru. W pole (3) wpisujemy port źródła - 8074. W polu (5) “Destination”, wpisujemy adres serwera gadu-gadu, w naszym przypadku będzie to: 217.17.41.93:8074
  2. Ostatnim krokiem jest kliknięcie przycisku ADD.

6. Właśnie postawiliśmy tunel między naszym komputerem a siecią gadu-gadu! Przejdźmy do konfiguracji Mirandy-IM do prawidłowego działania z naszym tunelem.

  1. Wchodzimy na oficjalny, polski support Mirandy-IM, >KLIK< Klikamy “Download”
  2. Po ściągnięciu Mirandy przystępujemy do jej instalacji (nie będę jej opisywał ponieważ opiera się ona głównie na klikaniu “Dalej” :) ) Myślę że każdy sobie z tym poradzi.
  3. Jeżeli instalacja przebiegła pomyślnie, możemy uruchomić Mirandę, naszym oczom powino się ukazać takie oto okienko:

  1. Szkoda nam czasu na wpatrywanie się w puste okienko.. więc przystępujemy do konfiguracji Mirandy.
  2. W lewym górnym rogu okienka klikamy na ikonkę podobną do literki M / Korony (wszystko zależy jak sobie to wyobrazisz :) ) Twoim oczom powinna się ukazać lista, klikamy na “Opcje“. Jeżeli wszystko poszło zgodnie z planem, powinieneś ujrzeć:

  1. Jako że jesteśmy sprytni? :) Na dole okna zaznaczamy opcję “Pokaż opcje zaawansowane” Odszukujemy zakładkę Sieć a w niej zakładkę Gadu-Gadu, klikamy na nią a w niej :P Na górze Zaawansowane.
  2. Kolejne czynności są banalnie proste… z pierwszego dużego pola usuwamy wszystkie adresy IP, po usunięciu wpisujemy swój (lokalny prowadzący do tunelu) czyli: 127.0.0.1:8074
  3. Warto też odznaczyć opcję “Używaj połączeń bezpośrednich” ponieważ zostawiając ta opcję więcej stracimy niż zaoszczędzimy (opcja ta odpowiada za odbieranie plików od użytkowników)
  4. Klikamy Zastosuj. Możemy wyjść z konfiguracji Mirandy.
  5. Wracamy do punktu 3 w artykule, czyli do łączenia z SSH. Tak jak jest to tam opisane… łączymy się z naszym serwerem SSH. Właśnie włączyłeś tunel pomiędzy Mirandą a serwerem Gadu-Gadu! Teraz wracasz do Mirandy i klikasz Dostępny. Jeżeli słoneczko zmieni kolor na żółty to możesz sobie pogratulować. Działa! Prawda że proste?
  6. Równie dobrze możemy tak samo zrobić z innymi aplikacjami, niestety nie opiszę tego w tym artykule bo był by on za bardzo rozległy… a miało być prosto! Jeżeli będziesz miał problemy z konfiguracją lub chcesz zapytać jak skonfigurować inny program do pracy z tunelem to zapraszam do pisania komentarzy! Odpowiem 100-u-procentowo :)

Jeżeli Mirandy-IM nie przypadła ci do gustu a chciałbyś jednak używać GG to proponuję zainteresować się programem GG Serwer Changer 5.0 Po przeczytaniu tego artykułu powinieneś się domyślić jak go skonfigurować, jeżeli nie to jak zawsze zapraszam do komentowania!Jeżeli coś namotałem lub popełniłem błędy ortograficzne, językowe to bardzo przepraszam. Bardzo ‘roztrzepany’ ze mnie człowiek :) Pozdrawiam, Maciek.

Pozdro dla całej ekipy www.bez-kabli.pl  < źródło mojej inspiracji :)

banner

12 Komentarzy »

  1. A nie łatwiej ustawić port na DYNAMIC i tunelować tym wszystko co obsługuje SOCKS ? Np. Firefox dobrze działa na socks (nie trzeba stawiać Squida na remote-hoście):

    about:config i network.proxy.socks_remote_dns TRUE

  2. Szczerze mówiąc nie wiedziałem o tym ;) Jeżeli możesz, to proszę abyś napisał o tym trochę więcej. Pozdro

  3. Czy w PuTTY Configuration -> [SSH] [Auth] -> podawałeś nazwę pliku .PPK ze swoim kluczem prywatnym?

  4. Nie :)

  5. W PuTTY Configuration, [SSH] zaznaczyłem [Enable compression],
    Utworzyłem Dynamic SOCKS tunnel na porcie 8989,(bez Destination),
    Nie używałem kluczy szyfrujących, tylko użytkownik i hasło,
    Połączyłem się z serwerem na którym mam konto shellowe,
    putty.exe -load konfiguracja -l uzytkownik -pw haslo
    W Event Log, pisze: Server Version: SSH-2.0-OpenSSH_4.6
    W Firefox, [manual proxy configuration], podałem tylko:
    SOCKS Host: 127.0.0.1, Port: 8989, [SOCKS v4],
    No Proxy for: localhost, 127.0.0.1, 192.168.1.0/24
    W google poszukałem filetype:txt czyli plików które powinny
    się bardzo dobrze kompresować, wybrałem plik:
    mailman.rfc-editor.org/pipermail/rfc-interest/2004-March.txt
    W LiveHTTPHeaders, rozmiar oryginalny: Content-Length: 48327
    Natomiast według licznika na porcie COM modemu: 54258 bajtów,
    Czyli żadnej kompresji! Ten narzut 5931 bajtów był u mnie
    obecny także przy połączeniu bezpośrednim - opakowanie TCP/IP.
    Powtórzyłem potem ten test także z wyłączoną opcją
    [Enable pompression] i rezultat jest ten sam niestety.
    Wobec tego czy mógłbyś zrobić taki test u siebie? Podejrzewam
    że opcja kompresji w SSH jest przewidziana tylko w przypadku
    użycia kluczy szyfrujących albo to ja mam pecha i akurat ten
    OpenSSH jest tak niekorzystnie skonfigurowany przez admina.

  6. Przed chwilą utworzyłem analogiczny jak poprzednio tunel
    ale tym razem połączenie jest szyfrowane z użyciem klucza
    wygenerowanego w puttygen.exe, część publiczną klucza
    skopiowaną z okna puttygen wkleiłem do pliku pubkey i
    wysłałem go do mojego katalogu domowego na serwer.com:
    pscp.exe -scp -load konfiguracja pubkey uzytkownik@serwer.com:pubkey
    Potem postępowałem według opisu: how_to_set_up_ssh_keys_with_putty

    Niestety znów nie zaobserwowałem kompresji przesyłanych
    danych, czyli muszę szukać innego konta shellowego.
    A niech to…

  7. Widzę że próbowałeś wszystkiego… najwidoczniej twój usługodawca coś poblokował. Jeżeli chcesz to udostępnię Ci konto Shellowe u siebie na serwerze. Jeżeli chcesz skorzystać to odezwij się w komentarzach lub na GG: 405528 :) Pozdrawiam

  8. Dzięki wielkie ;] wyślij mi hostname:port/login/pass
    na e-mail który podaję przy wpisywaniu komentarzy.
    Pozdrawiam.

  9. Zauważyłem jedną niepokojącą właściwość połączeń poprzez tunel ssh.
    Otóż Firefox nie zapisuje większości tak ściągniętych stron w cache dyskowym!
    Na pewno nie ma to związku z nagłówkami http: Cache-Control: no-cache
    ani Pragma: no-cache, bo te nagłówki zawsze usuwa mi Privoxy.
    Poza tym nawet odpowiedzi z google nie były zapisywane w cache dyskowym
    pomimo tego że mają oryginalny nagłówek Cache-Control: private.
    Pamiętam że cache’owane były za to takie strony które już poprzednio miały wpis w cache.
    Tylko dlaczego Firefox wogóle rozróżnia połączenia bezpośrednie i SOCKS pomimo tego
    że w konfiguracji Firefox zawsze podawałem tak naprawdę tylko lokalny http proxy - Privoxy.

    Wczoraj wieczorem, bardzo możliwe że na skutek używania tunelu ssh,
    zauważyłem zniszczenie cache dyskowego Firefox. Po wpisaniu adresu:
    about:cache?device=disk wyświetla się tylko pusta strona, żadnych starych wpisów.
    Nie było żadnego crashu Firefoxa, zresztą wtedy usunąłby on wszystkie
    pliki _CACHE_* z katalogu /Cache, dlatego myślę że mój cache “został zgwałcony” :/
    ( ha ha, tak oto rodzą się nowe terminy informatyczne )
    Podejrzewam że zawinił browser.cache.disk_cache_ssl=true, bo pamiętam że
    akurat w sesji poprzedzającej “zgwałcenie cache” wchodziłem na strony https.

    W związku z powyższym i niestety, itp., jestem zmuszony zrezygnować z używania
    Firefox + tunel ssh do czasu gdy znajdę konkretne rozwiązanie dla tego problemu.

  10. Dobro powraca - mam nadzieje,
    a czasem trzeba strzelić browca i po prostu odpuścić.

  11. Konto poszło na mail. Pozdrawiam

  12. Zagadka niezapisywania stron w cache dyskowym Firefox rozwiązała się.
    Firefox niezapisywał stron w cache dyskowym gdy łączyłem się poprzez
    tunel ssh ale przy połączeniu bezpośrednim wszystko było w porządku.
    Winny temu okazał się Traffic Compressor.
    Pomimo tego że nie używałem TC już od kilku tygodni to jednak jedna
    z zainstalowanych przez niego bibliotek (TCompLsp.dll) była nadal
    zarejetrowana w systemie jako Layered Service Provider dla Winsock2.
    Problem z cache ustąpił po użyciu uninstall.exe TrafficCompressor’a.

    Za pomocą DumpLsp lub AVG Anti-Spyware można sprawdzić jacy pośrednicy LSP są w systemie.
    A jeśli brak odpowiedniego deinstalatora LSP to możemy użyć LSP-Fix oraz HijackThis.

Dodaj komentarz