interfejsy sieciowe, ! , !2, Sieci
[ Pobierz całość w formacie PDF ]
Sieci komputerowe
lab 2
Jacek Wiślicki, jacenty@kis.p.lodz.pl
Celem poniższego ćwiczenia jest zapoznanie się z narzędziami i mechanizmami konfiguracji sieci
oferowanymi przez systemy UNIXowe (w naszym wypadku Slackware Linux). Ź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, jacenty@kis.p.lodz.pl
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.
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.
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, jacenty@kis.p.lodz.pl
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, jacenty@kis.p.lodz.pl
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, jacenty@kis.p.lodz.pl
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 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 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ą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).
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
[ Pobierz całość w formacie PDF ]