31.2. Átjárók és az útválasztás
Készítette: Coranth Gryphon.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).
31.2.1. Példa
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 |
31.2.2. Alapértelmezett útvonalak
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:
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.
31.2.3. Kettős hálózatú gépek
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.
31.2.4. Az útválasztók beállítása
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®.
31.2.5. Statikus útvonalak beállítása
Írta: Al Hoang.31.2.5.1. Manuális konfiguráció
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.
31.2.5.2. Rögzített konfiguráció
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"
31.2.6. Az útvonalak terjedése
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.
31.2.7. Hibaelhárítás
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.
31.2.8. Útválasztás multicast esetén
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.
Megjegyzés: 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.