Zabbix i monitorowanie ruchu na porcie

Niedawno na kanale IRCowym #zabbix padło pytanie, jak monitorować ruch na porcie. Po upewnieniu się, że chodzi o port protokołu, a nie o interfejs w switchu (co jest zresztą chyba bardziej popularnym znaczeniem, szczególnie w kontekście monitoringu), padły propozycje.

Moja ulubiona ostatnimi czasy metoda, czyli czytanie danych o ruchu z flowów. Poważnie, sflow i nfdump rządzą, a wrapper do Zabbiksa, który łyka parametry i używa nfdump jest trywialny do napisania, lekki i działa znakomicie, a wyciąganie dowolnych danych o ruchu jest bardzo wygodne. No ale do tego trzeba mieć zboczenie sieciowe i/lub sprzęt obsługujący flowy, ew. uruchomić zrzucanie flowów na maszynie z Linuksem, co może być zbędnym jej obciążeniem i ogólnie strzelaniem z armaty do muchy.

Prostszym rozwiązaniem jest odczyt danych bezpośrednio z iptables. Przypuśćmy, że chcemy monitorować w Zabbiksie, ile ruchu trafia do serwera na porcie 80, a ile na 443. W tym celu tworzymy reguły, które będą dopuszczały, a jednocześnie zliczały ruch na danym porcie:

iptables -A INPUT -p tcp --dport 443 -j ACCEPT
iptables -A INPUT -p tcp --dport 80 -j ACCEPT

Zakładam, że trafią w odpowiednie miejsce w łańcuchu tak, że ruch będzie przez nie przechodził. Do wyświetlania wartości posłuży iptables -L -n -v. Jak widać, w pierwszej kolumnie jest ilość pakietów, w kolejnej ilość bajtów. W /etc/zabbix/zabbix_agentd.conf dodajemy linię:

UserParameter=traffic.incoming.dstport[*], iptables -L -n -v | grep "dpt:$1" | \
sed 's/K/000/;s/M/000000/;s/G/00000000/' | awk '{print $$2}'

Kolejno: grep po parametrze wywołanym z Zabbiksa, w tym przypadku za parametr posłuży numer portu (czyli czytamy dwie wartości: traffic.incoming.dstport[80] oraz traffic.incoming.dstport[443]), zamiana (zgrubna, bo kilo to 1000, nie 1024) K, M i G na cyfry i wyłuskanie w awk drugiej kolumny, czyli ilości bajtów. Widoczny podwojony $ – bez tego zabbix_agent potraktuje $2 jako drugi parametr przekazany z serwera.

I to by było tyle w temacie. Oczywiście można w prosty sposób rozbudować. Gdyby były jakieś błędy/uwagi/sugestie to walcie śmiało – pisałem na sucho, ja tego typu dane biorę z flowów…

Jak uruchomić touchpad na Dell Vostro 3360 pod Linuksem

Dell Vostro 3360 to zacny sprzęt, z którego korzystam w pracy, chyba od roku. Trochę żałuję, że nie kupiłem go do domu, ale kupowałem wcześniej, nie byłem jakoś przekonany do 13″, no i cena też trochę wyższa. Okazuje się, że jak najbardziej taki ekran daje radę. W pracy korzystam z wersji z dyskiem SSD i procesorem i5. Na początku było więcej, teraz jest 4,5-5h na baterii, więc wynik bardzo przyzwoity – długie wypady pociągiem, serie spotkań w firmie czy przedłużający sie wypad do kolokacji mu nie straszne i nie ma potrzeby korzystania z zasilacza.

Vostro 3360 daje się zmusić do działania z Linuksem (opis co jak działa może kiedyś popełnię, ale wcześniejsze opisy na potrzeby Linux on laptops nie cieszą się zainteresowaniem, więc motywacja jest nikła), ale nie jest to sprzęt, w którym wszystko działa OOTB. Nawet więcej: dawno nie widziałem sprzętu wymagającej takiej rzeźby w celu uruchomienia Linuksa. Grymasił na wersję kernela, co objawiało się… zwisami systemu (nic ciekawego w logach nie znalazłem). Co ciekawe tylko pod Debianem, kumple pod Ubuntu z IIRC taką samą wersją kernela problemu nie mieli. Na debianowym 3.6 (wówczas z experimental) działało stabilnie, więc tak zostało.

