Sieci komputerowe lab 2 Jacek Wiślicki, [e-mail]
Celem poniższego ćwiczenia jest zapoznanie się z narzędziami i mechanizmami konfiguracji sieci
oferowanymi przez systemy UNIXowe (w naszym wypadku Slackware Linux). y
ródło kursu jest
podane w stopce dokumentu.
Ponadto, jak w przypadku MS Windows 2000, należy sprawdzić działanie narzędzi służących
do konfiguracji I diagnostyki sieci: ifconfig, ping, arp, traceroute, route, routed, nslookup. W celu
uzyskania szczegółów dotyczących danej komendy należy skorzystać z odpowiedniej strony  manualu
(man command_name).
Uwaga: systemy UNIXowe rozróżniają wielkość liter!
1. Tworzenie interfejsów sieciowych
W wielu systemach UNIXowych urządzenia sieciowe określane są w katalogu /dev. Jednak w
przypadku Linuxa są one  tworzone dynamiczne przez oprogramowanie i nie wymagają obecności
plików urządzenia.
W większości przypadków urządzenie sieciowe jest tworzone automatycznie poprzez sterownik
urządzenia podczas jego inicjalizacji, kiedy tylko wykryje on odpowiedni sprzęt. Na przykład sterownik
urządzenia Ethernetu (karty sieciowej) tworzy kolejne interfejsy eth[0..n] w miarę, jak rozpoznaje
odpowiednie karty. Pierwsza karta ethernetowa zostaje eth0, następna eth1 itd.
Jednak w niektórych przypadkach (SLIP i PPP) urządzenia sieciowe są tworzone poprzez
działanie programu użytkownika. Ma miejsce identyczny proces numerowania, jednak urządzenia nie
są tworzone automatycznie podczas bootowania systemu. Powodem tego jest, że w przeciwieństwie do
Ethernetu, ilość aktywnych urządzeń może zmieniać się podczas pracy maszyny. Te przypadki są ujęte
w dalszej części kursu.
2. Konfiguracja interfejsu sieciowego
Kiedy wszystkie odpowiednie programy są zainstalowane i znany jest adres sieciowy i
informacje o sieci można przystąpić do konfiguracji interfejsów. Proces ten polega na przypisywaniu
odpowiednich adresów do urządzenia sieciowego i ustawianiu odpowiednich wartości innych
konfigurowalnych parametrów urządzenia. Najczęściej wykorzystywanym w tym celu programem jest
ifconfig (interface configure). Zazwyczaj stosuje się następującą składnię:
root# ifconfig eth0 192.168.0.1 netmask 255.255.255.0 up
W tym wypadku konfiguracji podlega interfejs ethernetowy  eth0 o adresie IP  192.168.0.1 i
masce podsieci  255.255.255.0 . Dyrektywa  up następująca po komendzie narzuca interfejsowi stan
aktywny, jednak zazwyczaj pomija się ją, jako że jest wartością domyślną. W celu zamknięcia
interfejsu wystarczy wywołać  ifconfig eth0 down .
Jądro zakłada pewne wartości podczas konfiguracji interfejsów. Na przykład można określić
adres sieciowy i adres rozgłoszeniowy (broadcast), jednak kiedy się ich nie poda (jak w przykładzie
powyżej), jądro dokona próby  odgadnięcia ich , zakładając, że powinny być oparte na masce podsieci.
Z drugiej strony, kiedy nie sprecyzuje się maski podsieci, wtedy jest ona zakładana na podstawie klasy
C adresu IP. W przedstawionym przykładzie jądro założyłoby, że konfigurowana jest sieć klasy C i
adres sieciowy zostałby skonfigurowany jako  192.168.0.0 natomiast adres rozgłoszeniowy jako
 192.168.0.255
