vermin.eu.org

Podczas troubleshootingu (jak to by było po polsku? ;-)) łączności z siecią trzeba było wykonać test blackhole routers - czyli routerków, które nie puszczają pakietów o okreslonej wielkości przez sieć. Ponieważ polecenia ping i komunikaty z systemów Windows i Linux mocno się różnią, gwoli przypomnienia dorzucę (opierając się na IPku WP.pl):

To polecenie nakazuje nie fragmentować pakietów i ustawia ich realnąwielkość na 1500 - czylitypową dla pakietów ethernet. Jeśli w linuksie nie dostaniemy żadnej informacji, a w Windows Pakiet musi być podzielony na fragmenty, ale ustawiono opcję DF, to oznacza, że niestety, po drodze coś nie bangla.

Jak sobie z tym poradzić? Dla systemów rodem z Redmond polecam odpowiedni artykuł z KB, zaś dla linuksa wystarczy polecenie: ifconfig i odpowiednie MTU

Przyszło mi musieć posiadać dwa rodzaje pakietów na jednym systemie - ze stabilnego etcha i lenny’ego. Sprawa wydaje się banalna - wpis w /etc/sources.list

oraz w apt.conf

Po ty wystarczy dać aptitude update… żeby otrzymać to:

A wystarczy w /etc/apt/apt.conf dodać np.

i już działa

Byłem i zakupiłem certyfikat typu wildcard dla jednej z administrowanych domen. Taki to wymóg pojawił się w obsługiwanej przeze mnie firmie, coby korzystający z aplikacji webowych klienci tejże bezpieczniej się czuli wymieniając dane z serwerem. Nie jest to certyfikat z “zielonym paskiem” (swoją drogą jest to niezły absurd jako wysoko płatne bezpieczeństwo, szczególnie jak ktoś ma oskórkowanego FF/IE/Opera/whatever…) Kupiłem go od firmy polskiej, coby obce imperialistyczne świnie wolnorynkowe elementy ze znaczącym udziałem kapitału zagranicznego nie pasły się kosztem firmy.

Generacja certyfikatu oczywiście za pomocą paczki openssl - prosta komenda openssl req -new -key server.key -out server.csr i już mamy żądanie, które musimy wrzucić do Centrum Certyfikującego. Jak na razie wszystko fajnie i działa - abstrahując od tego, że oważ firma nie za bardzo przygotowana była ze swoim systemem sprzedaży webowej do certyfikatów typu wildcard i chciała wysyłać mi maila na adres webmaster@*.firma.com.pl albo sprawdzać siakieś pliki na takowymż serwerze. Niemniej pomoc ichnia zadziałała szybko i poprawnie i bezproblemowo certyfikat ów dostatałem wraz z instrukcjami jak to go wgrać do mego apache/iis/whatever_web_server. Miłe.

Niestety mój apache, (w przeciwieństwie do IIS, który łyknął wszystko bez słowa), stwierdził w zasadzie, że on nie obsługuje SSL pomimo całej odprawionej w konfiguracji virtual hosta magii mówiącej wprost, że SSL działać ma, że klucze i certyfikaty są (zweryfikowane) w odpowiednich miejscach:

Zgłaszał to na dodatek tak uprzejmie, że rzucał kodem nie do odnalezienia, informując poprzez FF/IE, że “blah.firma.com.pl wysłał nieprawidłowy lub niespodziewany komunikat. Kod błędu: -12263″. Wredne to o tyle, że włożenie w google “-12263″ zwróciło mi 0 wyników… Niemniej problem okazał się absurdalny w sensie swojej prostoty. Otóż (błędnie) nie miałem podefiniowanych wirtualnych hostów jako stojących na odpowiednich portach, tj. brakowało mi w odpowiedniej linijce informacji o porcie:

Dokonana w ten sposób separacja pomiędzy hostami szyfrowanymi (443) i nieszyfrowanymi (80) załatwiła sprawę… ale nie do końca. W końcu klient chciał coby komunikacja zachodziła w sposób bezpieczny. Ponieważ obciążenia serwera średniomałe w pliku odpowiadającym za port 80 dorzuciłem co następuje:

