Tag: howto

Opublikowane w

Jak sprawdzić IP?

Ten wpis to takie małe HOWTO i przegląd zagadnienia dla mniej zaawansowanych. Zagadnienie ogólne to jak sprawdzić IP? Można to rozumieć przynajmniej na dwa sposoby. Pierwszy to z jakim IP jesteśmy widoczni w sieci, drugi to jakie IP ma ustawiony mój komputer.

Sprawdzenie IP widocznego w Internecie

Generalnie, jeśli po drodze nie ma jakiejś zaawansowanej magii typu serwer proxy czy kreatywne przekierowania lub równie kreatywny routing, to do wszystkich serwisów w Internecie łączymy się z takiego samego IP. Z jakiego? Najprościej sprawdzić w logach dowolnego serwera, jeśli taki posiadamy. Jeśli nie, wystarczy skorzystać z którejś ze stron do sprawdzania IP:

Ostatnia ze stron umożliwia również sprawdzanie w sposób automatyczny, przyjazny programistom raz na 5 minut (szczegóły w FAQ na stronie).

Spawdzanie swojego IP pod Linuksem

Konfiguracja sieci w Debianie i Ubuntu znajduje się w /etc/network/interfaces, ale niekoniecznie znajdziemy tam nasz adres IP, szczególnie, jeśli jest on pobierany z serwera DHCP. Bieżącą, działąjącą konfigurację sieci z przydzielonymi adresami pozwoli nam za to zobaczyć polecenie ifconfig (w Debinanie przez zwykłego użytkownika należy wywołać z pełną ścieżką, czyli /sbin/ifconfig). Inna metoda, o ile mamy zainstalowany pakiet iproute, to wpisanie ip address. Albo, krócej ip a.

Sprawdzanie IP komputera pod Windows

Metoda najdoskonalsza, czy w wierszu poleceń. Wybieramy Start -> Uruchom wpisujemy cmd i naciskamy klawisz Enter. Pojawi się czarne okno w którym możemy pisać. Wpisujemy ipconfig i naciskamy enter. Jeśli chcemy więcej danych, wpisujemy ipconfig /all (znowu zatwierdzając enterem). Dla porządku jeszcze niezawodne polecenie diagnozujące sieć opartą o DHCP – ipconfig /renew. Na pewno działa pod Windows 2000, Windows XP, Vistą i zapewne pod Windows 7 (tego ostatniego nie sprawdzałem).

Sprawdzanie IP dla macos

Jak sprawdzić IP komputera z firmy Apple? W przypadku macos jest podobnie jak dla Linuksa. W terminalu wpisujemy ifconfig i gotowe.

Sprawdzanie działania IPv6

Trzy strony pozwalające na sprawdzanie, czy nasz komputer obsługuje łączność, albo inaczej czy działa IPv6. Każda ma swoje wady i zalety i sprawdza trochę co innego.

Działanie IPv6 można też sprawdzić poprzez ping ipv6.google.com.

Opublikowane w

Monitoring Tora w konsoli – howto.

Jak wiadomo m.in. z poprzedniego wpisu, prowadzę węzeł Tora. Bez połączeń wychodzących, czyli robię tylko za żuczka dokładającego jeden hop w ścieżce w celu zwiększenia anonimowości korzystających z tego programu. Od pewnego czasu miałem wrażenie, że jedyne, co robi mój Tor, to zajmuje pamięć (ponad 30% na biednym Dockstarze). Nie robiłem żadnych dokładnych statystyk, po prostu obserwowałem ilość ruchu na interfejsach, ale wyglądało, że jest mniej, niż kiedyś.

Postanowiłem sprawdzić, co się dzieje w rzeczywistości. Już kiedyś widziałem, że jest projekt arm czyli anonymizing relay monitor, ale wtedy nie było pakietów w Debianie, więc nie instalowałem, a pozwala on na znacznie więcej, niż tylko obejrzenie ilości ruchu, więc postanowiłem zainstalować arm.

W tej chwili paczka tor-arm jest dostępna w Debianie unstable (na stable instaluje się czysto), więc doinstalowałem ją (wajig install tor-arm). Samo uruchomienie (wpisanie arm) nic nie dało (używa domyślnej konfiguracji), więc po pierwsze, skopiowałem domyślną konfigurację (położenie w Debianie nieco inne niż podawane w manualu):

zcat /usr/share/doc/tor-arm/armrc.sample.gz > .arm/armrc

Nadal nic. Kolejna sprawa, to uruchomienie portu do kontroli w samym Torze, czyli dodanie w configu opcji:

ControlPort 9051

Po ponownym uruchomieniu arm jak najbardziej się połączył, ale ostrzega, że port do kontroli jest otwarty. Co prawda maszynka jest firewallowana, ale wypadałoby dodać hasło do zarządzania. Nie jest to trywialne i znalezienie zajęło mi dłuższą chwilę (chociaż jest w dokumentacji), więc opiszę. Najpierw generujemy hash hasła:

tor --hash-password jakieshaslo 

Otrzymujemy coś w stylu ciągu

16:2CCAAB2DEEB082CD60610B3BE6A0FF2A90EEFC92AD434C9C8CBFA42B0B

Następnie w konfiguracji Tora dodajemy linię

HashedControlPassword 16:2CCAAB2DEEB082CD60610B3BE6A0FF2A90EEFC92AD434C9C8CBFA42B0B

i restartujemy Tora (/etc/init.d/tor restart). Na koniec edytujemy ~.arm/armrc i uzupełniamy linię z startup.controlPassword, by miała postać:

startup.controlPassword jakieshaslo

Po zmianach okazało się, że miałem nosa i faktycznie niewiele się dzieje. Nawet bardzo niewiele. Praktycznie nic. Ponieważ kiedyś ruchu było więcej, postanowiłem sprawdzić, czy winnym nie jest ustawienie węzła jako bridge node. Bingo! Po zmianie od razu jest więcej ruchu. Zatem w chwili obecnej mój konfig Tora wygląda następująco:

ControlPort 9051
RelayBandwidthRate 20 KBytes
RelayBandwidthBurst 30 KBytes
ExitPolicy reject *:* # no exits allowed
ORPort 443
HashedControlPassword 16:2CCAAB2DEEB082CD60610B3BE6A0FF2A90EEFC92AD434C9C8CBFA42B0B

UPDATE: Przy okazji wygląda, że wyłączając tryb bridge node upiekłem dwie pieczenie na jednym ogniu. Po 16 godzinach zużycie pamięci RAM przez Tor wynosi ledwie 9%, zamiast wspomnianych 30%. Czyżby jakiś bug związany z trybem bridge? W każdym razie średni ruch upload i download teraz to po 50 Kbps, zużycie pamięci, które mnie trochę bolało mniejsze. Jednym słowem: lubię to! 😉

Opublikowane w

Zalany telefon – naprawa.

Chcąc nie chcąc udało mi się zdobyć nową sprawność na wyjeździe – ratowanie zalanego telefonu. Okazało się, że nie wszystkie plecaki są wodoszczelne. Ten, który pożyczyłem wykazał się praktycznie zerową ochroną przed deszczem. W przeciwieństwie do firmowego „laptopowego” plecaka, który zaskakująco dobrze chroni przed deszczem i do którego przywykłem.

W każdym razie deszcz był spory i po otwarciu kieszonki z kluczami od auta i telefonem okazało się, że w środku jest bagno telefon jest totalnie zalany. I to zalany nie tak trochę, że wilgotny, tylko praktycznie pływa i kapie z niego. Co prawda wyglądał, że działa, ale już wyświetlał, że włączone są jakieś dziwne opcje zestaw słuchawkowy, którego przecież nie mam.

Co prawda moja Nokia 3110c ma już 3 lata (ależ ten czas leci…), czyli telefon jest stary i należało by go wymienić, ale w sumie działał i prawie wystarcza. W zasadzie do pełni szczęścia brakuje mi – najchętniej wbudowanego – GPS, bo ostatecznie nie kupiłem zewnętrznego i minimalnie większego ekranu do przeglądania Internetu.

Po paru dniach wygląda, że zalanie telefonu nie zaszkodziło mu, więc może komuś też się opis przyda (za efekty nie ręczę, mi pomogło):

  • Wyłączenie telefonu i wyjęcie baterii (natychmiast po stwierdzeniu zalania).
  • Wyjęcie wszystkiego, co daje się wyjąć (karta SIM, karta microSD, jakbym mógł, to bym trochę bardziej rozebrał go, ale nie miałem ani instrukcji, ani narzędzi).
  • Osuszenie wszystkiego z osobna papierem toaletowym.
  • Wydmuchanie wody ze szczelin, dalsze osuszanie papierem.
  • 20-30 min suszenia w różnych pozycjach suszarką w takiej odległości, by się nie przegrzewał, ale żeby był wyraźnie ciepły.
  • Jak przestaną być widoczne ślady wilgoci (ekran itp.), 2,5-3h leżakowania telefonu na słońcu i wietrze (pewnie niezalecane przez producenta).

Po tym włączyłem telefon i okazało się, że na tyle, na ile używałem, funkcjonuje normalnie. I w sumie mam ambiwalentne uczucia. Z jednej strony fajnie, że uratowany, z drugiej nie ma pretekstu do kupna czegoś z Androidem.

UPDATE: Mimo pesymistycznej prognozy z komentarza, telefon ma się dobrze. Głośnik, mikrofon, klawiatura – bez zarzutu po około pięciu miesiącach blisko roku.