Inne problemy to: touchpad (naciśnięcie obu klawiszy naraz domyślnie nie emuluje naciśnięcia środkowego klawisza, co jest standardowym pod Linuksem – i ukochanym przeze mnie – skrótem do wklej), dźwięk czy karta sieciowa Atheros (o dziwo miedź). Dźwięk z alsą z Wheezy’ego działa IIRC od kopa, więc można uznać problem za załatwiony. Zresztą uruchomienie wszystkich komponentów Vostro 3360 na Linuksie (Debian Wheezy) ładnie opisał Łukasz. Co ciekawe, kernel 3.7 powodował jakieś problemy, ale nie pamiętam, czy chodziło o stabilność, czy może o coś innego.

W każdym razie czasy się trochę zmieniły, 3.6 jakiś taki starawy już. Doszły mnie słuchy, że karta sieciowa powinna działać bez magicznych zabiegów pod kernelem 3.11. Postanowiłem sprawdzić. Faktycznie, wydaje się działać. A system pozostaje stabilny. Pozostał jednak problem z touchpadem, więc postanowiłem zrobić instrukcję dla nowszej wersji kernela i nowszych plików ze strony, bo takie się pojawiły.

Na początek smutna sprawa: kernel 3.11, a dokładniej jego pliki nagłówkowe wymagają gcc w wersji 4.8, a to oznacza wymianę połowy systemu ze względu na zależności. Albo konieczność skompilowania kernela samodzielnie (czego na potrzeby desktopa wieki nie robiłem). Wybrałem bramkę numer dwa.

Wchodzimy na http://www.dahetral.com/public-download/alps-psmouse-dlkm-for-3-2-and-3-5/view i pobieramy plik psmouse-alps-1.3-alt.tbz.

Rozpakowujemy go (w /usr/src)

tar xvjf psmouse-alps-1.3-alt.tbz

Pobieramy debianowe źródło kernela

wajig install linux-source-3.11

I kopiujemy bieżący konfig (zakładam, że mamy uruchomiony kernel 3.11 z Debiana)

cp /boot/config-3.11-2-amd64 /usr/src/linux-source-3.11/.config

Kompilujemy i paczkujemy kernel oraz pliki nagłówkowe

cd /usr/src/linux-source-3.11
make-kpkg --append-to-version=-bpo-rozie --initrd kernel_image
make-kpkg --append-to-version=-bpo-rozie kernel_headers

Instalujemy utworzone pakiety

cd .. && wajig install linux-image-3.11.8-bpo-rozie_3.11.8-bpo-rozie-10.00.Custom_amd64.deb && 
wajig install linux-headers-3.11.8-bpo-rozie_3.11.8-bpo-rozie-10.00.Custom_amd64.deb

Kompilujemy i instalujemy odpowiedni moduł:

cd /usr/src/psmouse-alps-1.3 && ./alps.sh dkms_build_alps

Polecenie to automatycznie powoduje przeładowanie modułu psmouse, więc jeśli nie wystąpiły błędy, to od tej chwili wszystko powinno działać poprawnie, w szczególności naciśnięcie obu przycisków touchpada powinno wklejać zawartość schowka.

UPDATE: Prawdopodobnie da się prościej, o ile się nie jest ślepym. Wystarczy do sources.list dodać obsługę backportów dla Wheezy’ego:

deb http://http.debian.net/debian wheezy-backports main contrib non-free

i dostępne staną się kernele linux-image-3.11*… Cóż, kto nie ma w głowie, ma w… kompilatorze. Inna sprawa (i moje usprawiedliwienie!) to fakt, że nie tylko nikt nie zwrócił na to uwagi w komentarzach, ale nawet dwie osoby korzystają z mojego kernela.

UPDATE2: Wygląda na to, że od wersji 3.13 kernela nie potrzeba takich zabiegów. Przed chwilą zainstalowałem z debianowych backportów 3.13.5-1~bpo70+1 i… touchpad działa od kopa, bez kompilacji czegokolwiek.

Debian, Huawei E3131 od Play i Aero2