Polecenie ifconfig może być użyte z dodatkowymi parametrami, z których najważniejszymi są:
up aktywuje interfejs (domyślne).
down dezaktywuje interfejs.
[-]arp włącza/wyłącza użycie protokołu ARP dla danego interfejsu.
[-]allmulti włącza/wyłącza otrzymywanie wszystkich sprzętowych pakietów
multicastowych. Multicast sprzętowy umożliwia grupom hostów
strona 1 z 9
Sieci komputerowe lab 2 Jacek Wiślicki, [e-mail]
otrzymywanie pakietów zaadresowanych do specjalnych miejsc
przeznaczenia (np. wideokonferencje), jednak zazwyczaj opcja ta jest
niewykorzystywana.
mtu N pozwala ustawić MTU (Maximum Transfer Unit) urządzenia.
netmask określa maskę podsieci do, której należy urządzenie.
irq działa tylko z niektórymi typami urządzeń i pozwala ustawić IRQ
fizycznego urządzenia.
[-]broadcast [addr] włącza/wyłącza akceptowanie datagramów przeznaczonych dla adresu
broadcastowego.
[-]pointopoint [addr] pozwala ustawić adres maszyny na drugim końcu połączenia point-to-
point (jak SLIP albo PPP).
hw ustawia adres sprzętowy (możliwe dla niektórych urządzeń sprzętowych).
Jest rzadko użyteczne w Ethernecie, jednak ma zastosowanie dla innych
typów sieci np.: AX.25.
Można używać ifconfig względem dowolnego interfejsu sieciowego. Niektóre programy
użytkownika, jak pppd lub dip, automatycznie konfigurują urządzenia sieciowe kiedy je tworzą, wtedy
użycie ifconfig nie jest konieczne.
3. Konfiguracja resolwera nazw (Name Resolver)
3.1. Wymagane informacje
Podstawową informacją jest do jakiej domeny będą należały hosty. Oprogramowanie resolwera
nazw zapewnia usługę tłumaczenia tej nazwy poprzez żądania wysyłane do DNS (Domain Name
Server), wobec czego potrzebny jest także adres IP lokalnego serwera nazw (nameserver).
Pojawiają się tutaj trzy pliki konfiguracyjne, opisane poniżej.
3.2. /etc/resolv.conf
/etc/resolv.conf jest głównym plikiem konfiguracyjnym określającym resolwer nazw. Jego
format jest bardzo prosty  plik tekstowy z pojedynczym słowem kluczowym w linii. Zazwyczaj
wykorzystuje się trzy słowa kluczowe:
domain określa nazwę lokalnej domeny.
search określa listę alternatywnych nazw domen podczas wyszukiwania nazwy
hosta.
nameserver słowo to może być używane wielokrotnie, określa adres IP serwera nazw
używanego w procesie tłumaczenia nazw.
Przykład /etc/resolv.conf może wyglądać jak poniżej:
domain maths.wu.edu.au
search maths.wu.edu.au wu.edu.au
nameserver 192.168.10.1
nameserver 192.168.12.1
Przykład ten określa domyślną nazwę domeny, którą należy dowiązać do niepełnych nazw (nazwa
hosta bez domeny)  maths.wu.edu.au, a gdy host nie jest odnaleziony w tej domenie, wymusza także
sprawdzenie domeny wu.edu.au. Dwa wpisy serwera nazw pozwalają resolwerowi na korzystanie z
dowolnego z nich.
Proszę przeanalizować przykład pliku /etc/resolv.conf na lokalnym komputerze.
strona 2 z 9
Sieci komputerowe lab 2 Jacek Wiślicki, [e-mail]
3.3. /etc/host.conf
Plik /etc/host.conf jest stosowany do konfiguracji pozycji stanowiących o zachowaniu resolwera nazw.
Format pliku jest opisany szczegółowo na stronie  manualu  resolv+ . Przeważnie można wykorzystać
poniższy przykład:
order hosts,bind
multi on
Taka konfiguracja mówi resolwerowi nazw, żeby sprawdził plik /etc/hosts zanim podejmie próbę
 rozpytywania serwera nazw oraz żeby zwrócił wszystkie ważne adresy hosta odnalezione w pliku /
