Fejezet 12. Hálózatok

A “lemez nélküli működés” kifejezés arra utal, hogy a FreeBSD rendszerünk hálózaton keresztül indul el, valamint a működéséhez szükséges állományokat nem merevlemezről, hanem egy szerverről olvassa be. Ennek részleteiről kézikönyv lemez nélküli működésről szóló részében olvashatunk.

Igen. Ezzel kapcsolatban a kézikönyv Egyéb haladó hálózati témák című fejezetét javasoljuk elolvasásra, különös tekintettel az útválasztás és az átjárók bemutatására.

Ezt a kérdést általában olyanok teszik fel, akiknek két számítógépük van otthon, és ezek közül az egyiken a FreeBSD, a másikon pedig a Windows valamelyik változata fut. A FreeBSD rendszer fog az internethez csatlakozni, és ezen keresztül szeretnénk a windowsos gépről is elérni azt. Ez tulajdonképpen az előző kérdés egy speciális esete, és remekül megoldható.

Ha betárcsázós kapcsolattal csatlakozunk az internethez, akkor érdemes tudnunk, hogy a felhasználói módban futó ppp(8) tartalmaz egy -nat kapcsolót. A ppp(8) programot úgy tudjuk a -nat kapcsolóval futtatni, ha az /etc/rc.conf állományban a gateway_enable beállítást a YES értékre állítjuk. Ezután állítsuk be a windowsos gépünket ennek megfelelően és minden működni fog. A további részletekről a ppp(8) man oldalán vagy a kézikönyv felhasználói PPP-ről szóló bejegyzésében olvashatunk.

Amennyiben rendszerszintű PPP-t használunk vagy Ethernettel csatlakozunk az internethez, akkor a natd(8) démonra lesz szükségünk. Erre vonatkozóan a kézikönyv natd démonról szóló szakaszában találhatunk részletesebb információkat.

Igen. Érdemes elolvasnunk az slattach(8), sliplogin(8), ppp(8) és pppd(8) man oldalakat. A ppp(8) és a pppd(8) egyaránt támogatja a beérkező és kimenő kapcsolatokat, miközben a sliplogin(8) kizárólag csak beérkező kapcsolatokkal dolgozik, valamint a slattach(8) pedig csak kimenő kapcsolatokkal.

Ezek pontos használatáról olvassuk el a kézikönyv PPP-ről és a SLIP-ről szóló fejezetét.

Ha viszont csak egy “shellen” keresztül érjük el az internetet, akkor hasznos lehet megnéznünk a net/slirp csomagot. Segítségével a helyi gépről (korlátozott módon) hozzá tudunk férni különböző FTP és HTTP szolgáltatásokhoz.

Igen. Ha egy felhasználói PPP kapcsolat esetén szeretnénk hálózati címfordítást alkalmazni, akkor olvassuk el a kézikönyv felhasználói PPP-vel foglalkozó részét. Ha viszont más típusú hálózati kapcsolatok esetén kívánunk címfordítást használni, akkor ahhoz a kézikönyv natd démonnal kapcsolatos részét kell fellapoznunk.

Ezt illetően a kézikönyv PLIP-ről szóló szakaszát érdemes megnéznünk.

Amennyiben az álnév ugyanazon az alhálózaton található, mint a hozzátartozó interfész, akkor egyszerűen csak adjuk meg a netmask 0xffffffff paramétert az ifconfig(8) parancs meghívásakor, például így:

# ifconfig ed0 alias 192.0.2.2 netmask 0xffffffff

Minden más esetben a hagyományos módon adjunk meg egy hálózati címet és egy hálózati maszkot:

# ifconfig ed0 alias 172.16.141.5 netmask 0xffffff00

Erről bővebben a FreeBSD kézikönyvben olvashatunk.

Ha a kártyán egy másik portot szeretnénk használni, akkor ahhoz meg kell adnunk egy további paramétert a ifconfig(8) meghívásakor. Itt az alapértelmezett port a link0. Ha a BNC helyett az AUI portot akarjuk használni, akkor ennek a link2 értéket kell megadnunk. Az ilyen típusú beállítások az /etc/rc.conf állomány (lásd rc.conf(5)) ifconfig_* változóival adhatóak meg.

A személyi számítógépekben található bizonyos hálózati kártyák (szépen szólva) ügyesebbek a többieknél, ami az olyan komolyabb hálózati alkalmazások, mint például az NFS esetén gondokat okozhat.

Ezzel kapcsolatban kézikönyv NFS-ről szóló részét érdemes megnéznünk.