Będzie krótko o tym, jak uruchomić i korzystać z modemu Huawei E3131 od Play na Debianie (unstable). Dokładny opis dotyczący Aero2 z Huawei E3131 jest na DUG, tu najważniejsze rzeczy i parę zmian.

Modem Huawei E3131 od Play

Źródło: http://www.play.pl/telefony/huaweie3131_white/img/gal/big/1_1100x1100.png

Instalacja potrzebnych programów:

wajig install usb-modeswitch wvdial

Ustawienie trybu automatycznego (domyślnie jest tylko Play). Wykonanie na rozłączonym modemie, tylko raz, po kupnie modemu:

echo "AT^SYSCFG=2,0,3FFFFFFF,1,2\r" >/dev/ttyUSB0

Zawartość pliku konfiguracyjnego wvdial.conf:

$ cat /etc/wvdial.conf 
[Dialer aero2]
Modem = /dev/ttyUSB0
Init1 = AT+CGDCONT=1,"IP","darmowy"
Phone = *99#
Stupid mode = yes
Username = "aero"
Password = "aero"
Dial Attempts = 0
Auto DNS = "off"

[Dialer power]
Modem = /dev/ttyUSB0
Init1 = AT+CSQ

Gwoli wyjaśnienia – opcja Auto DNS nie działa. Ani wywołana w powyższy sposób, ani jako Auto DNS = 0 – zawsze ustawia serwery DNS w /etc/resolv.conf. Nadpisuję ręcznie przez

echo "nameserver 127.0.0.1" > /etc/resolv.conf

Aby faktycznie wvdial nie ustawiał serwerów DNS oferowanych przez dostawcę, tylko korzystał ze statycznie ustawionych w /etc/resolv.conf, należy, poza powyższymi ustawieniami, w pliku /etc/ppp/peers/wvdial zakomentować opcję usepeerdns. Info z wpisu static DNS with wvdial.

I tu pierwszy trick – lokalny cache DNS powinien znacznie przyspieszyć odczuwalne działanie sieci, zwł. na tak wolnym łączu.

Trick drugi – używam tunelowania SSH z kompresją (ssh -CND 9000 user@host_z_lepszym_łączem)i socks proxy 5 (localhost:9000) w przeglądarce. Na oko, łącząc się do hosta 1/0,25 Mbps jest minimalnie szybciej, niż na gołym Aero2. W przypadku użycia VPS z porządnym łączem jest znacznie szybciej. Warto zwrócić uwagę, by zapytania DNS nie były tunelowane, jeśli korzystamy z lokalnego cache’ującego serwera DNS.

Połączenie z siecią nawiązuję przez wvdial aero2 – w tym przypadku nie zależy mi na automagicznym wznawianiu w tym przypadku.

Drugi wpis, czyli power służy do określania siły sygnału GSM (znowu sprawdzanie siły sygnału GSM opisane jest szerzej na DUG). Wywołanie to wvdial power, otrzymujemy dwie cyfry oddzielone przecinkiem, interesuje nas pierwsza cyfra. 2 km od nadajnika (strona z rozmieszczeniem nadajników GSM poszczególnych operatorów z możliwością pomiaru odległości od nich), w budynku, na parterze, bez żadnej anteny mam 7-10. To wystarcza do bezproblemowego działania sieci. Ogólnie jestem bardzo zadowolony z Huawei E3131 i jego działania pod Linuksem.

UPDATE: W związku z tym, że od 1 kwietnia 2014 do nawiązania połączenia przez Aero2 wymagane jest rozwiązanie CAPTCHA, należy uważać ze zmianą DNSów. Jeśli zmienimy z serwerów DNS Aero2 na inne, to nie nastąpi automatyczne przekierowanie żądania HTTP na stronę z CAPTCHA. Dla porządku: adres, na który następuje przekierowanie to http://bdi.free.aero2.net.pl:8080/ (uwaga na port!). Resolvuje się to – tylko z sieci Aero2 przed uzyskaniem pełnego dostępu do internetu – na http://10.2.37.78:8080/

UPDATE Jeśli szukasz opisu Linuksa i Huawei E3131 w wersji hilink zajrzyj do tego wpisu.