1. Tworzenie interfejsów sieciowych. 2. Konfiguracja interfejsu sieciowego

Transkrypt

1 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 eth netmask up W tym wypadku konfiguracji podlega interfejs ethernetowy eth0 o adresie IP i masce podsieci 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 natomiast adres rozgłoszeniowy jako 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 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 <addr> określa maskę podsieci do, której należy urządzenie. 1

2 irq <addr> 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 <type> <addr> 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 /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 nameserver 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 /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: 2

3 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 /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 localhost loopback 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 (lub kolejne adresy z tej grupy). Wtedy bez względu na to, jak skonfigurowana jest dalej maszyna, otwarcie połączenia z 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 root# route add -host 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. 3

4 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 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 Nasz adres to , natomiast 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 eth netmask 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 * powinny zostać wysłane do urządzenia ethernetowego. Dokona tego polecenie jak poniżej: 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 4

5 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 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 eth netmask up root# route add default gw eth0 Przyglądając się bliżej plikom rc naszej sieci można odnaleźć co najmniej jeden bardzo przypominający nasz kod. Jest to dość częsta konfiguracja. Teraz rozpatrzymy trochę bardziej skomplikowaną konfigurację routingu. Weź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 netmask eth1 root# route add -net netmask 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ądź 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). 5

6 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 / / / \ ppp0 // ppp0 eth0 --- A // B --- eth0 // \-----/ \-----/ \ ppp1 ppp1 / - - ppp0ppp1 /-----\ C \-----/ eth / Pojawiają się tutaj trzy routery A, B i C. Każdy obsługuje jeden segment Ethernetu klasy C sieci IP o masce podsieci 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 netmask ppp0 root# route add -net netmask 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ć 6

7 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# /usr/sbin/routed 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

8 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 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 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 /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 socket_type proto flags czy usługa pasuje w tej konfiguracji jako pobrana z pliku /etc/services. 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. 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. 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 8

9 user server_path server_args 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ądź przykładami. 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. ścieżka do właściwego programu serwera odpowiedzialnego za wykonanie wpisu. opcjonalne pole zawierające argumenty wywołania aplikacji ze ścieżki powyżej. Proszę przeanalizować przykład pliku /etc/inetd.conf na lokalnym komputerze. 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 /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 /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 Localnet Amprnet 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. 9