A Linux egyes változataiban található NFS kód csak bizonyos privilegizált portokról fogad el kéréseket. Próbáljuk meg a következőt:

# mount -o -P linux:/valami /mnt

A SunOS™ 4.X változatait futtató munkaállomások csak privilegizált portokról fognak el kéréseket. Próbálkozzunk az alábbi paranccsal:

# mount -o -P sun:/valami /mnt

Ez leginkább azért történik, mert nem jól adtuk meg az /etc/exports állomány tartalmát. Olvassuk át a exports(5) man oldalt és a kéziköny NFS-ről szóló részét, különös tekintettel az NFS beállítására.

Próbáljuk meg az /etc/rc.conf állományban (lásd rc.conf(5)) kikapcsolni a TCP kiterjesztések használatát úgy, hogy az alábbi változót a NO értékre állítjuk:

tcp_extensions=NO

A Xylogic által gyártott Annex típusú gépek esetén is javasolt megtenni a fenti változtatást.

A FreeBSD alapértelmezés szerint támogatja a multicast műveleteket. Amennyiben egy multicast küldéseket közvetítő útválasztót szeretnénk beállítani, akkor újra kell fordítanunk a rendszermagunkat a MROUTING beállítás használatával és elindítani a mrouted(8) démont. Ez a démon úgy aktiválható a rendszer minden egyes indításakor, ha az /etc/rc.conf állományban az mrouted_enable változót YES értékűre állítjuk.

Az MBONE használatához további eszközök találhatóak a külön mbone kategóriában a Portgyűjeményen belül. Ha a vic és vat nevű konferenciaszervező eszközöket keressük, akkor itt érdemes szétnéznünk!

Glen Foster (<gfoster@driver.nsta.org>) a következő listát állította össze róluk, amelyet kiegészítettünk még néhány további elemmel:

Erre a FreeBSD kézikönyvben találjuk meg a választ.

Amennyiben a rendszermagot az IPFIREWALL beállítással fordítottuk le, akkor nem szabad elfelejtenünk, hogy ez alapértelmezés szerint minden olyan csomagot eldob, amelyet külön nem engedélyeztünk.

Ha véletlenül rosszul állítottuk volna be a rendszerünkön futó tűzfalat, akkor a hálózat működését úgy tudjuk visszaállítani, ha root felhasználóként kiadjuk a következő parancsot:

# ipfw add 65534 allow all from any to any

Az /etc/rc.conf állományban is megadhatjuk ehhez a firewall_type="open" sort.

Ha a tűzfalak beállításáról szeretnénk többet megtudni FreeBSD alatt, akkor olvassuk el a kézikönyv erre vonatkozó fejezetét.

Valószínűleg azért, mert nem egyszerűen a csomagok továbbítására (forward) van szükségünk, hanem hálózati címfordításra. Az “fwd” szabály pontosan azt csinálja, amiről a nevét kapta: csomagokat továbbít, de azokon belül semmit sem változtat meg. Tegyük fel, hogy van egy ilyen szabályunk:

01000 fwd 10.0.0.1 from any to ize 21

Amikor egy csomag az ize célcímmel megérkezik a 10.0.0.1 gépre, akkor benne a cél címe továbbra is az ize lesz! A csomag célcíme nem fog magától megváltozni a 10.0.0.1 címre. A legtöbb gép általában eldobja azokat a csomagokat, amelyeket nem egyenesen neki címeztek. Emiatt a “fwd” szabály használata nem minden esetben úgy működik, ahogy arra a felhasználó számít. Ez viszont ilyen, semmilyen hiba nincs benne.

Részletesebb információkat a szolgáltatások átirányításával foglalkozó GYIK-ban, a natd(8) man oldalán vagy a Portgyűjtemény valamelyik port átirányítással foglalkozó portjának dokumentációjában találhatunk.

Az FTP (vagy más egyéb szolgáltatás-) kéréseket a Portgyűjteményen belül található sysutils/socket porttal tudunk átirányítani. Az adott szolgáltatás helyett egyszerűen csak adjuk meg a socket parancsot és annak paramétereit, valahogy így:

ftp stream tcp nowait nobody /usr/local/bin/socket socket ftp.minta.com ftp

ahol az ftp.minta.com az a gép, ahová át akarjuk irányítani a szolgáltatást, az ftp pedig a konkrét szolgáltatás.

FreeBSD alatt alapvetően három eszköz szolgál erre a célra. A dummynet(4) a FreeBSD részeként megtalálható ipfw(4) egyik komponense. Az ALTQ a FreeBSD-ben található pf(4) rendszer része, az Emerging Technologies által fejlesztett Bandwith Manager pedig egy kereskedelmi termék.

