Mała sieć domowa w oparciu o system Linux
Dzisiaj zajmiemy się tworzeniem małej, dość dobrze zabezpieczonej sieci domowej. Udostępnianie internetu zrealizujemy poprzez komputer-host z zainstalowanym systemem Linux (dowolnym, może być Ubuntu, Debian, Mandriva i inne). Pamiętajcie jednak, że Wasze środowisko może różnić się od środowiska zaprezentowanego w artykule – analizujcie treść a nie tylko przeklejajcie komendy do konsoli! Lecimy!
Załóżmy środowisko:
Dla ułatwienia ustalmy hostname dla komputerów:
- komp1) orion nasz router
- komp2) scorpio podłączony przez interfejs eth1
- komp3) omega podłączony przez interfejs eth2
- komp4) syrius podłączony przez interfejs eth3
Oczywiście w sieci może być więcej komputerów – wystarczy do routera wsadzić większą ilość kart sieciowych. W przykładzie wykorzystałem 3 komputery z zainstalowanym systemem Debian GNU/Linux, nic jednak nie stoi na przeszkodzie aby był to jakikolwiek inny system operacyjny.
Dokładny opis naszej przykładowej sieci domowej:
Komputer1 (orion) ma 4 karty sieciowe na złączu PCI:
[22:00:05] night@orion:~$ lspci | grep -i ether 02:05.0 Ethernet controller: 3Com Corporation 3c940 10/100/1000Base-T [Marvell] (rev 12) 02:0b.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ (rev 10) 02:0c.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8029(AS) 02:0d.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ (rev 10)
W kolejności są to interfejsy od eth0 do eth3, przy czym interfejs eth0 (gigabitowa karta 3com) jest wpięta do sieci internet dostając adres z klasy prywatnej 192.168.0.10.
<22:02:26> root@orion:/home/night# ifconfig eth0
eth0 Link encap:Ethernet HWaddr 00:0E:2E:90:A7:37
inet addr:192.168.0.10 Bcast:192.168.0.255 Mask:255.255.255.0
inet6 addr: fe80::20e:2eff:fe90:a737/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:2274170 errors:0 dropped:0 overruns:0 frame:0
TX packets:2224882 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:2140325129 (1.9 GiB) TX bytes:1161463487 (1.0 GiB)
Interrupt:21 Base address:0xd400
Konfiguracja kart sieciowych
Zaczynamy od konfiguracji pozostałych kart sieciowych. W tym celu wyedytujemy plik /etc/network/interfaces w poniższy sposób:
(...) auto eth0 iface eth0 inet dhcp auto eth1 iface eth1 inet static address 10.0.0.1 netmask 255.255.255.0 auto eth2 iface eth2 inet static address 10.0.1.1 netmask 255.255.255.0 auto eth3 iface eth3 inet static address 10.0.2.1 netmask 255.255.255.0 (...)
I restart sieci:
# /etc/init.d/networking restart
To tyle w kwestii kart sieciowych. Teraz DHCP!
Konfiguracja serwera DHCP
Na początek szybka instalacja:
# apt-get install dhcp3-server
... i konfiguracja:
# rm /etc/dhcp3/dhcpd.conf; nano -w /etc/dhcp3/dhcpd.conf
W pliczku (który będzie pusty) wpisujemy dla każdej podsieci:
subnet 10.0.0.0 netmask 255.255.255.0 {
range 10.0.0.3 10.0.0.254;
default-lease-time 6100;
option domain-name „nasza.domena”;
option domain-name-servers pierwszy.dns, drugi.dns;
option routers 10.0.0.1;
option subnet-mask 255.255.255.0;
option broadcast-address 10.0.0.255;
host scorpio { # komputer nr 1
hardware ethernet adres.mac;
fixed-address 10.0.0.2;
}
}
Oczywiście zmieniamy domenę, dns’y na własne a adres.mac wypełniamy adresem MAC komputera nr 1 (scorpio). Pozwoli nam to przypisywać jeden i zawsze ten sam adres IP dla tej maszyny. Dla reszty podsieci deklarujemy podobnie:
subnet 10.0.1.0 netmask 255.255.255.0 {
range 10.0.1.3 10.0.1.254;
default-lease-time 6100;
option domain-name „nasza.domena”;
option domain-name-servers dns,pierwszy, dns.drugi;
option routers 10.0.1.1;
option subnet-mask 255.255.255.0;
option broadcast-address 10.0.1.255;
host scorpio {
hardware ethernet adres.mac;
fixed-address 10.0.1.2;
}
}
Analogicznie dla podsieci trzeciej zmiejając odpowiednio ustawienia IP w konfiguracji. Drobna zmiana w skrypcie startowym:
# nano -w /etc/default/dhcp3-server
gdzie definiujemy interfejsy na których działać ma serwer DHCP
INTERFACES="eth1 eth2 eth3"
... i restart demona
/etc/init.d/dhcp3-server restart
W tym momencie możemy sprawdzić, czy nasze stacje robocze otrzymały adres sieciowy (należy odświeżyć ustawienia IP na każdym z nich). Jeśli wszystko zrobiliśmy dobrze powinniśmy móc pingować każdy z naszych komputerów. Pozostało nam udostępnienie dla nich internetu.
Udostępnianie sieci
W tym celu stworzymy dodatkowy skrypt startowy:
# nano -w /etc/init.d/firewall
Do którego to wpiszemy następujące regułki iptables:
#linijka potrzebna do włączenia udostępniania internetu echo 1 > /proc/sys/net/ipv4/ip_forward #wyczyszczenie starych reguł z pamięci iptables iptables -F iptables -X iptables -t nat -X iptables -t nat -F # ustawienie domyślnej polityki (o tym później) iptables -P INPUT ACCEPT iptables -P FORWARD ACCEPT iptables -P OUTPUT ACCEPT iptables -A INPUT -i lo -j ACCEPT iptables -A FORWARD -o lo -j ACCEPT # Najważniejsze - udostępnienie sieci dla wybranych podsieci iptables -t nat -A POSTROUTING -s 10.0.0.0/24 -j MASQUERADE iptables -t nat -A POSTROUTING -s 10.0.1.0/24 -j MASQUERADE iptables -t nat -A POSTROUTING -s 10.0.2.0/24 -j MASQUERADE
Plik zapisujemy, nadajemy mu prawa wykonywalności:
# chmod +x /etc/init.d/firewall
dopisujemy do standardowych runleveli:
# update-rc.d firewall defaults 90
i odpalamy:
# /etc/init.d/firewall
W tym momencie mamy działający internet na wszystkich 3 komputerach. Voila! Trzy ostatnie linijki w skrypcie powinny stworzyć nam odpowiednią tablicę routingu:
# route -n Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 10.0.0.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1 10.0.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth2 10.0.2.0 0.0.0.0 255.255.255.0 U 0 0 0 eth3 192.168.0.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 0.0.0.0 192.168.0.1 0.0.0.0 UG 0 0 0 eth0
Dzięki tym wpisom komputery w sieci domowej będą „widzieć się wzajemnie”. Możemy to sprawdzić pingując hosta scorpio z hosta omega, lub na odwrót. No i najważniejsze – możemy korzystać z internetu na wszystkich końcówkach podpiętych do sieci domowej :-).
Powiedzmy jednak, że to nas nie satysfakcjonuje. Chcemy mieć możliwość logowania się poprzez ssh do każdego z komputerów w sieci domowej. Musimy zatem zająć się forwardowaniem portów.
Przekierowanie portów
Aby przekierować wybrany port z hosta A na nasz router musimy na końcu naszego skryptu firewall dopisać:
iptables -t nat -A PREROUTING -p tcp -i eth0 --dport 800 -j DNAT --to 10.0.0.2:22
Co to robi? Forwarduje każde zapytanie przychodzące na port 800 karty sieciowej eth0 na adres 10.0.0.2, port 22 w sieci lokalnej. Zatem, jeśli odpytamy nasz router z sieci zewnętrznej w ten sposób:
$ ssh <user>@<host> -p 800
Dostaniemy de facto połączenie z komputerem z adresem 10.0.0.2 w sieci lokalnej. W naszym przykładzie będzie to scorpio. Dodajmy resztę hostów:
iptables -t nat -A PREROUTING -p tcp -i eth0 --dport 800 -j DNAT --to 10.0.0.2:22 iptables -t nat -A PREROUTING -p tcp -i eth0 --dport 801 -j DNAT --to 10.0.1.2:22 iptables -t nat -A PREROUTING -p tcp -i eth0 --dport 802 -j DNAT --to 10.0.1.2:22
I w ten sposób mamy możliwość zalogowania się na każdy z naszych komputerów w sieci domowej z zewnątrz.
Jutro opiszę sposób zabezpieczenia naszego routera przed najpopularniejszymi atakami z zewnątrz w przypadku gdy posiadamy publiczny adres IP. Enjoy!
W artykule mogły pojawić się błędy i nieścisłości. Będzie on zaktualizowany w przypadku wykryciu takowych.
„Błąd szyny” – opis problemu
Od pewnego czasu miałem ciągłe problemy z moim komputerem stacjonarnym. Zawieszał się, restartował, wywalały się X’y, rozłączały karty sieciowe czy też nagle tracił całą tablicę routingu dla sieci domowej. Winę za to zwalałem na Debiana Sid z kilkoma paczkami z Experimental. Czasem pomagała reinstalacja pakietu, czasem zmiana wersji, czasem zaś restart komputera. Do dziś...
Włączając rano komputer zaniepokoił mnie komunikat apt’a:
(...) ldconfig: /usr/lib/libdb-4.6.so - plik jest skrócony (...)
... i tak kilkukrotnie. Googlowanie niezbyt mi pomogło, musiałem wychodzić do pracy. Zostawiłem włączony sprzęt.
W pracy zauważyłem ciekawą rzecz – padł mi serwer poczty. Szybkie logowanie do domku po ssh, postfix i:
# postconf -e Błąd szyny
Eeee? Mało tego:
# postfix Błąd szyny
że co?!
$ iceweasel -no-remote Błąd szyny
Nie no, to za wiele….
# apt-get install --reinstall iceweasel segmentation fault Błąd szyny
Opis błędu
„Błąd szyny” to tak naprawdę SIGBUS wysłany do procesu. Świadczy on o złym przydzieleniu miejsca w pamięci operacyjnej dla procesu, przez co nie może on zostać wykonany. Najczęściej przyczyną „błędu szyny” jest uszkodzenie pamięci RAM.
Analiza błędu
Wykonałem (zdążyłem wykonać) 2 czynności:
# memtester 500MB
Które szło sobie w tle dość szybko, oraz:
# strace postfix
Które pokazało bardzo ciekawą rzecz:
(...)
open("/usr/lib/libdb-4.6.so", O_RDONLY) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\260a\1"..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0644, st_size=1336100, ...}) = 0
mmap2(NULL, 1340944, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb7e79000
mmap2(0xb7fbb000, 12288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x142) = 0xb7fbb000
mmap2(0xb7fbe000, 9744, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xb7fbe000
****** SIGBUS *******
#
Odwołanie do pliku /usr/lib/libdb-4.6.so siedzącego w 0xb7fbe000 powodowało SIGBUS. Podejrzenie padło na tą właśnie komórkę pamięci. Przyjrzałem się dokładnie /usr/lib/libdb-4.6.so i co się okazało to już chyba łatwo przewidzieć. Biblioteka ta siedziała sobie na tym adresie pamięci a każde odwołanie do tej komórki kończyło się SIGBUS. Przełączenie konsoli na lecącego w tle memtestera pokazało prawdę – memtester wyrzucił SIGBUS a po kilkunastu sekundach miałem piękny kernel panic… Co oczywiście poskutkowało utraceniem połączenia SSH.
Morał
Jeśli kiedykolwiek napotkacie na SIGBUS w swoim komputerze, na dziwne błędy w stylu „Błąd szyny” bądź też na niestabilną pracę wielu niezależnych programów – przetestujcie swoje komponenty, w szczególności pamięć RAM i nie bagatelizujcie problemu… A teraz modlę się aby sprzęt w domu dało się odratować.
KNetworkManager, KPowerSave i problemy z uprawnieniami
Ostatnia aktualizacja Debiana Sid była dość desktrukcyjna dla mojego systemu… Padł GIMP (niezgodność wersji gimp i gimp-data), dodanie nowych X-ów spowodowało błędy ABI o których pisał Hadret i co chyba najgorsze – uruchamianie KPowerSave oraz KNetworkManager powodowało po kilku(nastu) sekundach sprzętowe zwisy komputera… Dodatkowo – KNetworkManager nie widział żadnych interfejsów sieciowych a KPowerSave nie potrafił regulować częstotliwości pracy procesora i podświetlenia matrycy. Uruchomienie tych aplikacji pod kontem roota dawało pozytywne efekty (wszystkie opcje działały), jednak tylko przez kilkanaście sekund – sprzętowy zwis. Słowem – koszmar na kilkadziesiąt minut zabawy…
Dla potomności i samoinformacji (swoisty reminder) zamieszczam rozwiązanie problemu z KPowerSave i KNetworkManager. Cała wina leży po stronie D-BUS a raczej jego najnowszej wersji, która wprowadza zaawansowane profile uprawnień. Zaglądając do:
$ cat /etc/dbus-1/system.d/knetworkmanager.conf
Widzimy „policies„, czyli nasze profile. I co? „Default„ jest na ustawione na „deny„ w każdym przypadku… Hmmm… Patrząc dalej zauważamy sygnowaną grupę, dla której flagi ustawione są na „allow„. No to:
# groupadd night netdev
Bądź też zmieniamy ustawienia „Default„ – wtedy każdy użytkownik będzie miał dostęp do zmiany ustawień sieci poprzez knetworkmanager. Analogicznie postępujemy dla kpowersave i innych programów, które korzystając z D-BUS poprawnie działają pod root‘em a na kontach użytkowników sprawiają problemy..
Voila! Wiem, nie wysiliłem się z wpisem, ale siedziałem troszkę nad tym aby zrozumieć mechanizm działania nowego systemu D-BUS. Boję się KDE4, które całe przejdzie na D-BUS...
Touchlib i OpenTouch czyli ekrany wielodotykowe
Pamiętacie film „Raport Mniejszości”? John Anderton korzystał w nim z ekranu dotykowego dużej rozdzielczości do „podglądania” przyszłości. Fikcja? Nie, ta technologia jest już w zasięgu ręki! No, może nie podglądanie przyszłości :-).
Ekran wielodotykowy to urządzenie, które pozwala komunikować się z użytkownikiem poprzez wygodny interfejs panelu dotykowego. Co go jednak wyróżnia to możliwość rozpoznawania wielu równoczesnych zdarzeń, np. używania panelu przez kilka osób jednocześnie.
Firma Microsoft zaprojektowała i stworzyła Microsoft Surface. Projektem zainteresowało się wojsko, kasyna w Vegas i największe hotele świata. Możecie sobie tylko wyobrazić jak wiele pieniędzy to może kosztować.
O samym Microsoft Surface możecie poczytać tutaj a prezentację macie poniżej:
Zapytacie pewnie – a jaki ma to związek z Wolnym Oprogramowaniem? Ma i to dość spory. Touchlib i OpenTouch to otwarte biblioteki do obsługi paneli wielodotykowych. Co ciekawe OpenTouch rozwijane jest przez naszego rodaka: Pawła Sołygę!.
No to super. Mamy całkowicie otwarte biblioteki do obsługi panelu wielodotykowego ale… ciągle nie mamy samego ekranu… Więc czemu sobie takowego nie zbudować?
NUI Group to grupa miłośników technologii naturalnych interfejsów komunikacyjnych. Na ich stronie oraz forum możemy znaleźć osoby, które zajmują się tworzeniem na własną rękę ekranów w technologii Frustrated Total Internal Reflection (FTIR). Sam mechanizm takiego panelu działa na zasadzie całkowitego węwnętrznego odbicia w dość grubej warstwie pleksi.
Złożenie ekranu wielodotykowego jest dość drogie i zajmuje troszkę czasu. Mały ekran 12×15cm możemy zbudować za około 600zł, duże panele (ponad metr szerokości) kosztować nas mogą do kilku tysięcy złotych. Po szczegółowe informacje na temat budowy zapraszam na forum NUI Group, a poniżej krótka prezentacja z możliwości własnego panelu wielodotykowego obsługiwanego przez otwarte bilbioteki touchlib:
Prezentację konkretnego zastosowania możecie zobaczyć na tej stronie (polecam).
Jak się to ma do systemu GNU/Linux? Touchlib i OpenTouch można bez problemu uruchomić i oprogramować pod dowolnym systemem Linuksowym. Dodatkowo – istnieje projekt MPX. MPX to modyfikacja Serwera X tak, aby mógł on korzystać z bilbioteki TouchLib. Wyobrażacie sobie na tym Compiza? :-)
I już na koniec: Touchlib jest wieloplatformowy (uruchamia się na praktycznie każdym sprzęcie, od Maców po PC), wydajny (szybkie działanie zapewnia średniej klasy komputer PC), skalowalny i wolny. Cóż więcej chcieć? Chyba zaczynam odkładać pieniążki na MyBox – mały panel wielodotykowy budowany przez NUI Group za cenę około 250zł. Niestety, nie wyświetla on obrazu, pozwala tylko pobawić się samych Touchlib…
Conky 1.4.7 dla Debiana (paczka deb)
Dwa tygodnie temu wydana została najnowsza wersja monitora systemowego Conky. Jak zwykle już – zbudowałem paczkę dla systemu Debian Sid. Paczka powinna zadziałać także w Debianie z gałęzi Testing. W tej wersji programiści dodali:
- moduł kolorowania składni pliku .conkyrc dla nano (w końcu działa!)
- zmienną $hwmon – wykorzystywaną do lm_sensors
- bezpośrednią implementację RSS (chociaż niektórzy nadal pewnie wolą swoje skrypty :-))
- monitorowanie stanu sieci bezprzewodowej
- kilka pomniejszych zmian w treści licencji i samym kodzie
Aby ściągnąć paczkę kliknij TUTAJ
Jeśli czegoś zabraknie w powyższej paczce proszę o powiadomienie, zbuduje się nową z „dodatkowymi funkcjonalnościami”.
ENJOY!
