A terv
Először pár szót arról, hogy MIRőL NEM SZóL ez
az anyag.
Nem akarok a Debian telepítésének menetéről mesélni, feltételezem, hogy aki ebből az anyagból akar profitálni, az már túljutott a telepítés nehézségein, illetve elérhetőek az Interneten kifejezetten a Debian telepítéséről szóló anyagok.
Nem írok részletesen arról, hogy egy-egy szolgáltatásra miért is van szükség a tervezett hálózatban, illetve nem szeretnék az ezekhez kapcsolódó elmélettel sem untatni senkit (bár valamennyit muszáj volt megemlítenem) - akit érdekel, az rengeteg jó dokumentációt találhat az Interneten.
Nem lesz szó ,,tuningolásról'', az egyes szolgáltatások memóriabeállításairól. Mégpedig azért nem, mert ezen opciók nagyon sok mindentől függenek, szinte lehetetlen megoldást mondani az egyes opciók értékére a körülmények pontos ismerete nélkül. Az egy gépen futó szolgáltatások, a sávszélesség, a felhasználók száma, a gépben lévő memória mennyisége - mind-mind olyan tényező1.1, amely az egyes szolgáltatások beállítását befolyásolja.
És most nézzük végre azt, hogy MIRőL SZóL a könyv. Kiválasztottam egy számomra szimpatikus hálózatot (egy C osztályút, a 192.168.10.0 címűt), és ebben a hálózatban szeretnék különböző szolgáltatásokat beüzemelni. Az üzembeállításhoz szükséges feladatok leírása ezen anyag egyik célja.
A szerverek Linuxot fognak futtatni, míg a munkaállomások windowsos gépek lesznek1.2. Lehetséges, hogy egyszer az anyag el fogja érni azt a szintet, amikor linuxos munkaállomások hálózatba állításáról is szót fog ejteni, de ez egyelőre csak nagyon távlati terv.
Nem kötelező minden - az anyagban szereplő - szolgáltatást üzembe helyezni a saját hálózatunkban. Azért ,,zsúfoltam'' bele talán feleslegesnek tűnő szolgáltatásokat (például másodlagos dns szerver), hogy a beállításával kapcsolatos dolgokat be tudjam mutatni.
A fejezetek sorrendje nem az elkészítés sorrendjét határozza meg (bár van olyan, amit csak meghatározott sorrendben lehet végrehajtani, például tanúsítvány generálása előtt nem lehet a tanúsítványt használó LDAP szervert üzembe helyezni). Egyszerűbbnek tűnt, ha minden szolgáltatásról külön fejezet szól (még akkor is, ha maga a szolgáltatás több gépet is érint - ekkor külön alfejezetben szólok a különböző gépek konfigurációs igényeiről). De nézzük meg, hogy milyen szolgáltatásokat terveztem beüzemelni a hálózatban (picit részletesebb magyarázatot az egyes fejezetek elején találhat a Tisztelt Olvasó az egyes szolgáltatások szükségességéről):
- DNS (elsődleges és másodlagos);
- DHCP (egyes gépekhez fixen hozzárendelt IP címek);
- SMTP (a belső hálózat levelezése, valamint az Internet felé
irányuló levélforgalom);
- IMAPS (titkosított kapcsolaton keresztüli levélkezelés,
miközben a levelek a szerveren tárolódnak);
- proxy (sávszélességünk védelme és egyéb megfontolások);
- fájltárolás (fájlok tárolása a szerveren);
- központi felhasználókezelés (egy jelszót minden
szolgáltatáshoz, ,,single sign on'');
- naplózás (központi logszerver, logelemzések);
- backup (ha minden a szervereken van, akkor érdemes
menteni);
- pontos idő (például a titkosításokhoz szükséges, hogy
azonosan járjanak a szerverek órái, de a logokban való
keresgélést is megkönnyíti, ha az összes gép órája azonosan jár);
- belső webszerver (például nyilvános adatoknak);
- tűzfal (védjük meg, amit összeraktunk).
A gépek nevei és IP címei (a belső hálózatban példaként az
akarmi.intra tartománynevet fogom használni) a következők
(ezeket az adatokat fogom felhasználni az egész anyagban, ezeknek
megfelelően készülnek majd el a konfigurációs állományok):
- a belső weboldalakat tároló szerver - intraweb,
192.168.10.247;
- a mentéseket végző szerver - backup, 192.168.10.248;
- a logszerver - syslog, 192.168.10.249;
- a fájlszerver - samba, 192.168.10.250;
- a proxyszerver - proxy, 192.168.10.251;
- a levelezőszerver - mail, 192.168.10.252;
- a DNS-szerver - dns, 192.168.10.253;
- a tűzfal belső hálózat felé néző lába - fw, 192.168.10.254.
Nem lehet megszabni, hogy milyen szolgáltatásokat kell egy gépre összerakni, és melyeket muszáj más gépekre telepíteni. Ebben a kérdésben is csak az általam követett elveket tudom elmondani (plusz még néhány olyan dolgot, amelyet fontosnak tartok kiemelni):
- A DNS és DHCP szolgáltatást azért szoktam egy gépre tenni,
mert hasonló adatokra van szükségük, és egyszerűbb szkriptből
generálni a mindkét szolgáltatáshoz szükséges állományokat. Ez
pedig nehézkes lenne (persze nem megoldhatatlan), ha külön gépen
lennének. Természetesen lehetséges külön gépen futtatni ezeket
az alkalmazásokat, és például cvs-ből venni a konfigurációs
állományokat.
- A DNS-ben (és egyúttal a DHCP-ben is) érdemes valamilyen
rendszer szerint elkülöníteni pár dolgot. A szerverek, a
hálózati nyomtatók, az aktív eszközök és a felhasználói gépek
csoportosítását tartom én célszerűnek. Egy lehetséges megoldás
netmaszk határokon ,,vágni'', ez a későbbi esetleges fizikai
szétválasztást is egyszerűvé teszi. Természetesen bármilyen más
felosztás is megoldást jelenthet, sőt, ilyen jellegű felosztás
nélkül is működőképes a hálózat. Hasznos olvasmányok a
döntéshez az rfc1519.txt
(http://www.ietf.org/rfc/rfc1519.txt) és az rfc1219.txt
(http://www.ietf.org/rfc/rfc1219.txt).
- Az IMAP-on történő levelezés meglehetősen sok feladatot ad
a diszk-alrendszernek (sok egyidejű felhasználó esetén), és a
hálózati forgalma is nagy tud lenni. Emiatt nem célszerű
hasonlóan nagy hálózati forgalmat bonyolító szolgáltatásokkal egy
gépre telepíteni, amilyen például a
sambaés asquid. - A proxy (
squid) is komolyan képes igénybevenni a diszk-alrendszert, emiatt célszerű önmagában futtatni, illetve olyan diszkeket (vagy diszkelrendezést) választani, amelyek képesek megfelelni ennek a terhelésnek. A diszkrendszer terhelését befolyásolja például a letöltésre használható sávszélesség is. Még a fájlrendszer kiválasztására is ügyelnünk kell, sőt, a mountolás opcióival is lehetőségünk nyílik gyorsítani a rendszert (például a noatime opcióval). - Az IMAP és az SMTP szolgáltatás egy gépen történő futtatása
ésszerűnek tűnik, hiszen a levelek kézbesítéséhez szükség van egy
MTA-ra (SMTP szolgáltatásra).
- NTP szolgáltatást szoktam a tűzfalra is telepíteni, hogy a
belső szervereknek ne az Internetre kelljen menniük a pontos
időért. Viszont a belső hálózat klienseit nem szoktam a
tűzfalhoz odaengedni, ezért a belső hálózaton is létre szoktam
hozni NTP szervert (vagy szervereket), amelyek közvetlenül a
tűzfalhoz szinkronizálják az óráikat, és szolgáltatnak a kliensek
felé. Amennyiben nem áll rendelkezésünkre egy gép, amely a belső
ntp szerver lehetne, akkor természetesen a kliensek
szinkronizálhatnak a tűzfalon futó ntp szerverhez.
- Ugyanez a helyzet a DNS szolgáltatással is. A tűzfalra is
telepítek, hogy a belső DNS szerver ne az Interneten lévő
szerverekkel beszéljen. Ily módon csak a tűzfallal kell
beszélnie. De a tűzfal is csak a belső hálózat dedikált DNS
szervereivel kommunikál, a kliensek nem érhetik el a tűzfalon
futó DNS szolgáltatást közvetlenül. Amennyiben nem áll
rendelkezésünkre egy külön gép, amely a belső DNS szerver
lehetne, akkor természetesen a klienseknek is el kell érniük a
tűzfalon futó DNS szervert.
- A központi logszerverre nem igazán érdemes mindenki számára
elérhető szolgáltatásokat telepíteni, nehogy a felhasználók
elfoglalják a logolás számára létfontosságú sávszélességet.
Célszerű a logelemző programokat is ezen a gépen futtatni, nem
pedig a különálló szervereken, bár vigyáznunk kell, hogy az
elemző programok ne terheljék le annyira a gépet, hogy az ne
legyen képes mással foglalkozni.
- A mentéseket végző (és tároló) gépre lehetőség szerint
semmilyen kívülről elérhető szolgáltatást nem szabad rakni,
hiszen (valószínűleg) a lehető legtöbb érzékeny adatot ez a
szerver tárolja.
- Az
rsynccsomag sokszor a segítségünkre lehet, érdemes telepíteni. Alapbeállításban nem fut démonként, tehát nem nyújt lehetőséget a gép kívülről történő elérésére. Jellemzőensshcsatornán keresztül használjuk.
Kosa Attila
2009-03-23