No i śmiga, loguje gdzie trza co trza i jeszcze spełnia założenia firmy. Ufff.

P.S.
Oczywiście wszystko to jest przy założeniu, że wcześniej wykonało się takie magiczne komendy w Debianie, które powrzucały w /etc/apache2/mods-enabled i /etc/apache2/sites-enabled odpowiednie moduły i site’y. Wystarczyło w tym celu wykonać sekwencję:

i sprawdzić czy wszystko działa za pomocą apache2ctl -t Ale to przecież oczywiste…

Nie jest to może super nowatorskie, niemniej ogólne wrażenie jest bardzo przyjemne
“How long have you been standing there?”

Źródło: Marcoos

Łącząc się z hostem poprzez SSH z nowego komputera, jesteśmy pytani o to, czy jesteśmy pewni z kim się łączymy. To pytanie, to raptem odcisk klucza publicznego serwera, który musimy zweryfikować.

Osobiście zawsze “zarządzałem” kluczami poprzez stronę WWW na której publikowałem odciski kluczy. Niemniej artykuł na Debian Administration, a dokładnie komentarze do niego pokazały mi ciekawą drogę.

Jak podaje RFC 4255, wystarczy dodać pewien typ rekordu do opisu strefy oraz uruchomić ssh z odpowiednią opcją aby łatwo zweryfikować drugą stronę połączenia. Do szukanej domeny (np. example.com) wystarczy dodać rekord SSHFP zawierający klucz (szczegółowa definicja).
Wygląda to mniej więcej następująco (RSA potem DSA):

Te linijki można wygenerować za pomocą komend:
ssh-keygen -r example.com -f /etc/ssh/ssh_host_rsa_key
ssh-keygen -r example.com -f /etc/ssh/ssh_host_dsa_key
lub dla starszej wersji bind
ssh-keygen -r example.com -f /etc/ssh/ssh_host_rsa_key -g
ssh-keygen -r example.com -f /etc/ssh/ssh_host_dsa_key -g

Żeby się połączyć wystarczy wydać komendę ssh example.com -o “VerifyHostKeyDNS=yes” (putty na razie nie ma opcji pozwalającej na weryfikację klucza zapytaniami DNS).

Chociaż jest to mało prawdopodobne, to oczywiście warto pamiętać, że jeśli ktoś zmanipuluje rekordy strefy (szczególnie, jeśli ułatwiamy sobie sprawę i trzymamy wszystkie informacje jako klucze swojej pod domeny, np. serwerX.moja_domena.com) to jesteśmy niestety mocno wystawieni na atak typu man-in-the-middle, więc warto przemyśleć swoją strategię postępowania (dodatkowa autoryzacja poprzez klucze dostępu, wpisy SSHFP per host per domain, weryfikacja rekordów od czasu do czasu).

Skoro wspomnieliśmy już ogólnie o tym cóż to to monitorowanie jest, warto by wszystko skonfigurować, żeby móc cieszyć nasze oczy pięknymi grafami/tabelkami/wykresami czy też jakąkolwiek inną reprezentacją zbieranych danych.

1. Instalacja
Przede wszystkim musimy zainstalować oprogramowanie agentów. W wypadku systemów Windows ścieżka jest prosta:
Panel Sterowania -> Dodaj lub usuń programy -> Składniki systemu Windows -> Narzędzia zarządzania i monitorowania. Po chwili mamy już zainstalowanego agenta.
W Debianie sytuacja jest także prosta. Wystarczy zainstalować paczkę snmpd (aptitude install snmpd). Dodatkowo przydadzą się nam narzędzia z paczki snmp (aptitude install snmp).
Pod Windows, jeśli nie chce nam się szukać, ściągąc i kompilować net-snmp tools z którego to pakietu pochodzi wykorzystywane w dalszej części narzędzie snmpwalk, warto ściągnąć Windows Management Instrumentation (WMI) SNMP Provider, który pozwoli na odpytywanie SNMP z poziomu WMI.