etc/hosts zamiast pierwszego z nich.
Proszę przeanalizować przykład pliku /etc/host.conf na lokalnym komputerze.
3.4. /etc/hosts
Plik /etc/hosts służy do umieszczania nazwy i adresu IP lokalnych hostów. Kiedy dany host pojawia się
w tym pliku, nie istnieje potrzeba korzystania z serwera DNS w celu odnalezienia jego IP. Wadą
takiego postępowania jest konieczność utrzymywania aktualności pliku względem zmian hostów. W
dobrze zarządzanym systemie zazwyczaj jedyne nazwy hostów, które występują w pliku dotyczą
interfejsu pętli zwrotnej (loopback) i nazw hostów lokalnych.
# /etc/hosts
127.0.0.1 localhost loopback
192.168.0.1 this.host.name
Można zdefiniować więcej niż jedną nazwę hosta w linii (przykład pierwszego wpisu powyżej, który
jest standardową pętlą zwrotną).
Proszę przeanalizować przykład pliku /etc/hosts na lokalnym komputerze.
4. Konfiguracja pętli zwrotnej
Interfejs pętli zwrotnej (loopback) jest szczególnym typem interfejsu umożliwiającym
połączenia z własną maszyną. Istnieje wiele powodów takiego działania, np. testowanie
oprogramowania sieciowego na pojedynczej maszynie. Konwencjonalnie, przypisuje się w tym celu
adres  127.0.0.1 (lub kolejne adresy z tej grupy). Wtedy bez względu na to, jak skonfigurowana jest
dalej maszyna, otwarcie połączenia z 127.0.0.1 zawsze osiągnie lokalnego hosta.
Konfiguracja pętli zwrotnej jest prosta i należy mieć pewność, że została prawidłowo
przeprowadzona (chociaż zazwyczaj dokonuje się automatycznie poprzez standardowe skrypty
konfiguracyjne).
root# ifconfig lo 127.0.0.1
root# route add -host 127.0.0.1 lo
Polecenie  route jest omówione dokładniej w dalszej części instrukcji.
5. Routing
Routing jest bardzo szerokim zagadnieniem i można na ten temat napisać oddzielne
opracowania. Jednak zazwyczaj będziemy mieć do czynienia ze względnie prostymi zagadnieniami
routingu. Poniżej zostają zaprezentowane jedynie podstawy.
Zacznijmy od definicji. Ta używana na potrzeby tego kursu brzmi: routing IP jest procesem
poprzez który host o wielu połączeniach sieciowych decyduje gdzie dostarczyć datagramy IP, które do
niego dotarły.
Wygodnie jest zilustrować ideę routingu przykładem. Proszę wyobrazić sobie typowy biurowy
router, który może mieć połączenie PPP z Internetem, pewną liczbę segmentów ethernetowych (do
stacji roboczych) i kolejne połączenie PPP z innym biurem. Kiedy router otrzymuje datagram poprzez
strona 3 z 9
Sieci komputerowe lab 2 Jacek Wiślicki, [e-mail]
którekolwiek ze swoich połączeń sieciowych, mechanizm routing stara się ustalić, któremu interfejsowi
powinien przesłać go dalej. Proste hosty także potrzebują routowania, wszystkie podłączone do
Internetu maszyny posiadają 2 urządzenia sieciowe  jedno do zapewnienia pętli zwrotnej (opisanej
powyżej), drugie do komunikacji z resztą sieci, np. Ethernet, PPP, czy szeregowy SLIP.
Pojawia się pytanie, jak właściwie działa routing. Każdy host utrzymuje specjalną listę reguł
routowania (tzw. tablica routingu). Tablica ta zawiera rzędy zawierające co najmniej 3 pola: adres
przeznaczenia, nazwę interfejsu do którego datagramy mają być routowane i opcjonalne adres IP
maszyny, która przejmie datagramy w kolejnym etapie przesyłania poprzez sieć. W Linuxie tablice tę
można podejrzeć poprzez:
user% cat /proc/net/route
lub jedną z następujących komend:
user% /sbin/route -n
user% netstat -r
Proces routowania jest dość prosty: nadchodzący datagram jest otrzymywany, sprawdzany jest
adres przeznaczenia i porównywany z wpisami w tablicy. Wybrany zastaje wpis, który najlepiej pasuje
do adresu i następnie datagram jest przesyłany dalej do wybranego interfejsu. Jeżeli podane jest pole
bramy, datagram jest wysyłany do tego hosta poprzez kreślony interfejs, w przeciwnym wypadku
zakłada się, że adres przeznaczenia należy do sieci obsługiwanej przez interfejs.
W celu dokonywania zmian w tablicy wykorzystuje się odpowiednie komendy. Argumenty
polecenia są konwertowane do wywołań jądra, nakazujących dodanie, usunięcie lub modyfikacje
wpisów tablicy routingu. Polecenie to nazywa się  route .
Poniższy przykład zakłada istnienie sieci ethernetowej klasy C o adresie 192.168.1.0. Nasz
adres to 192.168.1.10, natomiast 192.168.1.1 oznacza router podłączony do Internetu.
Pierwszy krok stanowi konfiguracja interfejsu w sposób opisany wcześniej. Komenda
wykorzystana w tym celu powinna mieć postać:
root# ifconfig eth0 192.168.1.10 netmask 255.255.255.0 up
Teraz należy dodać wpis do tablicy routingu w celu powiadomienia jądra, że datagramy
przeznaczone dla hostów o adresach pasujących do 192.168.1.* powinny zostać wysłane do urządzenia
ethernetowego. Dokona tego polecenie jak poniżej:
root# route add -net 192.168.1.0 netmask 255.255.255.0 eth0
Proszę zauważyć, że argument  -net jest użyty w celu powiadomienia programu router, że wpis
jest trasą sieciową. Kolejną możliwością jest trasa  -host , która oznacza trasę do konkretnego hosta o
danym adresie IP.
Ta trasa pozwoli ustanowić połączenia IP ze wszystkimi hostami w naszym segmencie
Ethernetu. Jednak co się dzieje z hostami poza tym segmentem?
Byłoby bardzo trudno dodać trasy to każdego potencjalnego miejsca docelowego w sieci,
dlatego stosuje się rozwiązanie znacznie upraszczające takie zadanie. Ten trik jest nazywany
 domyślną trasą (default route). Trasa domyślna  pasuje do każdego możliwego miejsca docelowego,
