Zamaskowany LAN

Internet
kasia szymczak
Zastosowania: Internet przez SDI w sieci lokalnej
Zamaskowany LAN
Łącza stałe są w naszym kraju wręcz nieprzyzwoicie drogie.
Horrendalne koszty dostępu do Internetu można nieco zmniejszyć, instalując SDI. Jak jednak podzielić w tym przypadku
wydatki związane z dostępem do Sieci pomiędzy kilka osób?
DI (Szybki Dostęp do Internetu) to
usługa ciesząca się dużym zainteresowaniem abonentów naszego największego
operatora sieci telekomunikacyjnych. SDI
wykorzystuje technologię firmy Ericsson
o nazwie HIS (Home Internet Solution).
System ten pozwala na użycie istniejącego
łącza telefonicznego do połączenia się z Internetem. Jednocześnie możliwe jest korzystanie z tradycyjnego aparatu telefonicznego.
Dokładniejsze informacje na temat działania
SDI można znaleźć w CHIP-ie nr 1/2000.
W tym artykule przedstawię rozwiązanie,
dzięki któremu użytkownicy komputerów połączonych w niewielką sieć lokalną będą mogli korzystać z Internetu za pośrednictwem
jednej maszyny dysponującej łączem SDI.
Niektóre zadania związane z tym problemem
można zrealizować, używając na przykład
komputera pracującego pod kontrolą systemu
Windows 98. Pełną obsługę usług internetowych w LAN-ie uzyskamy jednak dopiero za
pomocą Okien klasy NT. My skorzystamy
z Linuksa. System ten pozwala na udostępnienie w sieci lokalnej wszystkich usług oferowanych za pośrednictwem SDI. Dodatkową
S
188
zaletą Linuksa w stosunku do systemów komercyjnych jest fakt, iż jest on darmowy.
Instalacja terminala
Terminal SDI dostarczany do klienta ma wymiary typowego modemu zewnętrznego. Jest
on podłączany do portu szeregowego komputera przez zwykły kabel RS232. Urządzenie
wyposażone jest, rzecz jasna, w gniazda do
podłączenia sieci telefonicznej oraz aparatu
abonenckiego. Jeżeli podłączymy telefon
przed modemem SDI, nie będzie on działał.
Instalacja terminala SDI nie powinna nastręczać problemów. Wystarczy podłączyć go
do sieci telefonicznej i komputera. Po włączeniu zasilania i uruchomieniu urządzenia następuje jego synchronizacja z siecią telefoniczną, co sygnalizują odpowiednie kontrolki
świecące się na panelu terminala. Należy zauważyć, że w razie zaniku zasilania telefon
działa nadal – terminal jest dla niego w tym
przypadku „przezroczysty”.
Możemy teraz przystąpić do zestawienia
połączenia internetowego. Operator dostarcza wraz z urządzeniem sterowniki przeznaczone dla systemu Windows. Nie będą nam
one potrzebne. Obsługa terminala SDI przez
system operacyjny nie różni się bowiem prawie niczym od korzystania ze zwykłego modemu podłączanego do złącza szeregowego.
Do zainstalowania SDI możemy wykorzystać dowolną dystrybucję Linuksa. Nawet jeśli użyjemy jednodyskietkowej edycji
systemu o nazwie Polopiryn, otrzymamy
system w zupełności wystarczający do pracy z dowolnym modemem, np. SDI. Oferuje on realizację takich mechanizmów, jak
połączenie PPP (Point-to-Point Protocol)
czy translacja adresów za pomocą dynamicznej usługi NAT (Network Adress
Translation). Konfiguracja tej minidystrybucji jest bardzo prosta i ogranicza się do
udzielenia odpowiedzi na kilka pytań procedury instalacyjnej.
Nie będziemy się zajmowali wspomnianą
dystrybucją właśnie z powodu jej ścisłej specjalizacji. Rozwiązanie to jest idealne, jeżeli
chcemy podłączyć SDI do pojedynczego
komputera. Będzie on wtedy realizował tylko połączenie PPP czy ewentualnie translację adresów albo zaporę ogniową (firewall).
W tym przypadku możemy użyć nawet archaicznego peceta z procesorem 80386. Jedynym wymogiem jest wyposażenie maszyny
w co najmniej 8 MB pamięci RAM i odpowiednio szybki port szeregowy (oparty na
układzie UART 16550 lub nowszym). Jeżeli
marzy nam się np. serwer poczty elektronicznej, WWW czy proxy, musimy zastosować
mocniejszy komputer z odpowiednio pojemnym dyskiem twardym.
Konfiguracja Linuksa
Pierwsza rzecz, jaką musimy zrobić, to
sprawdzenie, do którego portu szeregowego
podłączony jest nasz terminal. Następnie odszukujemy w umowie dotyczącej świadczenia usługi SDI przydzielony nam adres IP,
login i hasło. Wszystko to powinniśmy znaleźć na drugiej stronie tego dokumentu,
w paragrafie drugim. Możemy teraz przystąpić do utworzenia odpowiednich skryptów
i skonfigurowania demona pppd. Odpowiada
on za obsługę protokołu PPP.
Zanim ustawimy parametry systemu, dobrze jest się upewnić, czy mamy zainstalowany pakiet pppd. Do prawidłowego działania
wymaga on, aby jądro zawierało mechanizmy
korzystania z PPP. Służy do tego opcja PPP
(point-to-point) support w konfiguracji kernela. Jeżeli mamy do czynienia z jądrem dostarczonym wraz z dystrybucją Linuksa, prawie
na pewno zostało ono skompilowane z włączoną obsługą protokołu PPP.
Następnie w pliku /etc/ppp/pap-secrets
wpisujemy znaleziony w umowie login, hasło oraz IP w podanym niżej formacie:
login * has‡o IP
Jeśli na dysku naszej maszyny w ogóle nie
ma wspomnianego katalogu, pakiet pppd
STYCZEŃ 2001
Internet
Zastosowania: Internet przez SDI w sieci lokalnej
STYCZEŃ 2001
Po dokonaniu opisanych czynności wydajemy z konta roota polecenie powodujące
nawiązanie połączenia internetowego:
pppd /dev/ttyS0
Początkującym użytkownikom Linuksa wyjaśnię dodatkowo, że ttyS0 odpowiada pierwszemu portowi szeregowemu (nazywanemu
zazwyczaj COM1). Jeśli terminal w naszym
systemie jest przyłączony do innego portu, należy podać odpowiednią nazwę urządzenia
(np. ttyS1 dla COM2). Działanie połączenia
możemy sprawdzić np. za pomocą polecenia:
Jeżeli otrzymamy odpowiedź od serwera
ICM, oznacza to, że mamy upragniony dostęp do Sieci.
Automatyczne połączenie
po starcie systemu
Ponieważ chcemy mieć stałe połączenie
z Internetem, warto tak skonfigurować maszynę, aby było ono nawiązywane podczas
uruchomiania systemu. Pozwoli to np. na
automatyczny start serwera pocztowego czy
WWW po awarii zasilania.
Funkcję samoczynnego łączenia naszego
komputera z Siecią możemy zrealizować na
kilka sposobów. Najprostszy to dopisanie
wywołania pppd do jednego ze skryptów
startowych systemu. W dystrybucji Red Hat
jest to plik /etc/rc.d/rc.local, w Debianie –
/etc/rc.boot.
Inną metodą jest skorzystanie ze specjalnego mechanizmu zastosowanego w większości dystrybucji. W katalogu /etc/ppp znajdziemy mianowicie plik no_ppp_on_boot.
Gdy zmienimy jego nazwę na ppp_on_boot,
podczas uruchamiania systemu zostaną wykonane zawarte w zbiorze polecenia (np.
wywołanie pppd). Jeżeli plik ten nie jest wykonywalny, system będzie uruchamiał pppd
z opcjami zawartymi w pliku /etc/ppp/
peers/provider. Zawartość tego ostatniego
zbioru tworzymy, posługując się identyczną
składnią jak w przypadku pliku options. Dodatkowo należy w nim umieścić linię definiującą urządzenie modemu (czyli np. w
Sieć lokalna z dostępem do Internetu
IP1
host 1
(IP1)
router
(IPr)
dan
e1
IPr port 1 dane 1
IPr port n dane n
łącze SDI
e2
dan
IP2
host 2
(IP2)
n
IP1 <–––> port 1
ne
Ustawienia te mają następujące znaczenie:
n 115200 – szybkość połączenia wyrażona
w bitach/s.;
n modem – włącza używanie linii kontroli
modemu;
n defaultroute – dodaje do systemowych tabel routowania domyślną trasę, używaną po
starcie interfejsu;
n noipdefault – wyłącza domyślne zachowania w razie braku lokalnego adresu IP.
W tym przypadku IP musi zostać przekazane przez serwer providera podczas negocjacji obu hostów;
n lock – ustawia plik lock dla danego urządzenia (portu);
n crtscts – włącza sprzętową kontrolę linii
RTC/CTS;
n noauth – wyłącza identyfikację;
n user <login> – nazwa użytkownika dla
identyfikacji przy użyciu PAP (<login> jest
identyczny z podanym w umowie z TP S.A.);
n persist – powoduje, że po przerwaniu połączenia program pppd nie zakończy działania,
tylko spróbuje utworzyć je na nowo;
n maxfail 0 – ustawia limit nieudanych połączeń, po przekroczeniu którego pppd zaprzestanie prób ponownego nawiązania łączności. Wartość zero oznacza brak ograniczeń;
nameserver 194.204.152.34
nameserver 194.204.159.1
ping news.icm.edu.pl
IP2 <–––> port 2
da
115200
modem
defaultroute
noipdefault
lock
crtscts
noauth
user <login>
persist
maxfail 0
lcp-echo-interval 20
lcp-echo-failure 5
n lcp-echo-interval 20 – pppd będzie co 20
sekund wysyłać do serwera tzw. ramkę żądań LCP. W połączeniu z opcją lcp-echo-failure ustawienie to jest używane przez mechanizm wykrywający zerwanie połączenia;
n lcp-echo-failure 5 – jeżeli serwer, z którym
się łączymy, nie odpowie na pięć żądań tzw.
echa LCP (patrz: opcja lcp-echo-interval),
pppd przerwie połączenie. W naszym wypadku jest to potrzebne, gdyż czasami łącze SDI
się zawiesza. W takiej sytuacji pppd przerwie
połączenie i wznowi je dzięki opcji persist.
Na zakończenie konfiguracji pppd należy
zadbać o poprawne wpisy w pliku /etc/resolv.conf. Definiują one używane DNS-y. Jeżeli nie mamy własnego serwera nazw, możemy wpisać w zbiorze resolv.conf adresy
maszyn naszego dostawcy usług:
IP
n
prawdopodobnie nie został w zainstalowany
systemie.
Należy pamiętać, że wszystkie pliki *-secrets powinny mieć prawa dostępu ustawione
na 600. Ich właścicielem musi być w takim
razie użytkownik root z grupy root. W przeciwnym przypadku będziemy wprawdzie mogli pracować, ale przy każdej inicjacji połączenia PPP otrzymamy komunikaty o nieprawidłowych prawach dostępu. Gdy pojawią
się jakiekolwiek problemy z połączeniem,
najlepiej zajrzeć do dzienników (logów) systemowych. Znajdują się w nich informacje
o wszelkich ewentualnych nieprawidłowościach w działaniu systemu i usług. Odpowiednie informacje znajdziemy w plikach
/var/log/syslog i /var/log/messages.
Kolejnym krokiem jest umieszczenie
w zbiorze /etc/ppp/options parametrów wywołania programu pppd. Zaoszczędzi nam
to każdorazowego wpisywania tych opcji
podczas uruchamiania pppd. Omawiany
zbiór konfiguracyjny powinien mieć w naszym przypadku postać:
IPn <–––> port n
host n
(IPn)
Tablica NAT
Jednym z najlepszych rozwiązań, jeśli chodzi o korzystanie z Internetu w sieci lokalnej, jest tzw.
maskarada. Polega ona na wykorzystaniu jednego adresu IP do obsługi wielu lokalnych maszyn.
Kontaktują się one z hostami sieciowymi za pośrednictwem portów routera.
189
190
Internet
Zastosowania: Internet przez SDI w sieci lokalnej
/dev/ttyS0). Jest to konieczne, gdyż w opisywanym przykładzie pppd będzie uruchamiane poleceniem pppd call provider. W tym
przypadku domyślnym położeniem pliku
provider jest katalog /etc/ppp/peers, ale
oczywiście możemy podać pełną ścieżkę do
zbioru.
Jeżeli używamy innej dystrybucji, należy
sprawdzić jej lokalną konfigurację. Można
też samodzielnie napisać skrypt, który sprawdzi, czy istnieje plik ppp_on_boot, i uruchomi
pppd z odpowiednimi opcjami, np.:
if [ -f /etc/ppp/ppp_on_boot]
then
if [ -x /etc/ppp/ppp_on_boot ]
then
/etc/ppp/ppp_on_boot
else
/usr/sbin/pppd call provider
fi
fi
Polecenia te warto dopisać do pliku rc.local
lub utworzyć nowy skrypt i umieścić go w katalogu /rc (szczegółowe informacje na ten temat znajdziemy też w dokumentacji naszej
dystrybucji).
SDI a LAN
Gdy nasze połączenie już funkcjonuje, warto się zastanowić, jak wykorzystać nasz serwer do udostępnienia Internetu innym komputerom w niewielkiej sieci lokalnej. Możemy tego dokonać, używając funkcji dynamicznej translacji adresów (NAT), czyli maskarady. Mechanizm ten jest wbudowany
w jądro Linuksa.
Jak działa NAT? Maskarada wymaga
dwóch interfejsów sieciowych, na przykład
ppp0 odpowiadającego terminalowi SDI
i eth0 karty sieciowej. Interfejs eth0 najlepiej
skonfigurować, przydzielając mu numer IP
z puli adresów prywatnych (inaczej: nieroutowalnych). Są to wszystkie adresy, których nie przekazują routery internetowe
(patrz: ramka „Numery IP w praktyce”).
Komputer wykonujący dynamiczną
translację adresów umożliwia wielu maszynom z sieci lokalnej korzystanie z sieci zewnętrznej (w tym przypadku z Internetu).
Dla komputera spoza naszego LAN-u wygląda to tak, jakby wszystkie połączenia
pochodziły z jednego adresu IP. Dzieje się
tak dzięki temu, że wszystkie pakiety kierowane do Internetu przez komputery z sieci
lokalnej ulegają translacji. Adresy źródłowe naszych maszyn są zamieniane na jeden
adres internetowy.
W jaki więc sposób serwer identyfikuje pakiety trafiające z Internetu do LAN-u? Otóż
wykorzystywany jest w tym przypadku mechanizm portów (protokoły UDP i TCP).
Każdemu połączeniu jest przydzielany osobny port. Jeżeli serwer odbierze z Internetu
pakiet adresowany do danego portu, na podstawie odpowiednich (dynamicznych) tablic
dane są kierowane do odpowiedniego komputera w sieci lokalnej.
Problemy zaczynają się, gdy podczas połączenia wykorzystuje się kilka portów. Ma
to miejsce np. gdy korzystamy z serwerów
FTP. Inną kłopotliwą sytuacją jest używanie przez komputery w sieci lokalnej protokołu niższej warstwy niż TCP/IP, takiego
jak ICMP (wykorzystywanego m.in. przez
polecenie ping). W wymienionych przypadkach konieczne jest stosowanie dodatkowych mechanizmów, którymi nie będziemy
się tu zajmować. Obsługę takich sytuacji zapewniają nam odpowiednie moduły jądra
systemowego.
Adresy internetowe
Maskarada sieci
Numery IP w praktyce
Gdy już mamy skonfigurowaną kartę sieciową, należy skompilować jądro z obsługą
zapory ogniowej i maskarady. W tym celu
podczas konfiguracji kernela włączamy
opcje IP: firewalling, IP: masquerading, IP:
ICMP masquerading, IP: masquerading special modules support oraz Dummy net driver
support. Po skompilowanu jądra i ponownym uruchomieniu systemu możemy przystąpić do konfiguracji maskarady.
Aby system wykonywał filtrację pakietów
i translacje adresów, konieczne jest użycie
narzędzia ipchains (dla jąder z serii 2.2).
Nie będę tu opisywał pełnej składni tego
programu, gdyż w Sieci z łatwością można
znaleźć jego obszerną dokumentację (patrz:
ramka „Info”). W naszym, najprostszym
przypadku wystarczą dwa polecenia:
Dzięki temu, że router naszego dostawcy
Internetu nie rozpowszechnia w Sieci adresów określonego typu (tzn. adresów nieroutowalnych), możemy ich używać w sieci
lokalnej. Wymaga to operacji translacji
(maskarady) numerów IP z sieci wewnętrznej. Ponieważ w naszej sieci nie bedziemy
mieli wielu komputerów, wystarczy nam
adres z tzw. klasy C (ostatni bajt adresu
oznacza numer maszyny). W naszym przykładzie interfejs eth0 (czyli router z linuksem) może mieć np. adres 192.168.255.1
przy masce 255.255.255.0 i adresie rozgłoszeniowym (broadcast) 192.168.255.255.
Maska podsieci określa, która część adresu określa numer sieci, a która definiuje poszczególne maszyny. Reszcie komputerów
z naszego LAN-u przydzielamy kolejne adresy IP (do dyspozycji w opisywanym przypadku pozostają 253 adresy).
190
ipchains -P forward DENY
ipchains -A forward -b
-s 10.0.0.0/8 -d 0.0.0.0/0
-i ppp0 -j MASQ
Powyższe polecenia zawierają tzw. reguły,
określające działanie naszego serwera w odniesieniu do pakietów przychodzących (input), wychodzących (output) oraz przekazywanych (forward). Zachowanie programów filtrujących pakiety może być określone przez tzw. reguły. Regułami mogą być
słowa:
n DENY – odrzucenie pakietu;
n REJECT – podobnie jak DENY, lecz wysyłany jest pakiet ICMP informujący o odrzuceniu połączenia;
n ACCEPT – powoduje odebranie pakietu;
n MASQ – włącza maskowanie adresów (tylko w przypadku mechanizmu forward);
n REDIRECT – przekierowanie;
n RETURN – przekazanie zachowania do
kolejnej reguły.
Pierwsza z przykładowych reguł powoduje, że domyślną akcją w odniesieniu do żądania przesyłania (forward) staje się DENY, co oznacza odmowę dostępu. Drugie
polecenie powoduje dodanie (opcja -A) nowej reguły do łańcucha forward. Parametr b włącza dwukierunkowy tryb działania reguły. Następnie podane są zakresy adresów
źródłowych (-s) i docelowych (-d). W tym
przypadku numery IP są zapisane w formacie adres/maska, przy czym maska ma format skrócony – wartość po ukośniku („/”)
określa liczbę jedynek w masce. Tak więc
zapis /8 odpowiada masce 255.0.0.0. Następnie podany jest interfejs, przez który
będą wysyłane i odbierane pakiety. Ostatnia
opcja (-j) określa mechanizm, do którego
odnosi się reguła – w tym przypadku jest to
MASQ, czyli dynamiczna translacja adresów (maskarada).
Jak już wcześniej wspomniałem, należy
pamiętać o modułach ip_masq_*. Powinny
one się znajdować w katalogu /lib/modules/nr_wersji_kernela/ipv4. Są to m.in.:
n ip_masq_cuseeme.o – dla mechanizmu
CU-SeeMe broadcasts;
n ip_masq_ftp.o – dla protokołu FTP. Moduł
ten jest niezbędny, gdyż FTP wymaga użycia
dwóch portów;
n ip_masq_irc.o – dla usługi IRC;
n ip_masq_quake.o – moduł dedykowany dla
gry Quake;
n ip_masq_raudio.o – RealAudio;
n ip_masq_vdolive.o – VDOLive.
Jeżeli moduły nie są przez jądro ładowane
automatycznie, należy to zrobić ręcznie za
pomocą polecenia insmod. W tym celu
z konta roota trzeba wydać polecenie insmod
ip_masq_ftp.
Przedstawiona przeze mnie konfiguracja
maskarady stanowi absolutne minimum,
gwarantujące prawidłowe działanie systemu. Dodatkowo można dopisać wiele innych reguł filtracji pakietów. Przykładem
jest choćby używana przez wielu użytkowników SDI reguła, gwarantująca że system nie
będzie odpowiadał na pakiety ping (czyli na
w
pakiety icmp echo-request):
STYCZEŃ 2001
193
Internet
Zastosowania: Internet przez SDI w sieci lokalnej
ipchains -A input -p icmp
--icmp-type 8 -i ppp0 -l -j DENY
W tym przypadku wszelkie pakiety tego typu odbierane za pośrednictwem interfejsu
ppp0 będą zapisywane w logach (opcja -l)
i odrzucane przez system. Regułę tę można
dopisać do skryptów startowych lub utworzyć
oddzielny skrypt służący do jej aktywowania.
Bardzo ważną, a często zapominaną czynnością jest włączenie w kernelu opcji ip_forward. Spowoduje to, że pakiety będą przekazywane między interfejsami. Omawiany parametr aktywujemy, wpisując wartość 1 do pliku /proc/sys/net/ipv4/ip_forward. Można to
zrobić ręcznie poleceniem:
echo ’1’ >
/proc/sys/net/ipv4/ip_forward
Rozkaz ten warto dopisać do skryptów startowych, np. tuż po regułach ipchains. Część
dystrybucji Linuksa zawiera pliki konfiguracyjne, umożliwiające zdefiniowanie opisywanego parametru. W Debianie jest to np. zbiór
/etc/network/options, w którym zmienną
ip_forward ustawiamy na yes. W dystrybucji
Red Hat będzie to natomiast plik /etc/sysconfig/network (opcja FORWARD_IPV4) lub –
w nowszych edycjach systemu – /etc/sysctl.conf (net.ipv4.ip_for-ward=1). Po dokonaniu odpowiedniej modyfikacji funkcja ip_forward zostanie włączona podczas uruchamiania systemu.
Jeszcze jednym zastosowaniem ipchains
jest regulowanie aktywności użytkowników.
W przypadku gdy zarządzamy np. niewielką
siecią w bloku, może się zdarzyć, że zaistnieje potrzeba chwilowego odłączenia danego komputera od sieci. Najprościej jest wtedy po prostu zablokować mu dostęp do serwera, używając właśnie reguły ipchains:
ipchains -A input -s adres-IP-komputera -j DENY -i eth0
Aby usunąć tę regułę, wystarczy zmienić
w podanym poleceniu parametr -A (Add) na
-D (Delete). Wszystkie reguły filtrowania
możemy wyświetlić na ekranie, wydając polecenie ipchains -L.
Metodą obejścia takiego zabezpieczenia
jest zmiana numeru IP blokowanego komputera. Aby temu zapobiec, na serwerze wykonujemy tzw. statyczne mapowanie tablic
ARP. Mówiąc inaczej, na stałe przypisujemy
sprzętowy numer karty komputera do danego adresu IP. Dzięki temu w przypadku
zmiany adresu IP nie zostanie nawiązane
połączenie danej maszyny z serwerem.
Dodatkowym zabezpieczeniem może być
skonfigurowanie maskarady dla każdego
komputera oddzielnie. Zamiast podawać adres podsieci i maski wpisujemy wtedy IP poszczególnych komputerów do kolejnych reguł ipchains. Co prawda musimy wtedy użyć
STYCZEŃ 2001
kilku czy kilkanastu reguł więcej, ale wraz ze
statycznym mapowaniem ARP stanowi to
niemożliwe do obejścia zabezpieczenie. Opisane mapowanie polega na umieszczeniu
w pliku /etc/ethers adresów sprzętowych
(MAC) i logicznych (IP), np.:
#IP
10.0.0.1
10.0.0.2
Adres sprzŒtowy MAC
00:C0:DF:B0:1A:E0
00:C0:DF:A3:21:B2
Adresy sprzętowe komputerów w sieci uzyskamy, wydając na serwerze polecenie arp -a.
Jeżeli nie dostaniemy w ten sposób adresów
wszystkich komputerów, należy posłużyć się
poleceniem ping w odniesieniu do danej maszyny. Następnie po wydaniu polecenia arp -i
eth0 -f /etc/ethers system na stałe przypisze adresy sprzętowe do numerów IP. Podanie nazwy zbioru z adresami jest konieczne tylko
wtedy, gdy jest to plik inny niż /etc/ethers.
Ergonomia stanowiska pracy
Gdy mamy już działającą własną sieć z uruchomioną maskaradą, warto zatroszczyć się
o nieco większy komfort pracy naszych użytkowników. Jednym z problemów, na jakie
możemy się natknąć, jest to, że serwery IRC
nie pozwalają wielokrotnie logować się użytkownikowi korzystającemu z danego IP. Jest
to normalna praktyka administratorów tych
maszyn. Pomóc tu może załadowanie modułu
ip_masq_irc oraz zadbanie o to, aby użytkownicy z sieci wewnętrznej byli odpowiednio
identyfikowani. Identyfikacja przebiega poprawnie, gdy na serwerze realizującym maskaradę działa usługa ident (demon identd).
W naszej przykładowej sieci identd musi
„umieć” identyfikować komputery obsługiwane przez maskaradę. W praktyce dobrze z zadaniem tym radzi sobie program oident.
W większości przypadków wystarczy zainstalować pakiet oident i sprawdzić, czy uruchamia się on z opcją -m. Aplikacja ta przekazuje żądania identyfikacji do komputerów w maskaradowanej sieci. Jeżeli oident nie uzyska
odpowiedzi na to żądanie (nie wysyłają jej np.
maszyny pracujące pod kontrolą Windows),
sprawdza zawartość pliku /etc/oidentd.users.
Zbiór ten ma następujący format:
#IP/MASKA
10.0.0.2
10.0.0.3
nazwa
user1
user2
system
UNIX
WINDOWS
Więcej informacji znajdziemy w dokumentacji oidenta. Jeżeli chodzi o inne usługiw Sieci znajdziemy specjalne moduły do jądra, umożliwiające używanie np. ICQ na
komputerze w sieci lokalnej.
Jeśli w naszej sieci lokalnej pracuje kilka czy
kilkanaście osób korzystających z WWW czy
FTP, warto się pokusić o zainstalowanie serwera proxy. Będzie on zapisywał w pamięci
podręcznej strony internetowe czy pliki z serwerów FTP. Dzięki temu zmniejszymy obcią-
żenie łącza, gdyż powtórny odczyt danych nastąpi z dysku serwera. W naszym wypadku
dobrym rozwiązaniem byłby program squid.
Jego konfiguracja jest dosyć złożona i nie będziemy jej tu omawiać. Informacje potrzebne
do zainstalowania serwera proxy znajdziemy
w dokumentacji squid oraz w Internecie.
Jeżeli mamy w sieci lokalnej kilku użytkowników lub zamierzamy zarejestrować własną
domenę, przyda nam się serwer DNS. Nawet
jeżeli nie mamy własnej domeny, nieco przyśpieszy on tłumaczenie adresów. Najpopularniejszym linuksowym pakietem zawierającym
name-server jest bind. Opis jego konfiguracji
znajdziemy w odpowiednim HOWTO (DNS-HOWTO). Należy przy tym zwrócić uwagę
na sposób, w jaki nasz dostawca Internetu nadaje nazwy domenowe urządzeniom połączonym z Siecią przez SDI. Nawet jeśli wykupimy własną domenę, np. www.firma.pl, po odwołaniu do naszego serwera za pomocą numeru IP otrzymamy adres typu p<kolejny numer>.miasto.sdi.tpnet.pl. Jeżeli mamy zamiar
uruchomić tylko serwer WWW, nie będzie to
miało większego znaczenia. W przypadku jednak, gdy czasami używamy SSH czy FTP, może się zdarzyć, że nasze połączenia będą odrzucane przez hosty internetowe. Niektóre
serwery sprawdzają bowiem zgodność domeny z jej domeną odwrotną.
Ostatnim, bardzo ważnym aspektem konfiguracji naszego serwera jest jego bezpieczeństwo. „Dziurawy” i źle skonfigurowany serwer może bowiem stanowić niebezpieczeństwo nie tylko dla nas samych, ale też dla innych użytkowników Internetu. Dlatego warto
zadbać o wyłączenie niepotrzebnych usług,
szczególnie tych uruchamianych przez inetd.
Należy też używać jak najnowszych wersji poszczególnych komponentów systemu, zwłaszcza tych, do których można uzyskać dostęp
z zewnątrz (takich jak WWW, FTP czy poczta elektroniczna). Więcej informacji na temat
zabezpieczania serwera linuksowego można
znaleźć na s. 140 numeru 9/2000 CHIP-a.
Sebastian Sawicki
INFO
Grupy dyskusyjne
Uwagi i komentarze do artykułu:
news://news.vogel.pl/chip.artykuly
Pytania techniczne:
news://news.vogel.pl/chip.internet
Internet
JTZ
http://www.jtz.org.pl/
Klub HIS-a
http://www.his-klub.iq.pl/
Literatura
Dokumentacja Linuksa
PPP-HOWTO, IP-Masque-rade-mini-HOWTO,
Net-3-HOWTO, podręczniki systemowe (man)
Na krążku CD dołączonym do CHIP-a
1/2001 1/2001 w dziale Internet | Internet przez
SDI znajduje się minidystrybucja Polopyrin 0.1
193