2. Weryfikacja
W systemie Windows zweryfikujemy działanie SNMP poprzez uruchomienie MMC Usługi (services.msc) i sprawdzenie czy działa serwis Usługa SNMP oraz (ewentualnie) Usługa SNMP Trap. Jest to też ciekawostka, ponieważ jest to jedyna (znana mi) usługa, która całą swoją konfigurację ma właśnie w tym miejscu. Wydawałoby się, że warto jej poświęcić chociaż małe MMC, a tu nic.
W systemie Debian wystarczy oczywiście wydać komendę ps `cat /var/run/snmpd.pid`, dzięki której zobaczymy, czy demon SNMP działa. Daemon tu jest agentem a nie serwerem, o czym warto pamiętać.

OK, może i SNMP działa, ale czy coś do nas powie? Czy odpowie na na nasze wołania? Wystarczy wydanie komendy snmpwalk -v 1 -c public localhost żeby ekran (jeśli wszystko jest ok) pokrył się tonami kodu, wyglądającego mniej więcej tak:

Te kody swoją droga coś znaczą - pierwsza pozycja to tzw. MIB, czyli nie “faceci w czerni”, ale nazwa danej (tu w postaci numerycznej), np. naszego czujnika temperatury albo pokrętła. Część po znaku równości to jak łatwo się domyśleć, aktualna wartość tegoż MIBa. MIBy można podawać za pomocą cyfrowego łańcucha znaków… albo, jeśli mamy coś co to ładnie przetłumaczy (czyli zbiory tekstowe z opisem MIBów), możemy zapytać się ładniej - snmpwalk -v 1 -M. -c public localhost IP-MIB::ipAdEntIfIndex co poda nam indeksy interfejsów w systemie.
Sama komenda ma strukturę snmpwalk -v wersja_protokołu -M katalog_z_MIBami -c community_name hostname MIB.

3. Konfiguracja
Domyślnie SNMP działa na lokalnym serwerze (localhost) z communityname public dla odczytu i private dla odczytu/zapisu (tak, za pomocą SNMP można także sterować urządzeniem!). Windows ma tylko community public i przyjmuje połączenia od dowolnego hosta. Warto zmienić ciut te wartości oraz podać, gdzie nasz sprzęt się znajduje (jeśli trochę go mamy). Odpowiednie wartości wpiszemy we właściwościach usługi (services.msc -> usługa SNMP -> własciwości: zakładka Agent i Zabezpieczenia) lub w /etc/snmp/snmpd.conf.
Tutaj także możemy zmodyfikować jakiego rodzaju informacje agent SNMP będzie monitorować (sieć, procesor, dyski, etc.) Gama możliwości jest naprawdę duża.

W systemie Windows możemy poza standardowymi parametrami odpytać następujące serwisy:

• WINS
• DHCP
• IIS
• LAN Manager
• RRAS (Routing and remote access)
• IAS
• liczniki System Monitora (wszystkie liczniki wydajności TCP/IP i usług na nim opartych)

Z czego sterować można IAS, Lan Managerem i WINSem.

4. Zarządca
Było zarządców wielu, ale żaden z nich nie śmiał zagrać przy… Cóż, ciężko powiedzieć. W zasadzie to HP OpenView narzuca się samo, niemniej my mamy mniejsze potrzeby. Chcemy monitorować. Chcemy żeby było prosto, łatwo i darmo. Chcemy MRTG (tak, wiem jest też Cacti - ale ono jest za bardzo rozbudowane na początek).
MTRG można zainstalować pod Windows oraz pod Linuxem. Program odpytuje agenta (agentów) w zadanych interwałach czasu (cron/at), zbiera dane i przetwarza je na postać graficzno -tekstową (HTML + obrazki PNG). Konfiguracja wygląda tak samo pod obydwoma systemami. Należy podać mu skąd ma pobrać dane, jakie MIBy nas interesują, podać parametry interfejsu, czyli tak naprawdę wytyczne odnośnie rysowania obrazka i już.
Na dodatek MRTG ma przyjemne “wizardy” tworzące samoczynnie konfigurację:

tworzy podstawowy plik konfiguracyjny dla społeczności public na localhost informując że dane będą w katalogu WorkDir

stworzy dla nas odpowiednie pliki
Teraz tylko parokrotne uruchomienie mrtg (mrtg /etc/mrtg/MartaG.cfg) tworzące resztę wymaganych plików uwieńczy naszą pracę sukcesem. Podstawowa konfiguracja zakończona i możemy popatrzeć jak to wszystko wygląda.

Należy pamiętać, że aby odczytać te dane na stacji administratorskiej to albo skonfigurujemy poprawnie IISa pod Windows lub Apache pod Linuxem, albo postawimy jakiś mały dedykowany serwer, jak np. microhttp, który idealnie sprawdzi nam się do rzadkiego publikowania statycznych informacji (chyba, że planujemy inne obciążenie tegoż serwisu - ale po co?).

Do czego właściwie potrzebne to wszystko? Żeby móc stworzyć własny, rozproszony SMS dla ubogich. Jakby nie można było kupić licencji… No, ale ten system daje także rzeczy, których wprost z SMSa wyciągnąć się nie da, a poznać je warto - jak chociażby lista aktualnych połączeń z danego komputera (stos TCP/IP), że nie wspomnę o podstawowym zadaniu MRTG, czyli monitorowaniu urządzeń sieciowych.

Dodatki: Narzędzia SNMP dla Windows.

Wyobraź sobie urządzenie, która ma ileś tam czujników - np. kaloryfer z termoregulacją. Masz odczyt temperatury (wartość1) i pokrętło (wartość2). Chcielibyśmy (jeśli kaloryfer to umożliwia) pobierać i monitorować urządzeniem zewnętrznym wartość tej temperatury (wartość1), a także ustawienie pokrętła (wartość2). Jak to zrobić (w dziedzinie komputerów)?

Monitorowanie sprzętu jest ważne - na przykład dlatego, że pozwala wykryć sytuacje prowadzące do nieodpowiednich zachowań. Zaczynając od tak banalnych rzeczy jak wysycenie pewnych parametrów (np. mierzenie poziomu zajętości dysku, badanie obciążenia procesora, stronicowanie pamięci i inne wąskie gardła), do zagadnień bezpieczeństwa (tu dla odmiany monitorowania bramki internetowej, co pozwoli nam stwierdzić, czy ktoś przypadkiem nie wykorzystuje naszego łącza pomimo (braku) zabezpieczeń w czasie teoretycznego braku aktywności). Monitorować można na wiele różnych sposobów, niemniej warto zainteresować się jednym z nich, dostępnym zarówno w systemach Windows i Linux - a przede wszystkim w dużej ilości urządzeń zewnętrznych (w szczególności sieciowych).

Do monitorowania wykorzystuje się protokół SNMP. Ten prosty protokół jest szeroko rozpowszechniony i doczekał się już swojej trzeciej wersji. Niemniej ponieważ w użyciu są przede wszystkim wersje 1 i 2, skupimy się na nich - żeby to zaczęło działać.

Do podstawowego działania każde monitorowane urządzenie powinno mieć program (agenta), który będzie pobierał stan jakiegoś wewnętrznego rejestru (np. przepływność interfejsu sieciowego) a następnie, odpytany przez zarządcę, podawał mu te dane. Agent może być także ciut proaktywny i w wypadku zadziałania zdefiniowanego warunku wysyłać do zarządcy odpowiednią informację (zwaną trap/pułapką). Do poprawnego działania w środowisku sieciowym potrzebne będą porty TCP 161 (odpytywanie) i 162 (pułapki). Przyda się jeszcze tzw. community name, czyli nazwa o którą będziemy odpytywać nasze urządzenie.

Na boku: Widać tu wyraźnie, że skoro jedynym zabezpieczeniem jest znajomość community name musimy przedsięwziąć inne środki bezpieczeństwa… lub wdrożyć wersję 3 protokołu SNMP.