jednak  niezbyt dokładnie , dlatego kiedy tylko istnieje inny wpis tablicy bardziej odpowiadający
adresowi docelowemu, właśnie on zostanie użyty. Idea trasy domyślnej stanowi po prostu  wszystko
inne powinno iść tutaj . Przykład poniżej określa taką trasę:
root# route add default gw 192.168.1.1 eth0
Argument  gw określa w poleceniu router, że następny argument jest adresem IP lub nazwą,
lub bramą, lub routerem, gdzie wszystkie datagramy odpowiadające temu wpisowi powinny zostać
przekierowane w celu dalszego routingu.
Teraz kompletna konfiguracja powinna mieć postać:
root# ifconfig eth0 192.168.1.10 netmask 255.255.255.0 up
strona 4 z 9
Sieci komputerowe lab 2 Jacek Wiślicki, [e-mail]
root# route add -net 192.168.1.0 netmask 255.255.255.0 eth0
root# route add default gw 192.168.1.1 eth0
Przyglądając się bliżej plikom  rc naszej sieci można odnalez
ć co najmniej jeden bardzo
przypominający nasz kod. Jest to dość częsta konfiguracja.
Teraz rozpatrzymy trochę bardziej skomplikowaną konfigurację routingu. Wez
my zadanie
skonfigurowania routera rozważanego wcześniej, posiadającego połączenie PPP z Internetem oraz
segment LAN obsługujący stacje robocze biura. Niech router posiada trzy segmenty Ethernetu i jedno
połączenie PPP. Konfiguracja routingu mogłaby być następująca:
root# route add -net 192.168.1.0 netmask 255.255.255.0 eth0
root# route add -net 192.168.2.0 netmask 255.255.255.0 eth1
root# route add -net 192.168.3.0 netmask 255.255.255.0 eth2
root# route add default ppp0
Każda stacja robocza używałaby prostszej formy przedstawionej powyżej, jedynie router
wymaga sprecyzowania każdej trasy sieciowej oddzielnie, ponieważ dla stacji roboczych domyślny
mechanizm routingu obejmie je wszystkie, obciążając router koniecznością prawidłowego kierowania
do nich datagramów. Można się zastanawiać dlaczego trasa domyślna w tym wypadku nie określa  gw .
Powód jest prosty, szeregowe protokoły, jak PPP oraz SLIP, posiadają jedynie dwa hosty w sieci, po
jednym na każdym końcu. Określenie hosta na drugim końcu połączenia jako bramy jest bezcelowe i
zbędne, jako że nie ma innego wyboru. Dla takiej sieci nie istnieje potrzeba określania bramy. Inne typy
sieci, jak Ethernetu, arcnet lub token ring, wymagają określenia bramy ze względu na obsługę dużej
ilości hostów.
6. Zasada działania programu  routed
Opisana powyżej konfiguracja routingu jest dopasowana do prostych organizacji sieci, gdzie
jedynie istnieją pojedyncze ścieżki do miejsc docelowych. Przy bardziej złożonych aranżacjach sieci
sprawa staje się trochę bardziej skomplikowana. Nie będziemy się jednak zajmować tym szczegółowo
podczas laboratorium.
Dużym problemem dotyczącym ręcznego (statycznego) routingu opisanego wcześniej jest, że
kiedy maszyna bądz
połączenie ulega awarii jedynym sposobem pokierowania datagramami inną drogą
(o ile takowa istnieje) jest ręczna interwencja i wykonanie odpowiednich poleceń. Oczywiście, jest to
sposób niezdarny, powolny, niepraktyczny i ryzykowny. Rozwinięto różnorodne techniki
automatycznego dopasowywania tablic routingu na wypadek awarii sieci posiadającej alternatywne
trasy. Techniki te określa się mianem protokołów dynamicznego routowania (dynamic routing
protocols).
Najczęściej spotykanymi protokołami dynamicznymi są RIP (Routing Information Protocol)
oraz OSPF (Open Shortest Path First Protocol). RIP jest bardzo powszechny w małych sieciach np.
małe i średnie sieci korporacyjne lub sieci wewnątrz budynków. Występuje on także w tzw. wersji
drugiej, wzbogaconej o bardziej niezawodne mechanizmy routowania i obsługującej m.in. adresowanie
bezklasowe. OSPF jest bardziej nowoczesny i nadaje się lepiej do obsługi dużych sieci i środowisk o
olbrzymiej liczbie potencjalnych ścieżek. Powszechnymi implementacjami są:  routed -RIP i
 gated -RIP, OSPF i inne.
