12. fejezet - Hálózatok

12.1. Honnan lehet többet megtudni a „lemez nélküli működésről”?
12.2. A FreeBSD használható kizárólag csak hálózati útválasztóként?
12.3. FreeBSD-n keresztül lehet Windows® operációs rendszerrel internetre csatlakozni?
12.4. A FreeBSD támogatja a SLIP és a PPP használatát?
12.5. A FreeBSD támogat hálózati címfordítást (NAT) vagy maszkolást?
12.6. A PLIP segítségével hogyan tudok két FreeBSD rendszert összekapcsolni párhuzamos porton keresztül?
12.7. Hogyan lehet álneveket megadni az Ethernet eszközöknek?
12.8. A 3C503 kártya hogyan állítható másik hálózati portra?
12.9. Miért okoz gondot az NFS használata FreeBSD alatt?
12.10. Miért nem lehet hálózati állományrendszereket csatlakoztatni Linux® alól?
12.11. Miért nem lehet hálózati állományrendszereket csatlakoztatni Sun™ típusú rendszerek alól?
12.12. A mountd miért küld folyton can't change attributes hibaüzenetet és miért jelenik meg a bad exports list hibaüzenet a FreeBSD alapú NFS szerveren?
12.13. A NeXTStep gépekkel miért nem sikerül PPP-n keresztül kommunikálni?
12.14. Hogyan lehet engedélyezni a multicast használatát az IP-n belül?
12.15. Milyen hálózati kártyák épülnek a DEC PCI chipkészletére?
12.16. Miért kell teljes hálózati neveket megadni?
12.17. Miért jelenik meg a Permission denied hibaüzenet minden egyes hálózati művelet esetén?
12.18. Az ipfw „fwd” szabálya miért nem irányít át más gépekre szolgáltatásokat?
12.19. Hogyan lehet egyik gépről a másikra szolgáltatásokat átirányítani?
12.20. Hogyan lehet a sávszélességet szabályozni?
12.21. Miért jelenik meg a /dev/bpf0: device not configured hibaüzenet?
12.22. Hogyan lehet a hálózaton elérhető Windows® típusú partíciókat csatlakoztatni, mint ahogy az smbmount csinálja Linux® alatt?
12.23. Mik azok az Limiting icmp/open port/closed port response üzenetek a naplókban?
12.24. Mik azok az arp: unknown hardware address format hibaüzenetek?
12.25. Miért jelennek meg 192.168.0.10 is on fxp1 but got reply from 00:15:17:67:cf:82 on rl0 üzenetek a konzolon és hogyan lehet ezeket kikapcsolni?
12.26. A CVSup programot telepítése után nem lehet elindítani, mert hibákat jelez. Mi a gond?

12.1.

Honnan lehet többet megtudni a lemez nélküli működésről?

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.

12.2.

A FreeBSD használható kizárólag csak hálózati útválasztóként?

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.

12.3.

FreeBSD-n keresztül lehet Windows® operációs rendszerrel internetre csatlakozni?

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.

12.4.

A FreeBSD támogatja a SLIP és a PPP használatát?

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.

12.5.

A FreeBSD támogat hálózati címfordítást (NAT) vagy maszkolást?

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.

12.6.

A PLIP segítségével hogyan tudok két FreeBSD rendszert összekapcsolni párhuzamos porton keresztül?

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

12.7.

Hogyan lehet álneveket megadni az Ethernet eszközöknek?

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.

12.8.

A 3C503 kártya hogyan állítható másik hálózati portra?

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.

12.9.

Miért okoz gondot az NFS használata FreeBSD alatt?

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.

12.10.

Miért nem lehet hálózati állományrendszereket csatlakoztatni Linux® alól?

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

12.11.

Miért nem lehet hálózati állományrendszereket csatlakoztatni Sun™ típusú rendszerek alól?

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

12.12.

A mountd miért küld folyton can't change attributes hibaüzenetet és miért jelenik meg a bad exports list hibaüzenet a FreeBSD alapú NFS szerveren?

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.

12.13.

A NeXTStep gépekkel miért nem sikerül PPP-n keresztül kommunikálni?

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.

12.14.

Hogyan lehet engedélyezni a multicast használatát az IP-n belül?

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.

Megjegyzés:

A FreeBSD újabb változataiban az mrouted(8) multicast útválasztó démon, a map-mbone(8) valamint az mrinfo(8) segédprogramok már nem szerepelnek az alaprendszerben. Ezek a programok már a FreeBSD Portgyűjteményében az net/mrouted portban találhatóak meg.

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!

12.15.

Milyen hálózati kártyák épülnek a DEC PCI chipkészletére?

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

12.1. táblázat - A DEC PCI chipkészletére épülő hálózati kártyák
GyártóTípus
ASUSPCI-L101-TB
AcctonENI1203
CogentEM960PCI
CompexENET32-PCI
D-LinkDE-530
DaynaDP1203, DP2100
DECDE435, DE450
DanpexEN-9400P3
JCISCondor JC1260
LinksysEtherPCI
MylexLNP101
SMCEtherPower 10/100 (Model 9332)
SMCEtherPower (Model 8432)
TopWareTE-3500P
Znyx (2.2.x)ZX312, ZX314, ZX342, ZX345, ZX346, ZX348
Znyx (3.x)ZX345Q, ZX346Q, ZX348Q, ZX412Q, ZX414, ZX442, ZX444, ZX474, ZX478, ZX212, ZX214 (10mbps/hd)

12.16.

Miért kell teljes hálózati neveket megadni?

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

12.17.

Miért jelenik meg a Permission denied hibaüzenet minden egyes hálózati művelet esetén?

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.

12.18.

Az ipfw fwd szabálya miért nem irányít át más gépekre szolgáltatásokat?

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.

12.19.

Hogyan lehet egyik gépről a másikra szolgáltatásokat átirányítani?

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.

12.20.

Hogyan lehet a sávszélességet szabályozni?

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.

12.21.

Miért jelenik meg a /dev/bpf0: device not configured hibaüzenet?

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

12.22.

Hogyan lehet a hálózaton elérhető Windows® típusú partíciókat csatlakoztatni, mint ahogy az smbmount csinálja Linux® alatt?

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.

12.23.

Mik azok az Limiting icmp/open port/closed port response üzenetek a naplókban?

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.

12.24.

Mik azok az arp: unknown hardware address format hibaüzenetek?

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.

12.25.

Miért jelennek meg 192.168.0.10 is on fxp1 but got reply from 00:15:17:67:cf:82 on rl0 üzenetek a konzolon és hogyan lehet ezeket kikapcsolni?

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.

12.26.

A CVSup programot telepítése után nem lehet elindítani, mert hibákat jelez. Mi a gond?

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.

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>.