Własny DNS cache jako lekarstwo na problemy z siecią

Jest powiedzenie, że nowe to dobrze zapomniane stare. Tak jest w przypadku DNS i ataków różnej maści. Niedawno głośno było o DDoSach z użyciem DNS amplification, potem o podmianie DNS (głównie na routerach, nie jak kiedyś na komputerach, ale cel ten sam), a od niedawna popularne stało się generowanie dużej ilości zapytań do serwerów DNS rekursywnych ISP (AFAIK też ostatecznie rodzaj DDoSu). Na tyle dużej, że niektórzy operatorzy mieli/mają problemy z obsłużeniem żądań pochodzących od swoich klientów na swoich serwerach cache’ujących.

Z różnych pokątnych źródeł (Facebook, IRC) wiem, że pierwszego dnia, gdy się to zaczęło, były problemy z dostępem do Internetu w sieciach należących do Inei i Multimedii. Nie znam przyczyny, ale biorąc pod uwagę, że jeszcze jednemu providerowi „kończyły się” maszyny obsługujące rekursywne DNS i że w przypadku Multimedii pomagała zmiana w systemie na np. serwery DNS Google, przypuszczam, że chodzi właśnie o niewydolność serwerów DNS dostarczanych użytkownikom tych sieci przez ISP.

Rozwiązanie jest dość proste – wystarczy uruchomić swój serwer DNS rekursywny lub forwarder na desktopie czy routerze w swojej sieci, by sieć zaczęła działać lepiej i być mniej zależna (lub nawet niezależna) od DNSów naszego ISP. Ja na swoich desktopach (oczywiście Linux) od dłuższego czasu mam uruchomionego unbound (pokłosie benchmarków DNS) – jest lekki i bezproblemowy. W obecnej sytuacji mamy podwójną korzyść z własnego cache: po pierwsze, jak zwykle odpowiedzi udzielane będą nieco szybciej[1], po drugie, uniezależniamy się od serwerów naszego ISP, który w związku z niewesołą sytuacją w sieci może mieć problemy z działaniem w ogóle.

Z kolei w przypadku sieci lokalnych i routerów sprzętowych działających pod kontrolą OpenWrt lub podobnego systemu warto zwrócić uwagę na mały i zgrabny dnsmasq, którego konfigurację opisywałem kiedyś dość dokładnie.

Niezależnie od wyboru, koniecznie pamiętajmy o zabezpieczeniu czyli poprawnej konfiguracji naszego serwera DNS. Obsługujmy zapytania rekursywne tylko z naszej zaufanej sieci (np. LAN). W przeciwnym razie nasz serwer może zostać wykorzystany do DDoS poprzez DNS amplification. Ograniczać można na wiele sposobów w zależności od użytego serwera i możliwości: firewall, ograniczenie nasłuchiwania do konkretnego interfejsu lub definicje obsługiwanych prefiksów w konfiguracji samego serwera.

[1] Nie zawsze jest to prawdą, liczy się nie tylko opóźnienie do serwera, ale także zawartość jego cache czy wydajność sprzętu, na którym działa. Pisałem kiedyś szerzej o wyborze serwera DNS.

Koniec konta w dyndns.com

Usługa dyndns w dyndns.com – czyli chyba najpopularniejszego dyndns w ogóle; pamiętam, że nawet w niektórych routerach w swoim czasie był wbudowany i to w firmware producenta – od dawna zmierzała do tego, by być płatną. A to skończyły się rejestracje nowych darmowych kont, a to wprowadzono wymóg korzystania z kont, a to – ostatecznie – wymóg logowania się przez WWW raz na miesiąc.

Ponieważ aż cały miesiąc na zalogowanie był, to stwierdziłem, że zawsze zdążę. Tym bardziej, że przysyłali powiadomienia parę dni wcześniej. I wystarczyło kliknąć linka. Więc nawet nie ustawiłem crona, który sam by się logował – w końcu link taki wygodny… O koncie płatnym nie myślałem – 15 dolców na rok to trochę dużo jak za „zamień zmienne IP na coś możliwego do zapamiętania”. Jakąś dotację co łaska (np. via Flattr) pewnie bym rzucił, ale tak z góry narzucona opłata – niekoniecznie, tym bardziej, że mogę sobie odpalić własny zastępnik w jakieś 30 minut. No ale nie lubię takich rzeźb i wolę coś, co jest wspierane szerzej i ma już infrastrukturę.

Dziś stwierdziłem, że nie mogę się zalogować. Błąd rozwiązywania nazwy. Hm, bywa, może awaria. Potem coś mnie tknęło. Sprawdziłem maile. Tak jest. 30.10 dostałem przypomnienie. Oczywiście zostało oznaczone jako spam przez providera poczty, w programie pocztowym, a pewnie i podświadomie angielski tytuł sklasyfikowałem jako spam.

W każdym razie nie mam już konta na dyndns.com. W zamian wybrałem no-ip.com. Też zasłużony w temacie serwis, też zdaje się był na routerach SOHO wspierany. I też mocno zmierzający w stronę komercji, ale nie przejmuję się – rejestracja tego typu serwisu plus setup to dosłownie 5 minut. No i w końcu uruchomiłem też dyndns na moim OpenWrt.

Niezbyt łatwo znaleźć przykłady konfiguracji ddclient dla no-ip.com (choć jest trywialna, a protokół noip wbudowany), więc:

cat /etc/ddclient.conf
pid=/var/run/ddclient.pid
protocol=noip
use=if, if=ppp0
login=login
password=haslo
domena.no-ip.biz

Wersja dla Dockstara z PPPoE, publiczny IP na ppp0.

PS Wpisu by nie było, ale ładnie wpisuje się w trend „używałem tego od lat, a teraz zamknęli„.

UPDATE Z tym ddclientt to pochwaliłem za wcześnie. Nie tylko nadal występuje coś, co miało miejsce od dawna, czyli obecność wiszących procesów ddclient, ale – co gorsza – przyrastają w zastraszającym tempie. Load 30 na biednym routerku był dziś za ich przyczyną. Ledwo zdołałem ubić. Sam ddclient okazał się skryptem w Perlu (przychodzi mi na myśl taki rozwinięty smsender.pl), a rozwiązanie jest proste – nie korzystam już z demonizacji, tylko wywołuję co 10 minut z crona. Okazało się, że ma jakiś problem z cache, a konkretnie z odczytem wartości z niego. Rozwiązanie wygląda tak (po wyłączeniu demonizacji w /etc/default/ddclient):

*/10 * * * * /bin/rm /var/cache/ddclient/ddclient.cache; /usr/sbin/ddclient -quiet > /dev/null

Wiem, dirty hack. Ostatnio mam niestety tendencję do tego. Przyznam, że myślałem w pierwszej chwili o cyklicznym killowaniu procesów ddclient.

UPDATE: Wygląda, że albo z tym wyłączaniem usług to ściema, albo coś im nie poszło – dostaję kolejne maile z linkami, których kliknięcie aktywuje konto. Nie sprawdzałem działania, ale wygląda, że mogę dodawać kolejne hosty i normalnie dalej korzystać za free. Raczej ciekawostka, bom już przeniesiony.

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.