Olyan programot akarunk futtatni, amelynek szüksége van a Berkeley Packet Filter (bpf(4)) használatára, azonban a rendszermag ezt nem tartalmazza. Úgy tudjuk aktiválni, ha a rendszermag konfigurációs állományába felvesszük a következő sort, majd fordítunk egy új rendszermagot:

device bpf        # Berkeley Packet Filter

Erre az SMBFS eszközeit használhatjuk, amely tartalmazza az ehhez szükséges rendszermagbeli módosításokat és a hozzátartozó felhasználói programokat. Ezek a programok és a hozzájuk tartozó mount_smbfs(8) man oldal az alaprendszer részei.

Ilyen üzeneteket akkor kapunk a rendszermagtól, ha valaminek a hatására több ICMP vagy TCP reset (RST) választ küld, mint amennyit kellene. Az ICMP válaszok sokszor olyankor generálódnak, amikor használaton kívüli UDP portokat akarnak elérni a rendszerünkön. A TCP reset pedig általában olyankor keletkezik, amikor meg nem nyitott TCP porthoz akarnak csatlakozni. Többek közt ilyenek okozhatják:

• A rendszer túlterhelését célzó, nyers erővel indított Denial of Service (Dos) támadások (ellentétben az egycsomagos, adott sebezhetőség kihasználó támadásokkal).

• A portok szisztematikus letapogatása, amelynek során egyszerre nagy mennyiségű portot próbálnak meg átvizsgálni (ellentétben azzal, amikor csak néhány jól ismert portot nyitnak meg).

Az üzenetben olvasható első szám azt mondja meg, hogy a rendszermag mennyi csomagot küldött volna, ha nem korlátoztuk volna, a második pedig magát a határt jelzi. Ezt a net.inet.icmp.icmplim sysctl változó segítségével tudjuk beállítani, ahogy például most megnöveljük az értékét 300-ra:

# sysctl -w net.inet.icmp.icmplim=300

Amennyiben le szeretnénk tiltani az ilyen jellegű üzeneteket a naplókban, viszont még továbbra is szükségünk lenne a válaszküldés korlátozására, a net.inet.icmp.icmplim_output sysctl változó segítségével így tudjuk ezt megtenni:

# sysctl -w net.inet.icmp.icmplim_output=0

Végezetül, ha teljesen ki akarjuk kapcsolni a válaszküldés korlátozását, akkor állítsuk a net.inet.icmp.icmplim sysctl változót (lásd az előbbi példában) a 0 nulla értékre. A korlát törlése azonban a fenti okok miatt egyáltalán nem ajánlott.

Ez arra utal, hogy valamelyik gép a helyi Ethernet-alapú hálózatunkon olyan MAC-címet használ, amelynek a FreeBSD nem ismeri a formátumát. Valószínűleg olyankor kapjuk ezt a hibaüzenetet, amikor valaki más kísérletezik az Ethernet kártyája beállításaival valahol a hálózaton. Leggyakrabban kábelmodemes hálózatokon tapasztalhatunk ilyet. Megnyugodhatunk, teljesen veszélytelen, semmilyen hatással nincs a FreeBSD gépünk teljesítményére.

Ilyen üzeneteket akkor kapunk, amikor a hálózaton kívülről érkezik hozzánk váratlanul egy csomag. A letiltásukhoz állítsuk a net.link.ether.inet.log_arp_wrong_iface értékét 0-ra.

Először is nézzük meg, hogy az iménti hibaüzenet mellett nem látunk-e valami hasonlót:

/usr/libexec/ld-elf.so.1: Shared object "libXaw.so.6" not found

Az ilyen jellegű hibák általában olyankor keletkeznek, amikor olyan gépre telepítjük a net/cvsup portot, amelyen viszont nem található meg a Xorg programcsomag. Amennyiben szükségünk lenne CVSup programhoz mellékelt grafikus felületre, akkor kénytelenek leszünk mellé az Xorg programjait is telepíteni. Ha viszont egyszerűen csak parancssorból szeretnénk használni a CVSup lehetőségeit, töröljük le a korábban telepített csomagot, majd helyette rakjuk fel a net/cvsup-without-gui vagy a net/csup portot. A FreeBSD újabb változataiban megpróbálkozhatunk a csup(1) használatával is. Ezzel a témával részletesebban a kézikönyv CVSup használatáról szóló része foglalkozik.