Egy gép egy másikat úgy tud megtalálni a hálózaton, ha erre létezik egy olyan mechanizmus, amely leírja, hogyan tudunk eljutni az egyiktől a másikig. Ezt hívjuk útválasztásnak (routing). Az „útvonal” (route) címek egy párjaként adható meg, egy „céllal” (destination) és egy „átjáróval” (gateway). Ez a páros mondja meg, hogy ha el akarjuk érni ezt a célt, akkor ezen az átjárón keresztül kell továbbhaladnunk. A céloknak három típusa lehet: egyéni gépek, alhálózatok és az „alapértelmezett”. Az „alapértelmezett útvonalat” (default route) abban az esetben alkalmazzuk, ha semelyik más útvonal nem megfelelő. Az alapértelmezett útvonalakról a későbbiekben még beszélni fogunk. Három típusa van az átjáróknak: egyéni gépek, felületek (avagy „linkek”) és a hardveres Ethernet címek (MAC-címek).
Az útválasztás
különböző területeit a
következő netstat
parancs
alapján fogjuk bemutatni:
%
netstat -r
Routing tables Destination Gateway Flags Refs Use Netif Expire default outside-gw UGSc 37 418 ppp0 localhost localhost UH 0 181 lo0 test0 0:e0:b5:36:cf:4f UHLW 5 63288 ed0 77 10.20.30.255 link#1 UHLW 1 2421 example.com link#1 UC 0 0 host1 0:e0:a8:37:8:1e UHLW 3 4601 lo0 host2 0:e0:a8:37:8:1e UHLW 0 5 lo0 => host2.example.com link#1 UC 0 0 224 link#1 UC 0 0
Az első két sorban az alapértelmezett
útvonalat (melyről részleteiben majd a következő
szakaszban fogunk szólni) és a
localhost
útvonalát
láthatjuk.
A localhost
címhez az
útválasztási táblázatban a
lo0
eszköz tartozik (a
Netif
oszlopban), amelyet loopback
eszköznek is neveznek. Ez arra utasítja a
rendszert, hogy az ide küldött csomagokat ne a helyi
hálózaton küldje keresztül, hanem csak
ezen a belső felületen, mivel úgyis oda
jutnának vissza, ahonnan indultak.
A táblázatban a következő sor egy
0:e0
kezdetű címet
tartalmaz. Ez egy hardveres Ethernet cím, más
néven MAC-cím. A FreeBSD magától
képes beazonosítani tetszőleges gépet
(ebben a példában a test0
gépet) a helyi Ethernetes hálózaton
és felvenni hozzá egy útvonalat,
közvetlenül az ed0
Ethernetes
csatolófelületen keresztül. Ehhez a
típusú útvonalhoz tartozik még egy
lejárati idő is (a Expire
oszlop), amely akkor kap szerepet, ha ennyi idő
elteltével nem kapunk semmilyen hírt a
gépről. Amikor ilyen történik, az
géphez eddig nyilvántartott útvonal
automatikusan törlődik. Ezek a gépek a RIP
(útvonal-információs protokoll, Routing
Information Protocol) nevű mechanizmuson keresztül
azonosítódnak, mely a legrövidebb út
kiszámítása alapján határozza
meg a helyi gépekhez vezető útvonalat.
A FreeBSD a helyi alhálózat (10.20.30.255
és example.com
, az
alhálózathoz tartozó név)
esetében is felvesz útvonalakat. A
link#1
megnevezés a gépben
található első Ethernet-kártyát
jelöli. Megfigyelhetjük, hogy rajta kívül
nincs is több felülete.
Mindegyik csoport (a helyi hálózati gépek és a helyi alhálózatokatok) útvonalait a routed nevű démon tartja automatikusan karban. Ha ez nem fut, akkor csak a statikusan definiált (vagyis az előre megadott) útvonalak fognak létezni.
A host1
sor a saját
gépünkre vonatkozik, amelyet az Ethernet címe
szerint ismerünk. Mivel mi vagyunk küldő
gép, a FreeBSD tudni fogja, hogy ilyenkor az Ethernetes
felület helyett a loopback eszközt
(lo0
) kell használnia.
A két host2
sor arra mutat
példát, amikor az ifconfig(8) paranccsal
álneveket hozunk létre (ennek konkrét okait
lásd az Ethernetről szóló
részben). A lo0
felület
neve után szereplő =>
szimbólum azt jelzi, hogy ez nem csak egy loopback
felület (mivel a címe szintén a helyi
gépre mutat), hanem a felület egy másik neve.
Ilyen útvonalak csak az álneveket ismerő
gépeknél jelennek meg. A helyi
hálózaton minden más gépnél
egyszerűen csak a link#1
jelenik meg az
ilyen útvonalak esetében.
Az utolsó sor (a 224
céllal rendelkező alhálózat) a
multicastre (többesküldésre) szolgál,
amellyel majd egy másik szakaszban foglalkozunk.
Végezetül az útvonalakhoz tartozó
különféle tulajdonságok a
Flags
oszlopban láthatóak. Az
alábbi rövid táblázatban
összefoglaltunk közülük
néhányat:
U | Up: az útvonal aktív |
H | Host: az útvonal egyetlen gépre mutat |
G | Gateway: az adott cél felé ezen a gépen keresztül küldjünk, amely majd kitalálja, hogy merre küldje tovább |
S | Static: ez az útvonal statikus, nem a rendszer hozta létre automatikusan |
C | Clone: ebből az útvonalból származtatunk új útvonalat azokhoz a gépekhez, amelyekhez csatlakozunk. Ilyen útvonalakat általában a helyi hálózatokban találhatunk |
W | WasCloned: azt jelzi, hogy ezt az útvonalat egy helyi hálózatra mutató (klón, avagy Clone típusú) útvonal alapján hoztuk létre automatikusan |
L | Link: az útvonal Ethernetes hardverhez kapcsolódik |
Amikor a helyi rendszernek fel kell vennie a kapcsolatot egy távoli géppel, ellenőrzi az útválasztási táblázatban, hogy létezik-e már hozzá valamilyen útvonal. Ha a távoli gép egy olyan alhálózatba esik, amelyet már el tudunk érni (klónozott útvonalak), akkor a rendszer megnézi, hogy a hozzá tartozó felületen képes-e kapcsolatot létesíteni.
Ha minden ismert útvonal csődöt mond, akkor
a rendszerünknek marad még egy utolsó
esélye: az „alapértelmezett”
útvonal használata. Ez az útvonal egy
speciális átjáró útvonal
(ebből általában csak egyetlen egy
létezik a rendszerben) és tulajdonságai
között mindig szerepel a c
. A
helyi hálózat gépei közül ez az
átjáró az legyen, amelyik
közvetlenül kapcsolódik a külső
világhoz (PPP összeköttetéssel, DSL,
kábelmodem, T1 vagy bármilyen más
hálózati felületen keresztül).
Amikor pedig magát a külső világ felé átjáróként szolgáló gépet állítjuk be, az alapértelmezett útvonal az internet-szolgáltatónk által megadott gép címe lesz.
Vegyünk egy példát az alapértelmezett útvonalakra. Egy tipikus konfiguráció:
A Helyi1
és Helyi2
gépek a hálózatunk tagjai. A
Helyi1
az internet-szolgáltatót
éri el egy betárcsázós PPP
kapcsolaton keresztül. A PPP szerver a külső
felületén keresztül a helyi
hálózaton pedig egy másik
átjáróhoz csatlakozik.
Az egyes gépek alapértelmezett útvonalai így alakulnak:
Gép | Alapértelmezett átjáró | Felület |
---|---|---|
Helyi2 | Helyi1 | Ethernet |
Helyi1 | T1-ÁJ | PPP |
Gyakran felmerül a kérdés, hogy
„Miért (és hogy-hogy) a
T1-ÁJ
a Helyi1
gép számára az alapértelmezett
átjáró és nem a
szolgáltató azon szervere, amelyhez
csatlakozott?”
Ne felejtsük el, hogy a PPP felület a
szolgáltató helyi hálózatában
a mi részünkre kap címet, és a itt az
összes többi géphez tartozó
útvonal automatikusan létrejön. Emiatt
már eleve el tudjuk érni a
T1-ÁJ
gépet, ezért amikor
a szolgáltatón keresztül küldünk,
nincs szükségünk egy további
lépcsőre.
Általában a X.X.X.1
címet szokták a
helyi hálózat
átjárójának kiosztani. Ezért
(az előbbi példát
újrahasznosítva) ha a helyi
hálózatunkon a C osztályú 10.20.30
címtartományt
használjuk, és a szolgáltatónkhoz a
10.9.9
címtartomány
tartozik, akkor az alapértelmezett útvonalak a
következők lesznek:
Gép | Alapértelmezett útvonal |
---|---|
Helyi2 (10.20.30.2) | Helyi1 (10.20.30.1) |
Helyi1 (10.20.30.1, 10.9.9.30) | T1-ÁJ (10.9.9.1) |
Az /etc/rc.conf
állományon keresztül könnyen meg tudjuk
adni az alapértelmezett útvonalat. A
példánkban a Helyi2
gép
/etc/rc.conf
állományába kell felvennünk a
következő sort:
defaultrouter="10.20.30.1"
A route(8) parancs használatával viszont akár közvetlenül is megtehetjük mindezt:
#
route add default 10.20.30.1
A route(8) man oldalon olvashatunk arról bővebben, hogy a hálózati útválasztási táblázatokat kézzel hogyan tudjuk módosítani.
Egy másik típusú konfigurációról is szót kell ejtenünk, ahol a gép egyszerre két hálózatnak is tagja. Gyakorlatilag az átjáróként üzemelő számítógépek (mint például az, amelyik a fenti példában PPP kapcsolattal csatlakozott) ilyen kettős hálózatú gépnek tekinthetőek. Ez a kifejezés azonban igazából csak azokra az esetekre illik, ahol a gép egyszerre két helyi hálózatban is megjelenik.
Az egyik esetben a gépben két Ethernet kártya található, melyek mindegyike birtokol egy-egy hálózati címet az egyes alhálózatokon. De előfordulhat az is, hogy a gépünkben csupán egyetlen Ethernet kártya van és az ifconfig(8) segítségével álneveket hoztunk létre hozzá. Az előbbi általában két fizikailag elkülönölő Ethernet alapú hálózat esetében történik, míg az utóbbinál csak egyetlen fizikai hálózati szegmensről van szó, amely viszont logikailag két külön alhálózatot tartalmaz.
Akármelyiket is vesszük, az útválasztási táblázatok úgy jönnek létre, hogy bennük a gép a másik alhálózat felé átjáróként (bejövő útvonalként) lesz nyilvántartva. Ebben a konfigurációban a gép a két alhálózat között útválasztóként fog tevékenykedni, és gyakran valamelyik vagy éppen mind a két irányba be kell állítanunk valamilyen csomagszűrést vagy tűzfalazást.
Ha azt szeretnénk, hogy ez a gép a két felület között továbbítson csomagokat, akkor a FreeBSD-ben külön engedélyezni kell ezt a lehetőséget. A következő szakaszban ennek részleteit tárjuk fel.
A hálózati útválasztó nem
csinál mást, csak továbbküldi az egyik
felületén beérkező csomagokat egy
másik felületére. Az internetes
szabványok és a sokéves mérnöki
tapasztalat azonban nem engedik, hogy a FreeBSD Projekt
alapértelmezés szerint is
elérhetővé tegye ezt a FreeBSD rendszerekben.
Ezt a lehetőséget az alábbi
változó YES
értékűre
állításával lehet
engedélyezni az rc.conf(5)
állományban:
gateway_enable="YES" # Ez legyen YES, ha átjáróként akarunk üzemelni
Ezzel lényegében a
net.inet.ip.forwarding
sysctl(8)
változó értékét
állítjuk 1
-re. Ha
valamiért egy időre szüneteltetni akarjuk a
csomagok továbbküldését, akkor
állítsuk a változó
értékét 0
-ra.
Az új útválasztónak nem árt arról sem tudnia, hogy merre továbbítsa a forgalmat. Ha elég egyszerű a hálózatunk, akkor akár statikus útvonalakat is használhatunk. A FreeBSD alapból tartalmazza a BSD-k esetén szabványos routed(8) útválasztó démont, amely a RIP (v1 és v2) valamint az IRDP megoldásokat ismeri. A BGP v4, OSPF v2 és a többi fejlettebb útválasztási protokoll a net/zebra csomagban érhető el. Az ettől bonyolultabb hálózati útválasztási feladatokhoz olyan kereskedelmi termékek is elérhetőek, mint például a GateD®.
Tegyük fel, hogy hálózatunk a következő:
Ebben a forgatókönyvben az
A-utvalaszto
a mi FreeBSD-s gépünk,
amely az internet felé vezető
útválasztó szerepét
játssza. Számára az
alapértelmezett útvonal a 10.0.0.1
, amelyen keresztül a
külső világot tudja elérni.
Feltételezzük, hogy a
B-utvalaszto
nevű gépet
már eleve jól állítottuk be,
ezért tudja merre kell mennie. (A kép
alapján egyszerű: csak vegyünk fel egy
alapértelmezett útvonalat a
B-utvalaszto
géphez, ahol így a
192.168.1.1
lesz az
átjáró.)
Ha megnézzük most az
A-utvalaszto
útválasztási
táblázatát, akkor nagyjából
a következőket fogjuk látni:
%
netstat -nr
Routing tables Internet: Destination Gateway Flags Refs Use Netif Expire default 10.0.0.1 UGS 0 49378 xl0 127.0.0.1 127.0.0.1 UH 0 6 lo0 10.0.0/24 link#1 UC 0 0 xl0 192.168.1/24 link#2 UC 0 0 xl1
Az A-utvalaszto
útválasztási táblázata
alapján jelen helyzetben nem lehet elérni a 2.
belső hálózatot. Nincs ugyanis olyan
útvonal, amely a 192.168.2.0/24
alhálózat
felé vezetne. Ezt például úgy
tudjuk megoldani, ha manuálisan felvesszük ezt az
útvonalat. Az alábbi paranccsal
hozzáadjuk a 2. belső hálózat
elérését az A-utvalaszto
útválasztási
táblázatához, ahol a 192.168.1.2
lesz a következő
ugrási pont (next hop):
#
route add -net 192.168.2.0/24 192.168.1.2
Most már az A-utvalaszto
bármelyik gépet képes elérni a
192.168.2.0/24
hálózaton.
A fenti példa tökéletesen
szemlélti a statikus útvonalak
felvételét egy működő rendszeren.
Azonban ezzel az a gond, hogy az így megadott
útválasztási információ nem
marad meg a gép újraindítása
után. Ezért az előbbihez hasonló
statikus útvonalakat inkább az
/etc/rc.conf
állományban
rögzítsük:
# A 2. belső hálózat elérését felvesszük statikus útvonalként static_routes="belsohalo2" route_belsohalo2="-net 192.168.2.0/24 192.168.1.2"
A static_routes
konfigurációs változó
karakterláncok szóközzel tagolt
felsorolását tartalmazza. Mindegyik
karakterlánc egy útvonal neve. Az iménti
példában csak egyetlen ilyen név
szerepelt a static_routes
értékében, amely a
belsohalo2
volt. Utána
beírtunk még egy konfigurációs
változót is, amelynek a neve
route_belsohalo2
.
Ide helyeztük a route(8) parancsnak
átadandó beállítás
összes paraméterét. Ez pontosan olyan,
mintha a következő parancsot adtuk volna ki:
#
route add -net 192.168.2.0/24 192.168.1.2
Ezért kellett a "-net 192.168.2.0/24
192.168.1.2"
.
Ahogy már korábban is
említettük, a static_routes
értékében több karakterláncot
is megadhatunk, aminek segítségével
egyszerre több statikus útvonalat is
létrehozhatunk. A következő sorok arra
mutatnak példát, hogy a 192.168.0.0/24
és 192.168.1.0/24
hálózatok
számára miként állítsunk be
statikus útvonalakat a képzeletbeli
útválasztónkon:
static_routes="net1 net2" route_net1="-net 192.168.0.0/24 192.168.0.1" route_net2="-net 192.168.1.0/24 192.168.1.1"
Azt már tudjuk, hogyan adjuk meg a külvilág felé vezető útvonalakat, azonban arról még nem beszéltünk, hogy kívülről miként találnak meg bennünket.
Annyit már megismertünk, hogy az útválasztási táblázatokban megadhatjuk a hálózaton azt a gépet, amelyen keresztül az adott címtartomány (a példában egy C osztályú alhálózat) felé küldhetünk, amely pedig továbbküldi a hozzá érkező csomagokat.
Amikor a csatlakozunk az internet-szolgáltatónkhoz, a nála levő útválasztási táblázatok úgy állítódnak be, hogy az alhálózatunk felé igyekvő adatok a korábban létrejött PPP összeköttetésen keresztül jutnak el hozzánk. A világ többi részén levő rendszerek viszont honnan fogják tudni, hogy a mi internet-szolgáltatónknak küldjenek?
Van egy rendszer (ez leginkább a névszerverek elosztott információs adatbázisához hasonlít), ami nyilvántartja a pillanatnyilag kiosztott címtartományokat és megadja a csatlakozási pontjukat az internet gerinchálózatán. Ez a „gerinc” tulajdonképpen olyan fővonalakból áll, amelyen keresztül a világban az országok között mozog az internet forgalma. A gerinchálózat mindegyik gépe tárolja a központi útválasztási táblázatok egy másolatát, ami a forgalmat egy adott hálózatról a megadott gerincbeli hordozóra irányítja át, végig az internet-szolgáltatók láncán egészen addig, amíg az el nem éri a hálózatunkat.
A szolgáltatónk feladata, hogy a gépünk felé leágazásként (és így a felénk vezető útként) beregisztálja magát a gerinchálózat gépein. Ezt nevezik az útvonal terjedésének.
Néha gondok lehetnek az útvonal terjedésével, és egyes gépek nem képesek elérni minket. A traceroute(8) parancs mind közül talán az egyik leghasznosabb ilyen helyzetekben, mivel ezzel fel tudjuk deríteni, hogy az útválasztás hol akad meg. Ugyanilyen jól hasznosítható azokban az esetekben, amikor látszólag nem tudunk elérni egy távoli gépet (tehát a ping(8) csődöt mond).
A traceroute(8) parancsnak annak a távoli gépnek a nevét kell megadnunk, amelyhez csatlakozni akarunk. Futása közben megjeleníti azokat az átjárókat, amelyeken keresztül csatlakozni próbál, akár sikerült elérni a célgépet, akár a kapcsolat hiánya miatt kudarcot vall.
A parancs használatáról és működéséről részletesebb információkat a traceroute(8) man oldalán találunk.
A FreeBSD alapból támogatja mind a multicastet használó alkalmazásokat, mind pedig a multicasthez tartozó útválasztást. Multicast esetében semmilyen speciális beállítás nem szükségeltetik, az ilyen alkalmazások egyből el tudják érni ezt a lehetőséget. A multicast kérések útválasztásához azonban be kell építenünk némi támogatást a rendszermagba:
options MROUTING
Emellett még el kell indítanunk az
mrouted(8) démont is, amelyhez az
/etc/mrouted.conf
állományban
még be kell állítanunk tunneleket és
a DVMRP használatát. A
multicasthez tartozó további
beállításokat az mrouted(8) man
oldalán találhatjuk.
A FreeBSD 7.0 megjelenésével a mrouted(8) démont kivették az alaprendszerből. Azt a DVMRP többesküldési protokollt valósítja meg, amelyet a legtöbb alkalmazásban mostanság már a pim(4) segítségével oldanak meg. Ennek megfelelően a hozzá tartozó multicast protokollt valósítja meg, amelyet a legtöbb alkalmazásban mostanság már a pim(4) segítségével oldanak meg. Ennek megfelelően a hozzá tartozó map-mbone(8) és mrinfo(8) segédprogramok is eltávolításra kerültek. Ezek a programok attól a kiadástól kezdődően a Portgyűjtemény részeként érhetőek el a net/mrouted portban.
Ha kérdése van a FreeBSD-vel kapcsolatban, a
következő címre írhat (angolul):
<questions@FreeBSD.org>.
Ha ezzel a dokumentummal kapcsolatban van kérdése, kérjük erre a címre írjon:
<gabor@FreeBSD.org>.