OK - tyle teorii wystarczy. Jak to wszystko zrobić nie dopłacając? O tym w następnym artykule.

Przy tak dużej zmianie i wyborze nowego systemu warto przemyśleć kilka spraw. Pomoże w tym ten komiks.
Zawsze też można się zastanowić nad inną, niemniej fajną

Cóż - aktualizacja systemu, szczególnie, do jakby nie było jeszcze wersji testowej, powoduje pewne problemy. W tym wypadku niestety posiadanie karty działającej ze sterownikiem sundance 1.1 z jajka 2.6.18 w wypadku zainstalowania snmpd, który z automatu odpytuje to urządzenie co 30 sekund powoduje zrzut czegoś w formacie

i to dla każdej z aktywnych kart składających się na to urządzenie.

Podejrzewam, ponieważ nie towarzyszą temu żadne komunikaty o wyłączaniu komunikacji, oopsy kernela, czy inne dziwne teksty (%s: Something Wicked happened! %4.4x.), że są to informacje typu debug, które zostały wkompilowane w kernel. Niestety serwer jest zdalny i nie za bardzo mogę wyłączyć tą sieciówkę, przez którą idzie m.in. cała komunikacja ze światem zewnętrznym… a pewnie wystarczy zmiana parametrów przy ładowaniu tego modułu Cóż, będzie go trzeba w wolnej chwili przeładować albo czekać, że wraz z wersją 2.6.19 pojawi się w Debianie sterownik w wersji 1.2 (i wtedy przeładujemy system…)

[l8r that day] Po przejrzeniu kodu i stron…

Swoją drogą ciekawe jest, że RH podaje, że ten moduł nie przyjmuje żadnych parametrów, a w źródle można znaleźć takie coś:

co zresztą pokazuje modinfo. Dalsze śledztwo pokazało też, że za całe zamieszanie odpowiedzialna jest procedura netdev_ioctl, która ot tak sobie wypluwa te wszystkie informacje, przy debug=0. Raczej przyjdzie ręcznie wywalić ten kod z modułu…

Istnieje w sieci komputer o nazwie netbios “23″. Niby nic takiego, ale… próba połączenia się z nim jednego z komputerów poprzez otoczenie sieciowe generuje w logach IPSa dziwne zdarzenie: “martian destination 0.0.0.23 from 192.168.10.141″. Co ciekawe znajduje się także właściwy adres IP i komputer rozpoczynający połączenie w końcu się połączy… ale zastanawia mnie, czy nadanie jako nazwy komputera adresu IP w postaci DWORD a na tym właśnie adresie otworzenie udziału nie spowodowałoby de facto przekierowania zapytania pierwotnego na tą drugą (DWORD) maszynę?

Posiadając wiele interfejsów w systemie (np. dzięki wieloportowej karcie… lub kilku takim zabawkom) warto ponazywać je ciut inaczej niż domyślne w Linuksach ethX. Przydaje się to także w momencie, gdy czasem dodajemy lub zabieramy kartę z komputera przez co zmienia się numeracja interfejsów… i nagle ginie wyjście na świat, a my musimy zgadywać (dmesg), który eth za to odpowiada.
Przede wszystkim pomyślmy jak się ma ten interfejs nazywać - załóżmy, że iface do sieci nazwiemy world zaś iface do sieci wewnętrznej intranet (jakiż jestem orginalny…). Najpierw musimy wyedytować pliki odpowiedzialne za konfigurację sieci (w Debianie /etc/network/interfaces) i zamienić tam ethX na nasze nowe nazwy. Następnie otwieramy, lub, co bardziej prawdopodobne, tworzymy plik /etc/mactab, gdzie tworzymy wpisy typu nazwa_interfejsu_sieciowego adres MAC:

world 00:0D:88:11:22:33
intranet 00:0D:88:aa:bb:cc

Teraz wystarczy wydać komendę ifname i nasze nazwy zostały przypisane. To samo swoją drogą osiągnelibyśmy komendą ip link set eth3 name world.
Jedyna rzecz, jaka zostaje do zrobienia to upewnienie się, że nasze przypisania będą się odtwarzać przy starcie systemu. W Debianie (i podejrzewam, że w innych distro także) potrzeba wyedytować plik konfiguracji sieci (Debian: /etc/init.d/networking) dodając do niego:

Używanie odmiany testing Debiana ma jedną wadę - częste aktualizacje, (co nawiasem mówiąc świadczy o tym, że może etch jednak wyjdzie w TYM roku…). Chcąc podnieść sobie wersję open office trafiłem jednak na problem - otóż konfiguracja wywracała się na ttf-opensymbol. Miał on problem z dostępem do niektórych katalogów, których nie było w systemie.

"/usr/share/fonts": error scanning
"/usr/X11R6/lib/X11/fonts": error scanning
"/usr/local/share/fonts": error scanning
"/var/lib/defoma/fontconfig.d": error scanning

Rozwiązaniem okazało się aktualizacja pakietu fontconfig, który nie był wymagany wprost ale jedynie polecany.

Proste i banalne - czasem wystarczy przejrzeć zależności pakietu żeby znaleźć rozwiązanie. Szkoda tylko, że nie można tego zrobić od razu z poziomu aptitude, podczas wystąpienia problemów z instalacją…

Instalacja WEP jest prosta - wszystko sobie działa bezproblemowo, wystarczy wszak instalacja koniecznego i tak pakietu wireless-tools, a potem prosta komenda iwconfig eth1 essid enc restricted. Niestety z WPA trzeba się ciut namęczyć - szczególnie, jeśli posiada się kartę do której pasują sterowniki ipw2[21]00.

Pierwszym krokiem, który musimy wykonać, jest instalacja pakietu wpasupplicant, który wspomaga w autoryzacji - i to nie tylko jeśli chodzi o sieci WPA/WPA2 (TKIP, EAP), ale także WEP oraz sieci otwarte - więc jest pomocniejszy zdecydowanie niż ręczna konfiguracja przez iwconfig.
Niestety ma też swoje wady, przynajmniej w systemie Debian. Otóż nie instaluje on żadnych plików konfiguracyjnych, ani do katalogu /etc/, ani do katalogu /etc/init.d, co jak na rozpieszczającego mnie Debiana jest trzeba przyznać dziwne. Niemniej zmusza do tego, czego misie nie lubią - czyli zamiast “podejścia przez walkę” do przeczytania najpierw instrukcji. Szybkie przejrzenie katalogu /usr/share/doc/wpasupplicant powoduje, że procedura instalacji jest banalnie prosta. Potrzebujemy do niej jednak danych, których część zdobędziemy poprzez wykonanie komendy:
host:~# iwlist eth1 scan.

eth1      Scan completed :
          Cell 01 - Address: 00:16:41:60:13:B2
                    ESSID:"neostrada_195d"
                    Protocol:IEEE 802.11bg
                    Mode:Master
                    Channel:10
                    Encryption key:on
                    Bit Rates:1 Mb/s; 2 Mb/s; 5.5 Mb/s; 6 Mb/s; 9 Mb/s
                              11 Mb/s; 12 Mb/s; 18 Mb/s; 24 Mb/s; 36 Mb/s
                              48 Mb/s; 54 Mb/s
                    Quality=68/100  Signal level=-59 dBm
                    Extra: Last beacon: 4ms ago
          Cell 02 - Address: 00:16:41:10:00:30
                    ESSID:"default"
                    Protocol:IEEE 802.11bg
                    Mode:Master
                    Channel:11
                    Encryption key:on
                    Bit Rates:1 Mb/s; 2 Mb/s; 5.5 Mb/s; 6 Mb/s; 9 Mb/s
                              11 Mb/s; 12 Mb/s; 18 Mb/s; 24 Mb/s; 36 Mb/s
                              48 Mb/s; 54 Mb/s
                    Quality=89/100  Signal level=-40 dBm
                    IE: WPA Version 1
                        Group Cipher : TKIP
                        Pairwise Ciphers (2) : CCMP TKIP
                        Authentication Suites (1) : PSK
                    IE: IEEE 802.11i/WPA2 Version 1
                        Group Cipher : TKIP
                        Pairwise Ciphers (2) : CCMP TKIP
                        Authentication Suites (1) : PSK
                    Extra: Last beacon: 8ms ago