Program  routed występuje w standardowych dystrybucjach Linuxa, wchodzi także w skład
pakietu  NetKit . Przykład gdzie i jak stosować dynamiczne routowanie może stanowić poniższa
ilustracja.
strona 5 z 9
Sieci komputerowe lab 2 Jacek Wiślicki, [e-mail]
192.168.1.0 / 192.168.2.0 /
255.255.255.0 255.255.255.0
- -
| |
| /-----\ /-----\ |
| | |ppp0 // ppp0| | |
eth0 |---| A |------//---------| B |---| eth0
| | | // | | |
| \-----/ \-----/ |
| \ ppp1 ppp1 / |
- \ / -
\ /
\ /
\ /
\ /
\ /
\ /
\ /
\ /
ppp0\ /ppp1
/-----\
| |
| C |
| |
\-----/
|eth0
|
|---------|
192.168.3.0 /
255.255.255.0
Pojawiają się tutaj trzy routery A, B i C. Każdy obsługuje jeden segment Ethernetu klasy C sieci
IP o masce podsieci 255.255.255.0. Każdy router posiada także połączenie PPP z dwoma pozostałymi
routerami. Sieć tworzy trójkąt.
Jasne jest, że konfiguracja tablicy routingu powinna być następująca:
root# route add -net 192.168.1.0 netmask 255.255.255.0 eth0
root# route add -net 192.168.2.0 netmask 255.255.255.0 ppp0
root# route add -net 192.168.3.0 netmask 255.255.255.0 ppp1
Coś takiego działałoby prawidłowo do czasu uszkodzenia połączenia między routerami A i B.
W takim wypadku i przy bieżącej konfiguracji hosty segmentu A nie mogłyby osiągnąć hostów
segmentu B, ponieważ ich datagramy byłyby kierowane do połączenia ppp0 routera A, które jest
uszkodzone. Mogłyby natomiast utrzymywać  konwersację z hostami segmentu C a hosty segmentu C
wciąż komunikowałyby się z hostami segmentu B, ponieważ połączenie pomiędzy B i C jest sprawne.
W takiej sytuacji, jeżeli A może komunikować się z C oraz C może komunikować się z B,
rozwiązaniem byłoby przetrasowanie datagramów od A przeznaczonych dla B poprzez C i nakazanie
wysłania ich do B. Właśnie takiej problematyki dotyczą protokoły routingu dynamicznego jak RIP.
Jeżeli każdy z routerów A, B i C miałby uruchomionego demona routingu, ich tablice rooutingu byłyby
automatycznie dopasowywane w celu odzwierciedlenia bieżącego stanu sieci w sytuacji awarii
któregokolwiek połączenia. Dla skonfigurowania takiej sieci, każdy router potrzebuje dwóch rzeczy. W
przypadku routera A konfiguracja byłaby następująca:
root# route add -net 192.168.1.0 netmask 255.255.255.0 eth0
root# /usr/sbin/routed
strona 6 z 9
Sieci komputerowe lab 2 Jacek Wiślicki, [e-mail]
Demon routingu  program  routed automatycznie odnajduje wszystkie aktywne porty sieciowe
kiedy się uruchamia i wysyła oraz nasłuchuje wiadomości każdego urządzenia sieciowego w celu
umożliwienia wyznaczenia i aktualizacji tablicy routingu hosta.
Jest to bardzo pobieżne wyjaśnienie routingu dynamicznego i miejsc jego zastosowania. Istotne
punkty odnośnie tego rodzaju routingu to:
1. Wystarczy uruchomić demona protokołu dynamicznego routingu kiedy maszyna obsługiwana przez
Linuxa ma możliwość wyboru spośród wielu tras do miejsca docelowego. Przykładem tego mogłoby
być używanie IP-Masquerade.
2. Demon dynamicznego routingu automatycznie modyfikuje tablicę routingu w celu dopasowania jej
do zmian w sieci.
3. RIP przeznaczony jest dla małych sieci.
7. Konfiguracja serwerów sieciowych i usług
Serwery i usługi sieciowe są programami które umożliwiają zdalnemu użytkownikowi
korzystanie z lokalnej maszyny. Programy serwerów nasłuchują na portach sieciowych. Porty te są
środkami adresowania konkretnej usługi na konkretnym hoście i pozwalają serwerowi odróżnić
wywołania konkretnych usług (np. telnet i FTP). Zdalny użytkownik ustanawia połączenie sieciowe z
naszą maszyną i programem serwerowym, programem demona sieciowego, nasłuchującym na danym
porcie, akceptującym połączenie i wykonującym się. Demony sieciowe mogą działać na dwa sposoby,
obydwa wykorzystywane w praktyce:
standalone program demona sieciowego nasłuchuje na przeznaczonym dla niego
porcie sieciowym i kiedy nadchodzące połączenie jest nawiązane, sam
nim zarządza w celu zapewnienia usługi.
slave to the inetd server serwer inetd jest specjalnym demonem sieciowym, który specjalizuje się
w zarządzaniu nadchodzącymi połączeniami. Posiada plik
konfiguracyjny, który mówi mu, który program należy uruchomić kiedy
ma być nawiązane połączenie. Dowolny port może zostać
skonfigurowany na użytek zarówno TCP lub UDP. Porty opisane są w
kolejnym pliku, opisanym poniżej.
Istnieją dwa ważne pliki, które należy skonfigurować w celu zapewnienia prawidłowych usług
sieciowych. Są to /etc/services (przypisuje nazwy do numerów portów) oraz /etc/inetd.conf (plik
konfiguracyjny demona inetd).
7.1. /etc/services
Plik /etc/services stanowi prostą bazę danych, która wiąże nazwy  przyjazne człowiekowi do
zorientowanych na maszynę portów usług. Jego format jest bardzo prosty. Jest to plik tekstowy, którego
każda linia stanowi oddzielny wpis bazy. Wpis taki składa się z trzech pól oddzielony dowolną liczbą
białych spacji (TAB albo spacja). Pola te to:
name port/protocol aliases # comment
name pojedyncze słowo stanowiące nazwę usługi.
port/protocol pole to jest rozdzielone na dwa  podpola
port liczba określająca numer portu, na którym nazwana usługa będzie dostępna.
Większość standardowych usług ma przypisane odpowiednie numery
zdefiniowane w RFC-1340.
protocol może być wypełnione przez  tcp albo  udp . Ważną rzeczą jest, że zapis
 18/tcp jest zdecydowanie różny od  18/udp i nie istnieje techniczna
