Wstęp
Jak skonfigurować domowy serwer pełniący funkcje NAT, firewalla, serwera uPNP (do dynamicznego przekierowania portów dla np. Skype czy choćby transferów plików w Gadu-Gadu), serwera iTunes, DHCP, lokalnego przyspieszacza DNS (bind9), przyspieszacza WWW (transparent proxy za pomocą Squid 3), usługi pobierania plików poprzez BitTorrent z możliwością kontroli przez WWW lub aplikację kliencką (dzięki transmission-daemon).
Do tego celu użyję dość przyjemnego w konfiguracji Ubuntu Server, w wersji zwanej kodowo Karmic Koala (wkrótce, już oficjalnie, 9.10).
Zakładam że dostęp do Internetu uzyskujemy przez urządzenie zewnętrzne, dostarczone przez operatora, podłączone za pomocą kabla sieciowego do serwera. Inne konfiguracje, jak np. modem DSL podłączony przez USB, także są możliwe, jednak ich ustawienie zostawiam w gestii czytelnika.
Konfiguracja sprzętowa
Mój serwer to stosunkowo żwawy staruszek o następujących parametrach:
- Pentium III 933 skręcony na 466MHz - chłodzony pasywnie pióropuszem Zalmana, ogrzane powietrze odciągane przez zasilacz - temperatura 32-36°C, także w gorące dni
- 512MB RAM (DDR 133)
- Seagate Barracuda IV 60GB - tu rzecz jasna polecam coś większego
- dwie karty sieciowe 1Gbps, choć może z jedną nieco przesadziłem, ponieważ i tak łączy się ona z modemem kablowym UPC z prędkością 100Mbps. Z drugiej strony karty gigabitowe nie są znacząco droższe od 100 megabitowych, więc nie stanowi to problemu. Zawsze mamy nieco lepszy sprzęt na wypadek, gdyby operatorzy zaczęli nam wreszcie do domów podpinać gigabitowe łącza światłowodowe. ;)
Na razie jest to lekko chaotyczny zrzut kroków, jakie popełniłem po kolei, by z czystej instalacji stworzyć dość fajnie działający serwerek domowy. Jak czas pozwoli, rozwinę go nieco i uporządkuję.
Gdyby pójść zgodnie z opisem, myślę że skonfigurowanie serwera można zamknąć w dwóch godzinach od zainstalowania.
Pewne elementy konfiguracji powinno dać się jeszcze przyspieszyć, wykorzystując nieco magii uniksowych poleceń grep/sed/awk, jednak nie jestem w nich szczególnie biegły, zatem nie będę ryzykował. ;)
Przy instalacji wybrałem opcje "LAMP", "DNS", "Samba". W razie gdyby czegoś brakowało, a będzie potrzebne przez inne usługi, które będziemy instalować na następnym etapie, zostaną przez Ubuntu doinstalowane.
Uwaga! Przy instalacji Ubuntu Server może być warto wybrać opcję LVM dla dysków, albo zarezerwować sobie nieco miejsca na takie wolumeny na dysku. Dzięki temu w łatwy sposób będzie można stworzyć udziały Windows obsługujące shadow copy, tj. zachowujące historię zmodyfikowanych plików i pozwalające do nich wracać w dowolnym momencie. Funkcja ta istnieje od Windows 2000, serwer Samba obsługuje ją poprzez vfs, za pomocą modułu shadow_copy. Konfiguracja shadow copy jest dość prosta. Póki nie spróbuję samemu i nie udokumentuję, polecam opis wyglądający na dość przyjemny: SambaShadowCopyHowto.
Czego jeszcze w opisie brakuje, to konfiguracja związana z opcjami oszczędności energii. Ze względu na posiadany procesor, usług wykorzystujących Cool'n'Quiet w procesorach AMD czy SpeedStep nie będę konfigurował, ale warto się nimi zainteresować. Procesor w tego typu serwerze mimo wszystko większość czasu będzie się dość nudził, zatem będzie działał na minimalnych przewidzianych przez producenta obrotach.
Można natomiast zająć się ustawieniem chociażby wyłączania dysku/dysków po ustalonym czasie. Gdy nieco ten temat rozpoznam, także pod względem zorientowania się, jak uczynić by Ubuntu jak najrzadziej odwoływał się do dysku by nie budzić go zbyt często, uzupełnię ten opis. Tu można zdziałać z ekstremalnie opóźnionymi zapisami na dysk, przechowywaniem większej ilości danych w pamięci (np. preload.d dla plików uruchamialnych i bibliotek). Szczególnie ciekawą z technicznego punktu widzenia opcją, z jaką się spotkałem, to "położenie" (przy użyciu unionfs) systemu plików trzymanego w pamięci RAM na drzewie katalogów /var/log. W tym wypadku nawet częste zapisy do logów nie wywołują zapisów na dysk, wszystko odbywa się w pamięci. Jednak w razie powieszenia systemu lub awarii zasilania wolę zachować informacje z logów.
Większość opisów instalacji Linuksa na kartach pamięci lub pendrivach te kwestie podejmuje, zatem warto się zainteresować.
Kroki konfiguracji
Pierwsza “paczka”
apt-get install mercurial etckeeper mc linux-igd transmission-cli transmission-daemon squid3 dhcp3-server traceroute
Zauważcie że nigdzie, w przeciwieństwie do innych dokumentów instalacji czy konfiguracji Ubuntu czy innych systemów linuksowych, nie dodaję sudo przed komendami. W takim “ciągu” wydawanych komend administracyjnych wolę odpalić basha z uprawnieniami roota, tj.
sudo bash
Ale oczywiście należy pamiętać, by pracę na koncie administratora zredukować do minimum! Tyczy się to także użytkowania Windows. Gdyby wszyscy tego przestrzegali już od premiery Windows XP, swiat byłby dziś znacznie lepszy. ;)
Etckeeper
Przekonfigurować etckeeper na Mercurial (korzystam z hg na co dzień, zatem dla mnie jest to bardziej znajome narzędzie, niż bzr).
Odkomentować opcję w /etc/etckeeper/etckeeper.conf:
VCS="hg"
zamiast domyślnej
VCS=”bzr”
Serwer DNS
Plik /etc/bind/named.conf.options
Odkomentować forwarders, wstawić adresy ip serwerów DNS dostawcy połączenia internetowego, u mnie:
forwarders {
62.179.1.63; 62.179.1.62;
};
Restart serwera
/etc/init.d/bind9 restart
(choć może wystarczyłby reload, tę opcję zalecam częściej, by nie przerywać działania usług tylko dla zmiany w pliku konfiguracyjnym. Z tego co wiem, większość usług, przynajmniej tych popularnych, interpretuje wysłanie sygnału SIGHUP jako rozkaz przeładowania konfiguracji)
Resolver
W /etc/resolv.conf dodać serwer lokalny, 127.0.0.1 do DNSów, przed pozostałymi już ustawionymi (w czasie konfiguracji DHCP przy instalacji serwera),
nameserver 127.0.0.1
Sprawdzić działanie forwardowania DNS:
- Uruchomić komendę dig google.com dwukrotnie
- Za drugim razem, w odpowiedzi, linijka ;; SERVER: będzie zawierała 127.0.0.1#53. Jeśli nie, coś jest nie tak, RTFM! ;)
Denyhosts
Jeśli nasz serwer jest bombardowany próbami zalogowania na losowe konta poprzez SSH, dobrze jest mieć denyhosts, który automatycznie będzie namolne maszyny blokował po kilku nieudanych próbach.
apt-get install denyhosts
Domyślna konfiguracja jest całkiem w porządku, choć daemon jest ustawiony tak, by monitorować nowych upierdliwych “gości” co 30 sekund. W tym czasie zdąży taki wykonać przynajmniej kilkanaście prób zalogowania, a nie chcemy zaśmiecania logu. W pliku /etc/denyhosts.conf przestawiłem tym samym ten czas na 10 sekund:
DAEMON_SLEEP = 10s
Zakładając że sami nie będziemy próbowali za często logować się na konta które na naszym serwerze nie istnieją, można nieco ostrzej reagować na takie “ataki”, zmniejszając liczbę tolerowanych prób do 2
DENY_THRESHOLD_INVALID = 2
Myślę że kolekcjonować blokowanych adresów na dłużej niż 3 dni nie ma potrzeby:
PURGE_DENY = 3d
Zobaczymy, o ile czystsze logi będą w ciągu tygodnia. :)
Transmission Daemon
Konfigurujemy transmission-daemon. Trzeba upewnić się, że transmission-daemon jest zatrzymany, inaczej nadpisze ustawienia w /etc/transmission-daemon/settings.json
/etc/init.d/transmission-daemon stop
W pliku ustawień:
- by móc sterować za pomocą klienta webowego lub innych aplikacji sterujących zdalnych (dla Windows jest http://code.google.com/p/transmission-remote-dotnet/ )
- do rpc-whitelist po przecinku dodać adresy sieci lokalnej, u mnie 192.168.1.*
- umożliwiamy ustalanie innych ograniczeń szybkości transferów w dni robocze, gdy nikogo nie ma w domu, by torrentów nie pobierać z pełną prędkością cały dzień, utrudniając działanie innych usług sieciowych
- "alt-speed-enabled" na true
- "max-peers-global" na 100
- "peer-socket-tos" na 32 - później spróbujemy na firewallu ustawiać priorytet pakietów bittorrentowych na niski, by nie zakłócać działania innych usług
- "preallocation" na 0 - domyślnie przy pobieraniu torrenta od razu rezerwowane jest miejsce na dysku na całą jego zawartość, ustawiamy na 0, jeśli tego nie chcemy
- "rpc-password" na "transmission" - bo nie potrzebujemy mocnych zabezpieczeń, jeśli mamy sterować zdalnie tylko z sieci lokalnej
- "speed-limit-down-enabled" na true
- "speed-limit-up-enabled" na true
- "upload-slots-per-torrent" na 10, albo wedle preferencji
Logowanie startu systemu
W /etc/default/bootlogd opcję BOOTLOGD_ENABLE ustawić na Yes
Może się przydać.
Linux Internet Gateway Daemon
linux-igd to usługa uPNP, umożliwiająca ustawianie przez aplikacje sieciowe przekierowania portów z najbliżej położonej bramki internetowej/firewalla. uPNP wykorzystuje Skype, uTorrent, do ustawiania portów sieciowych dla nasłuchiwania ruchu przychodzącego.
W /etc/default/linux-igd
- EXTIFACE na interfejs sieciowy zewnętrzny, prowadzący do internetu, u mnie
EXTIFACE=eth0
- INTIFACE na interfejs sieciowy sieci lokalnej, u mnie
INTIFACE=eth1
Można zrestartować serwer lub przeładować konfigurację:
/etc/init.d/linux-igd restart
Firewall
Korzystamy z domyślnie instalowanego ufw – uncomplicated firewall. Jest prosty w użyciu i jest standardową opcją we wszystkich Ubuntu, to jego dwie niezaprzeczalne zalety.
W pliku /etc/default/ufw - do IPT_MODULES dodać moduł nf_conntrack_netbios_ns, zatem u mnie:
IPT_MODULES="nf_conntrack_ftp nf_nat_ftp nf_conntrack_irc nf_nat_irc nf_conntrack_netbios_ns"
Konfigurujemy NAT wg oficjalnej dokumentacji:
- w /etc/default/ufw DEFAULT_FORWARD_POLICY na "ACCEPT"
- odkomentowujemy w /etc/ufw/sysctl.conf linijkę net/ipv4/ip_forward=1
- odkomentowujemy w /etc/ufw/sysctl.conf linijkę net/ipv6/conf/default/forwarding=1
- w /etc/ufw/before.rules dodajemy następujący kod, przed sekcją *filter
# nat Table rules
*nat
:POSTROUTING ACCEPT [0:0]
# Forward traffic from eth1 through eth0.
-A POSTROUTING -s 192.168.0.0/24 -o eth0 -j MASQUERADE
# don't delete the 'COMMIT' line or these nat table rules won't be processed
COMMIT
Ta konfiguracja zakłada że chcemy przekierowywać ruch z sieci lokalnej z interfejsu eth1 na interfejs zewnętrzny, eth0.
Maskę adresów ip należy zmienić na odpowiednią, u mnie 192.168.1.0/24.
Otwieramy porty usług
Aby po włączeniu firewalla można było się łączyć na SSH z wewnątrz i zewnątrz:
ufw allow ssh
Odpalamy firewall:
ufw enable
Dodać regułę zezwalającą na wysyłanie zapytań od DNS z sieci lokalnej
ufw allow from 192.168.1.0/24 to any app bind9
Dodać regułę zezwalającą na połączenie SMB komputerów Windows do udziałów udostępnionych na serwerze
ufw allow from 192.168.1.0/24 to any app samba
Otwieramy port do zarządzania transmission-daemonem z zewnątrz
ufw allow from 192.168.1.0/24 to any port 9091
Aplikujemy reguły tradycyjnie komendami:
ufw disable && ufw enable
SQUID
Ustawiamy SQUID jako proxy przezroczysty, tj. przekierowujący każde odwołanie HTTP na port 80 z sieci wewnętrznej na port własny, domyślnie 3128, tym samym przechowując w pamięci podręcznej wszystkie statyczne pliki przychodzące z internetu - przy kilku komputerach w sieci daje to dość zauważalną poprawę szybkości działania odwiedzanych przez domowników stron.
Tutaj edytujemy plik /etc/squid3/squid.conf
W sekcji acl dodajemy:
acl localnet src 192.168.1.0/24
Odkomentowujemy linijkę
http_access allow localnet
Do linijki http_port 3128 dodajemy "transparent", bez znaków cudzysłowia, tj.
http_port 3128 transparent
Linijka cache_dir:
cache_dir aufs /var/spool/squid3 500 16 256
- aufs to asynchroniczny "system plików", operacje na plikacj pamięci podręcznej nie będą blokowały głównego procesu squid, co może poprawić wydajność
- 500 - rozmiar pamięci podręcznej w megabajtach
- 16 i 256 to odpowiednio liczba podkatalogów pierwszego i drugiego poziomu w drzewie katalogów pamięci podręcznej, może tak pozostać, nie ma większego znaczenia w naszych zastosowaniach
maximum_object_size zwiększamy do 30000 KB - w takim maksymalnym dopuszczalnym rozmiarze obiektu przechowywanego zmieszczą się już wszelkie pliki aktualizacji, np. firefoksa, co dla kilku komputerów może znacząco poprawić wydajność sieci
Logformat - parametr ustawiający format, w jakim będzie wypełniany plik log dostępny w /var/log/squid3/access.log:
logformat custom %>a [%tl] "%rm %ru HTTP/%rv" %Hs %<st %Ss:%Sh
Ten jest bardziej czytelny od domyślnego, ale domyślny może być czytany przez standardowe logparsery, o ile chcemy takich używać, zatem wedle uznania
Konieczne jest ustawienie na firewallu przekierowania odwołań do serwerów internetowych na porty 80, na serwer Squid, port 3128, zatem dodajemy w regule *nat w /etc/before.rules, za -A POSTROUTING liniki
# Forward port 80 requests to transparent squid proxy
-A PREROUTING -i eth1 -p tcp -m tcp --dport 80 -j DNAT --to-destination 192.168.1.2:3128
Zostawiłem komentarz dla zachowania czytelności pliku konfiguracyjnego.
Tu 192.168.1.2 to adres serwera w sieci wewnętrznej, jednak nie ustawiliśmy go jeszcze.
Serwer DHCP
Najlepiej by komputery w wewnętrznej sieci nie wymagały żadnych ustawień sieciowych, zatem dobrze jest ustawić usługę DHCP, by wszystkie potrzebne parametry przekazał serwer.
W /etc/dhcp3/dhcpd.conf
option domain-name-servers 192.168.1.2;
Każdy komputer otrzyma informację, iż pod tym IP jest serwer nazw domenowych. Można wedle uznania dodać też awaryjnie serwery dostawcy internetowego
subnet 192.168.1.0 netmask 255.255.255.0 {
range 192.168.1.100 192.168.1.240;
option routers 192.168.1.2;
}
Tym samym serwer DHCP będzie przydzielał komputerom adresy z podanych zakresów ip, a jako bramkę internetową poda 192.168.1.2.
Przydatną opcją jest też możliwość przydzielania na stałe numerów IP konkretnym komputerom, a raczej ich kartom sieciowym.
Za to odpowiedzialna jest sekcja host
host dev {
hardware ethernet 00:1B:FC:70:CF:D3;
fixed-address 192.168.1.69;
}
Przydzieliłem tym samym komputerowi z kartą sieciową o podanym MACu stały numer 192.168.1.69.
Choć dla przekierowania portów większość "nowoczesnych" aplikacji stosuje usługi uPNP i NAT-PMP, a tę pierwszą nasz serwer udostępnia, czasem przydaje się jednak przydzielenie stałego numeru wybranej maszynie lub kilku oraz ustawieniu dla nich przekierowania portów na stałe.
Uruchamiamy ponownie serwer dhcp:
/etc/init.d/dhcp3-server restart (tradycyjnie, powinien wystarczyć reload)
Konfiguracja interfejsów sieciowych
Ustawiamy ostateczne adresy ip serwera dla wewnętrznej i zewnętrznej sieci
W /etc/network/interfaces
- dla eth0 zostają domyślne, gdyż serwer będzie otrzymywał numer IP publiczny od modemu kablowego
- dla eth1:
auto eth1
iface eth1 inet static
address 192.168.1.2
netmask 255.255.255.0
Restartujemy sieć:
/etc/init.d/networking restart
Teraz najlepiej zrestartować serwer, by sprawdzić, czy wszystko dobrze funkcjonuje od momentu startu serwera.
reboot
Teraz można przepiąć kabel sieciowy do karty interfejsu wewnętrznego.
iTunes media server – Firefly
apt-get install libid3tag0 mt-daapd
Otwieramy port serwera mediów dla sieci wewnętrznej
ufw allow from 192.168.1.0/24 to any port 3689
I aktualizujemy ustawienia firewalla
ufw disable && ufw enable
Tworzymy użytkownika media, opcja -m każe utworzyć katalog domowy.
useradd media -m
Zakładamy katalog /home/media/music
mkdir /home/media/music
chmod 777 /home/media/music - uprawnienia do modyfikacji katalogu dla wszystkich
Dodajemy katalog /home/media/music do udziałów Samba, by był dostępny do zapisu dla maszyn Windows
[media]
path = /home/media/music
guest ok = yes
writable = yes
comment = iTunes Media Folder
Przeładowujemy konfigurację serwera Samba:
/etc/init.d/samba reload
Teraz można wejść z dowolnej maszyny Windowsowej do katalogu media na serwerze i wgrać biblioteczkę muzyki.
W panelu administracyjnym, dostępnym pod http://ip_serwera:3689 (user: admin, hasło mt-daap) ustawiamy stosowne opcje, /home/media/music jest ustawiony domyślnie.
W Server Status konsoli Firefly odpalamy Start Full Scan, by odnalazł nasze utworki. Gdy uruchomimy iTunes, serwer Firefly powinien się pojawić jako jedno ze źródeł muzyki.
Można ustawić użytkowników i hasła dla serwera mediów, ale ... ufamy współlokatorom jako tako. ;)
Robimy z serwera wieżę: Music Player Daemon ;)
Ta usługa działająca na serwerze pozwala odtwarzać bezpośrednio z niego muzykę, natomiast sterować nim można za pomocą szeregu aplikacji klienckich, także dla Windows, Windows Mobile czy iPhone/iPod Touch.
Już wkrótce!
Na koniec
Być może stawianie pełnych serwerów DHCP i DNS dla niewielkiej domowej sieci to nieco za dużo, powinien wystarczyć znacznie mniej rozbudowany dnsmasq, spełniający funkcję prostego cache DNS i serwera DHCP.
Jeżeli macie uwagi merytoryczne, szczególnie z punktu widzenia bezpieczeństwa systemu, ale i zasad administracji systemami linuksowymi, proszę o komentarze. Nie jestem szczególnie zaawansowanym użytkownikiem linuksa, nie jest to moja działka, chcę po prostu działający domowy serwer o dość szerokim spektrum zastosowań, których raczej proste "sieciowe kieszenie na dyski" nie spełnią.