Widzimy, że w zasięgu mamy dwie sieci, jedną chronioną przez WEP, drugą zaś przez WPA - używające szyfrowania AES/TKIP oraz klucza wstępnej autoryzacji (PSK). Jeśli ów klucz znamy, to wystarczy teraz:

• skopiować plik examples/wpa-psk-tkip.conf - cp examples/wpa-psk-tkip.conf /etc/wpa_supplicant/wpa_supplicant.conf
• dokonać w nim odpowiednich zmian - czyli w liniach essid wpisujemy nazwę sieci (tu: default), w proto zostawić WPA, w key-mgmt zostawić WPA-PSK, w pairwise dodać CCMP, zaś w psk wpisać właściwy klucz
• wydać komendę wpa_supplicant -w -i eth1 -D ipw -c /etc/wpa_supplicant/wpa_supplicant.conf, co przy założeniu, że AP nas wpuści, powinno spowodować autoryzację w sieci…

Niestety zamiast podłączenia się do sieci, otrzymujemy komunikat:

ioctl[IPW_IOCTL_WPA_SUPPLICANT]: Operation not supported
ioctl[IPW_IOCTL_WPA_SUPPLICANT]: Operation not supported
Failed to set encryption.
Trying to associate with 00:16:41:10:00:30 (SSID=’default’ freq=0 MHz)
Authentication with 00:00:00:00:00:00 timed out.

Jak widać problem leży gdzieś w sterowniku do ipw, który czegoś nie wspiera, nie ustawia szyfrowania i próbuje się autentykować do nicości/wszystkiego (ciekawe, co ma MAC ::?) Co nam pozostaje? Spróbujmy dokonać debugowania sesji - sam wpa_supplicant to dość dobrze wspiera, wystarczy, że do linii poleceń dodamy “-d”.
host:~# wpa_supplicant -w -i eth1 -D ipw -c /etc/wpa_supplicant/wpa_supplicant.conf -d. Jedną z pierwszych kluczowych dla nas linii jest:

wpa_driver_ipw_set_wpa: enabled=1
ioctl[IPW_IOCTL_WPA_SUPPLICANT]: Operation not supported

Suuuuuper. Jak zwykle kochane sterowniki ipw robią problemy (albo ich implementacja w wpa_supplicant?). Na szczęście jest rozwiązanie wygooglane w bugtracku Debiana - wystarczy zmienić sterownik dla wpa_supplicant na wext, czyli nasza linia wywołania programu powinna wyglądać następująco:
wpa_supplicant -w -i eth1 -D wext -c /etc/wpa_supplicant/wpa_supplicant.conf . Teraz pozostaje tylko skonfigurować interfejs - np. dhclient -i eth1 i voila.

Sprawa wydawałaby się bananalna. Pakiety wchodzą z internetu (interfejs zewnętrzny, zewnętrzny IP) do routera i mają trafić do jakiegoś komputera w sieci. Router robi jakąś maskaradę sieci wewnętrznej. Ponieważ chcemy przejąć w tejże sieci wewnętrznej pulpit, powiedzmy, że to będzie WXP Pro, czyli interesuje nas port 3389. Zakładamy, że port na który wchodzą pakiety, to port 33089
OK - czyli do tej pory mamy:

• zewnętrzny IP routera (np. 193.213.32.4),
• wewnętrzny IP/sieć routera (np. 172.16.34.1/16),
• port routera: 33089
• adres WXP (np. 172.16.34.56),
• port WXP: 3389
• swój adres: 83.24.240.244

Sprawa banalna, opisana wszędzie, wystarczy wykonać dwa polecenia:

• /sbin/iptables -A PREROUTING -t nat -s 83.24.240.244 -d 193.213.32.4 –dport 33089 -j DNAT –to-destination 172.16.34.56:3389
• /sbin/iptables -A FORWARD -d 172.16.34.56 -p tcp –dport 3389 -j ACCEPT