przyczyna, dla której ta sama usługa potrzebuje istnieć na obydwu. Zdrowy
strona 7 z 9
Sieci komputerowe lab 2 Jacek Wiślicki, [e-mail]
rozsądek nakazuje, że taka sytuacja pojawia się jedynie kiedy konkretna
usługa ma być dostępna zarówno poprzez TCP jak i UDP.
aliases inne nazwy pod którymi można odnieść się do danej usługi.
Każdy tekst pojawiający się po  # jest ignorowany I traktowany jako komentarz.
Proszę przeanalizować przykład pliku /etc/services na lokalnym komputerze.
7.2. /etc/inetd.conf
Plik /etc/inetd.conf jest plikiem konfiguracyjnym demona serwera inetd. Jego zadaniem jest
informować inetd co ma robić kiedy otrzymuje żądanie połączenia dla konkretnej usługi. Dla każdej
usługi, dla której mają być przyjmowane połączenia należy zdefiniować, demona serwera jakiej usługi
ma uruchomić i w jaki sposób.
Format tego pliku jest także bardzo czytelny. Jest to plik tekstowy, którego każda linia opisuje
usługę, którą chcemy zapewnić. Każdy tekst po  # jest ignorowany jako komentarz. Linia składa się z
siedmiu pól oddzielonych dowolną liczbą białych spacji. Ogólnie format wygląda następująco:
service socket_type proto flags user server_path server_args
service czy usługa pasuje w tej konfiguracji jako pobrana z pliku /etc/services.
socket_type opisuje typ gniazda, które zostanie przez dany wpis uznane za odpowiednie,
dopuszczalne wartości to: stream, dgram, raw, rdm, lub seqpacket. Jest to z natury
mało techniczne, jednak zwyczajowo niemalże wszystkie usługi oparte o TCP
używają stream i niemal wszystkie usługi UDP używają dgram. Jedynie bardzo
specyficzne typy demonów serwerowych korzystają z innych wartości.
proto protokół postrzegany jako ważny dla danego wpisu. Powinien zgadzać się z
odpowiednim wpisem w /etc/services i zazwyczaj będzie to tcp lub udp. Serwery
oparte na Sun RPC korzystają z rpc/tcp lub rpc/udp.
flags istnieją jedynie dwie możliwe wartości tego pola. Jego ustawienie informuje inetd,
czy program serwera sieciowego zwalnia gniazdo po wystartowaniu i dlatego inetd
może uruchomić kolejną jego instancję przy następnym żądaniu połączenia, czy
raczej powinien czekać i założyć, że jakiś już uruchomiony demon serwera obsłuży
nowe połączenie. Znowu, zwyczajowo niemal wszystkie serwery TCP powinny mieć
tą wartość ustawioną na nowait, podczas gdy większość serwerów UDP wymaga
wait. Istnieją pewne znaczące wyjątki dotyczące tego pola i w razie wątpliwości
należy posłużyć się dokumentacją bądz
przykładami.
user opisuje które konto użytkownika z /etc/passwd będzie ustawione jako właściciel
demona sieciowego kiedy jest uruchomiony. Często ze względów bezpieczeństwa
można ustalić tą wartość na nobody tak, że nawet w przypadku złamania
bezpieczeństwa serwera potencjalne straty są minimalne. Jednak najczęściej pole to
wskazuje na root, gdyż wiele serwerów wymaga takich uprawnień do prawidłowego
funkcjonowania.
server_path ścieżka do właściwego programu serwera odpowiedzialnego za wykonanie wpisu.
server_args opcjonalne pole zawierające argumenty wywołania aplikacji ze ścieżki powyżej.
Proszę przeanalizować przykład pliku /etc/inetd.conf na lokalnym komputerze.
strona 8 z 9
Sieci komputerowe lab 2 Jacek Wiślicki, [e-mail]
8. Pomniejsze pliki konfiguracyjne sieci
Istnieje grupa mniej istotnych plików odpowiedzialnych za konfiguracje sieci pod Linuxem.
Potencjalnie nigdy nie zajdzie konieczność ich modyfikacji, jednak warto je opisać w celu określenia
ich zawartości i znaczenia.
8.1. /etc/protocols
Plik /etc/protocols jest bazą danych mapującą numery identyfikacyjne protokołów z ich
nazwami. Jest wykorzystywany przez programistów w celu umożliwienia określania protokołów po
nazwie, jak i przez pewne programy (np. tcpdump) w celu wyświetlenia nazw protokołów zamiast
numerów na strumieniu wyjściowym. Ogólna składnia pliku to:
protocolname number aliases
Proszę przeanalizować przykład pliku /etc/protocols na lokalnym komputerze.
8.2. /etc/networks
Plik /etc/networks spełnia podobną funkcję do /etc/hosts. Jest prostą bazą nazw sieciowych i
odpowiadających im adresów sieciowych. Format różni się tylko tym, że zawiera tylko dwa pola w
linii:
networkname networkaddress
Przykłady wpisów mogą wyglądać następująco:
Loopnet 127.0.0.0
Localnet 192.168.0.0
Amprnet 44.0.0.0
Podczas używania komend typu router, jeżeli miejsce docelowe jest siecią i ta sieć posiada wpis
w /etc/networks, polecenie router wyświetli nazwę sieci zamiast jej adresu.
strona 9 z 9