Pierwsza z reguł mówi, że kazdy pakiet wchodzący z sieci zewnętrznej, kierowany na IP 193.213.32.4, port 33089 powinien być przekierowywany na maszynę o IP 172.16.34.56 i port 3389. Jest to reguła sprawdzana zanim zostanie podjęta jakakolwiek decyzja o routingu. Pakiety wpadają sobie do firewalla, podejmowana jest decyzja o routingu, ponieważ sieć docelowa jest wśród tych, które firewall osbługuje, to wrzuca pakiet do łańcucha forward, stąd konieczność (reguła 2) umożliwienia takiego właśnie ruchu.

Banalna sprawa, nieprawdaż? Gdzie ten haczyk? Cóż, wszystko działa oprócz tego, że TU nie działa. Otóż komputer kliencki ma swojego firewalla, który to spryciarz dopuszcza tylko połączenia z sieci wewnętrznej, (co łatwo sprawdzić, bo odrzuca połączenia z zewnątrz, a telnet na port działa). Zastosowany tu DNAT niestety nie tłumaczy adresu źródłowego na adres lokalny i pozostawia 83.24.240.244, co klient od razu ubija - pojawia się konieczność szukania zagrody, znaczy obejścia.
W tym momencie szkoły są dwie: falenicka i otwocka. Albo nie mamy czasu, olewamy sprawę, komfigurujemy tunel i voila, jesteśmy w środku i mamy dostęp do maszyny, albo nie mamy czasu, niemniej pokombinujemy z iptables. Pierwsza rzecz, która się nasuwa, to przeróbka pakietu. Niestety tablica mangle nie do tego została stworzona, żeby przerabiać takie cuda, więc nie tam. Są polecenia conntracka zamiany adresów, ale one raczej nie mają tu zastosowania. Rozwiązanie sprawy leży znów w NATce. Tym razem jednak na wyjściu.

• iptables -A POSTROUTING -t nat -s 83.24.240.244 -d 172.16.34.56 -p tcp –dport 3389 -j SNAT –to 172.16.34.1

Cóż to robi? Bada pakiet już wychodżacy z routera i jeśli spełnia on warunki źródła, celu, portu… to robi NAT (zwany popularnie maskaradą) zamianiejąc jak to w nacie bywa adresy źródła (-s), ukrywając je za adresem bramy. Nie ukrywam, że przez dłuższą chwilę nie przyszło mi do głowy, że to może być tak banalne (przecież to zwykły NAT, tylko na opak), niemniej szybka, nocna lektura dokumentacji pozwala na usprawnienie procesów myślowych.

Jedyne co mnie zastanawia, to fakt, że zawsze najlepsze (czytaj: działające w zadowalający sposób. ok, po prostu działające) rozwiązanie człowiek znajduje na końcu. Może dlatego, że dalej nie szuka?

W debianie testing/etch pojawiło się swego czasu jądro systemu w wersji 2.6.17.

Wielkieś mi uczyniła pustki w domu moim,
Moje drogie jądro, tym pojawieniem swoim!

Jądro to automagicznie wyłączyło mi sieć bezprzewodową, generując przy tym tonę komunikatów typu

Ponieważ jednocześnie owe jądro wnosiło sterownik w wersji 1.1.1 należało także zmienić firmware z wersji 2.4 na 3.0. Niestety - pomimo tych zmian sterownik ipw2200 w jądrze nie działał poprawnie z ieee80211. Pozostawało jedynie ściągnąć nowszą wersję sterownika i samemu znów skompilować moduł ipw2200-source lub rekompilować jądro. Co ciekawe, to zachowanie nie występowało w poprzedniej wersji jądra - 2.6.16, gdzie wszystko działało poprawnie.

Na szczęście po ostatnim upgradzie systemu pojawiło się w końcu jądro 2.6.18 z ipw2200 w wersji 1.2.0 oraz ieee80211 w wersji… 1.1.13 (czyli downgrade!). I znów wszystko działa