Segédlet a BorderManager Enterprise Edition 3.5 alkalmazásához
Scott Jones – Novell Consulting
Bevezető
A BorderManager Enterprise Edition (BMEE) egy szoftvercsomag, amelynek célja, hogy javítsa és bővítse az NDS és a NetWare biztonsági és kapcsolati szolgáltatásait. A BMEE az alábbi szolgáltatásokkal bővíti a NetWare-t:
- WAN-médiák kezelése
- Emelt szint csomagszrés
- Hálózati címfordítás (Network Address Translation, NAT) – a patchelt NetWare 5-ben már benne van;
- Virtuális magánhálózatok (VPN) kezelése, telephelyek közötti és kliens-telephely típusúaké egyaránt
- Távoli hozzáférés (RADIUS-szal) és modemmegosztás
- IP-átjárók – IPX/IP és IP/IP áramköri átjárók (circuit gateway)
- Különféle proxyszolgáltatások, többek között láthatatlan HTTP-proxy
- Különféle cache-szolgáltatások, mindkét irányúak
- Hozzáférés-vezérlés
- Tartalomszrés
A jelen dokumentum a BMEE 3.5-ös verzióját tárgyalja. Javalatot tesz a szerverek elhelyezésére és konfigurációjára, valamint néhány megjegyzést ejt a BorderManager telepítéséről és a szokásos szolgáltatások konfigurációjáról. Habár a BMEE egyes komponensei kezelik az IPX/SPX-protokollokat is, az alábbiakban csak TCP/IP-ről lesz szó.
A szerverek elhelyezése és konfigurációja
Fizikai és logikai elhelyezés
A BorderManager-szerverek a fizikai és logikai hálózaton való elhelyezése a legfontosabb tervezési szempont. Ez határozza meg, hogy a kitzött célok hogyan valósíthatók meg (ha egyáltalán). A helyes elhelyezés kialakításához pontosan ismerni kell a hálózati infrastruktúrát.
Ahhoz, hogy tzfalként szolgáljon, a BMEE-szervernek legalább két hálózat interfésszel kell rendelkeznie, és a hálózatok közötti átjáróként mködnie (ld. 1. ábra). Előfordulhat azonban is, hogy egy BMEE-szervernek csak egy fizikai csatolója van. Az ilyen, végponti elhelyezés megfelelő lehet például a RADIUS- vagy VPN-szerverek számára, ha nem használunk tzfalszolgáltatásokat. Még a proxy/cache-szolgáltatások is mködtethetők egy végponti szerveren, bár ez esetben a felhasználók egyszer módon megkerülhetik a proxyt.
1. ábra: BMEE-szerver, mint átjáró, tzfalként alkalmazva
Tzfal- vagy hierarchikus cache-szolgáltatások tervezését a legfelső ponton kezdjük. Ez jellemzően az elsődleges kapcsolat az Internet felé. Az eszköz, amely a csatlakozást biztosítja, lehet akár egy BMEE-szerver, akár egy külső útválasztó. Akármelyik is, az első BMEE-szervernek rendelkeznie kell egy olyan interfésszel, amelynek legalább egy bejegyzett nyilvános IP-címe van (célszer ezt a kártyát PUBLIC névre keresztelni). Ha a szerver statikus címfordítást (NAT-ot) végez, akkor egynél több nyilvános címre is szükség lehet.
Alakítsunk ki elegendően nagy alhálózatot ahhoz, hogy bőségesen megfeleljen a hálózat előrelátható igényeinek. Ha az Internet-szolgáltató számozatlan vagy nem útirányított (unrouted) kapcsolatot biztosít, akkor szükség lesz egy külső útválasztóra is, mint az első BMEE-szerverrel együtt a kapcsolódást biztosító eszközre. A 2. ábra e konfigurációra mutat példát..
2. ábra: BMEE-szerver nem útirányított ISP-kapcsolat esetén
Távoli telephelyeken pénz takarítható meg, ha a BMEE-szerver biztosítja a kapcsolatot. A BorderManager kezeli a legtöbb WAN-médiát, így a bérelt vonalakat, a Frame Relay-t, az ISDN-t és az ATM-et. A szolgáltatók azonban a legtöbb esetben adnak egy útválasztót, akár kell, akár nem, így feleslegben maradhat egy eszköz a szerver mellett. Ha az ISP a nyilvános hálózatot elérhetővé teszi a közte és az ügyfél közötti vonalon, akkor ezt az extra útválasztót lehet transzparens bridge-ként használni.
Megjegyzés: A rendszer kezeli a behívásos kapcsolatokat is, de ezek hasznáalta nem ajánlott. Egy állandó 56/64 vagy T1/E1 kapcsolat a legstabilabb és a legegyszerbben konfigurálható.
Nagyobb szervezeteknél előfordulhatnak olyan komplex igények, amelyek megkövetelik, hogy a BMEE-szolgáltatások több szerverre való elosztását és egy ún. "demilitarizált zóna" (DMZ) kialakítását. Tegyük fel például, hogy több száz felhasználó számára kívánunk NAT- és VPN-szolgáltatásokat biztosítani. Mivel mindkettő igen processzorigényes funkció, érdemes külön szervereket alkalmazni. A VPN-szerverek azonban nem tehetők a NAT-eszközök mögé. Ez esetben ugyanis, mivel a NAT új fejlécet tesz a csomagokra, nem lehetséges a SKIP-párbeszéd a VPN-csomópontok között és nem tudják megbeszélni a titkosítás módját sem. A VPN-szervernek tehát a NAT-szervernél "feljebb" kell elhelyezkednie. (Az egyéb típusú tzfalmegoldások kialakításáról részletesen a BMEE termékdokumentációjában lehet olvasni.)
A saját belső hálózaton belül a szokásos infrastruktúra-tervezési elvek érvényesek. Például célszer a szerverek közötti ugrások számának minimalizálása egy hierarchikus cache-struktúra kialakításával. Ez azt eredményezheti, hogy néhány külső útválasztót el kell távolítani, vagy át kell konfigurálni őket hídnak. Az útválasztó-hardver helyben hagyása tartalék kapcsolatot biztosíthat: ha a BMEE-átjárószerver hosszabb időre kiesne, a régi útválasztó gyorsan átkonfigurálható.
Elhelyezés az NDS-fán belül
Habár a BorderManager egy szerverközpontú termék, az NDS-t használja a konfiguráció részleteinek tárolására és a a hitelesítéshez. Szinte minden alkalmazásszint konfiguráció a "Szerver"-objektum segítségével történik. A BMEE "Szerver"-objektumainak a címtárfában való elhelyezése tehát kritikus fontosságú, csakúgy, mint annak eldöntése, hogy a szerverek mely replikákat tartalmazzák.
A BorderManager-szervereket lehetőleg a felhasználóihoz közel kell elhelyezni az NDS-címtárfában. Egy helyi iroda esetében például a BMEE-átjárószervert lehetőleg az adott földrajzi hely OU-jába tegyük. A cél, hogy minimálisra csökkentsük a címtárfában való keresgélést és a szerver által igényelt replikák számát. Ha megvalósítható, tegyük az összes felhasználót és szabályt egy helyi replikába (a szabályok elhelyezéséről később még szólunk).
Megjegyzések a szerver konfigurációjával kapcsolatban
A proxy/cache szerverek finomhangolásakor az alábbi minimális környezeti beállításokra van szükség:
set maximum packet receive buffers = 2500
set maximum interrupt events = 50
set immediate purge of deleted files = on
set garbage collection interval = 5
set minimum packet receive buffers = 1000
set new packet receive buffer wait time = .1 sec
set maximum service processes = 1000
set minimum service processes = 500
set new service process wait time = .3 sec
set worker threads execute in a row count = 15
set pseudo preemption count = 200
set enabled file compression = off
set enable disk read after write verify = off
set maximum file locks = 100000
set directory cache allocation wait time = 0.1 sec
set directory cache buffer nonreferenced delay = 60 min
set maximum number of internal directory handles = 500
set maximum directory cache buffers = 10000
set minimum directory cache buffers = 2500
set maximum concurrent directory cache writes = 125
set maximum concurrent disk cache writes = 750
set dirty disk cache delay time = .1 sec
E beállítások értelmét a TID #2949807 és a TID #10012765 taglalja (megtalálható a http://support.novell.com címen). Szintén e TID-ek segítenek abban, hogy további hangolás esetén mit érdemes állítani.
- Maximum Physical Receive Packet Size. A BMEE online dokumentáció tartalmazza a "Maximum Physical Receive Packet Size" (maximális fizikai fogadási csomagméret) változó javasolt beállításait, és ezek általában helyesen mködnek is. Az egyetlen kivétel, hogy ha a szerverben lévő WAN-kártya frame relayhez csatlakozik, akkor a telekommunikációs kapcsoló miatt lehetséges, hogy 1514-nél kisebb értéket kell beállítani. Ha a javasolt beállításokkal nem folyik adat át a WAN-kapcsolaton, akkor a PING.NLM segítségével, a ping-csomag méretének 1514-ről való folyamatos csökkentésével határozzuk meg azt az értéket, amelyeknél már jönnek válaszok, és legyen ez a maximum fizikai fogadási csomagméret. Szintén megoldás a Set Use Specified MTU = On parancs kiadása, de az ronthatja az átviteli teljesítményt.
Ha a WAN-kapcsolat Point-to-Point Protocolt (PPP-t) használ – ilyen lehet egy behívásos vonal vagy egy "clear channel" DDS-áramkör –, akkor a maximális fizikai fogadási csomagméretet 10-zel meg kellhet növelni a javasolt értékekhez képest, a PPP-fejléc miatt. - Minimális hardverkövetelmények. Az összes BorderManager-szolgáltatás képes egyidejleg futni meglepően gyenge hardveren. Ha a szerverben van legalább 64MB RAM, akkor képes kiszolgálni egy kisebb csoportot. A cache-funkciók azonban óriási mértékben növekednek több RAM használata esetén; 256 MB vagy több memória javasolt, amennyiben lehetséges.
Mivel a titkosítás és a csomagfordítás processzorigényes funkciók, nagy környezetekben (több mint néhány száz felhasználó esetén) a VPN, a NAT és az IP-átjárókat célszer külön szerverekre tenni. - Szerverkötetek. Célszer külön köteteket készíteni a cache és a naplózás számára, hogy a SYS kötet ne teljen be. A cache hatékonysága javítható 8 vagy 16 kilobájtos blokkok használatával, a tömörítés és a blokk-részallokáció kikapcsolásával. Az NSS-kötetek jól használhatók a cache számára, de további finomhangolásra van szükség (ld. TID #2949807).
- Statikus útválasztás. Ahol csak lehetséges, használjunk statikus útválasztást a BMEE-szervereken. Ez minimális mértékben terheli meg a szervert és nem növeli az útválasztó útkeresési forgalmát, amely már így is létezhet a hálózaton. Mivel a BMEE-szerverek tipikusan "felfelé irányú" (upstream) átjárók, az egy statikus alapértelmezés útvonal és a minimális hálózati utak beírása igen egyszer lehet.
- A licenceléssel kapcsolatos kérdések. A BorderManager licencrendszere eltér e legtöbb többi Novell-termékétől. A hálózati réteg szolgáltatásaihoz (szrés, NAT, telephelyek közötti VPN s.í.t.) csupán egy szerverlicencre van szükség. A felhasználói hitelesítést igénylő szolgáltatásokhoz (távoli hozzáférés, tartalomszrés stb.) felhasználói licencet igényelnek. A felhasználók a szerveren futó BorderManager-alkalmazáshoz hitelesítik magukat, nem pedig a NetWare-hez, így a BorderManager-szervereken általában elég a hozzájuk kapott NetWare-alaplicenc. Az egyes komponensek külön is kaphatók, háromféle csomagban (Firewall Services, VPN Services és Authentication Services), amely a dedikált szerverek használata esetén pénzt takaríthat meg.
A BorderManager telepítése
Ha kialakítottuk a szerverek helyét, aBorderManager telepítése már egyszer. A telepítőprogram az összes komponenst előkészíti a konfiguráláshoz. A telepítés három lépésből áll:
- A BorderManager telepítése a szerveren
- Az NWAdmin-bővítőmodulok telepítése
- A CyberPatrol telepítése (igény esetén)
A BorderManager telepítése a szerveren
A BMEE 3.5 NetWare 4.11, 4.2, 5.0, 5.1, valamint a Kisvállalati NetWare 4.2, 5.0 vagy 5.1 változataira telepíthető. Az aktuális OS-szervizcsomagokat fel kell telepíteni. Az online dokumentáció minden egyes OS-hez külön telepítési utasításokat tartalmaz. A BorderManager kiterjeszti az NDS sémáját, így a telepítő személynek Supervisor joggal kell rendelkeznie a címtárfa gyökerét illetően. Csakúgy, mint minden egyéb fontos NDS-mvelet előtt, ellenőrizzük a címtárfa állapotát, mielőtt a telepítéshez látnánk.
Alapértelmezés szerint a BRDCFG.NLM betöltődik, miután a szervert a telepítés végeztével újraindítjuk. A "Secure the Public Interface" (a nyilvános interfész biztosítása) funkcióval bekapcsoljuk a csomagszrőket az alapértelmezés szrőkkel. NetWare 4.x-en alapértelmezés szerint az összes BMEE-szolgáltatás le van tiltva. NetWare 5-ön alapértelmezés szerint a hozzáférés-vezérlés és a HTTP-proxy be vannak kapcsolva, minden más BMEE-szolgáltatás pedig ki.
Az NWAdmin-bővítőmodulok telepítése
A szervizcsomag telepítése és a szerver újraindítása után futtassuk le a a SYS:PUBLIC\BRDRMGR\SNAPINS\ könyvtárban található SETUP.EXE nev programot, amely a NetWare Administrator moduljait telepíti. Ha a PKI-modul még nincs fent a szerveren, azt is telepíti, de a SYS:PUBLIC\ könyvtárba. Onnan kézzel kell átmásolni a PKISNAP.DLL-t a WIN32\SNAPINS\ alkönyvtárba.
A CyberPatrol telepítése (opcionális)
A CyberPatrol egy sor előre elkészített "URL-tiltó" (deny-by-URL) szabály, amely a SYS:ETC\CPFILTER\CP_SETUP.EXE futtatásával telepíthető. A BorderManager a CyberPatrol egy 45 napos próbaváltozatát tartalmazza.
A BMEE konfigurációja: a szerverkonzol
A BorderManager konfigurációjának nagy része az NWAdminból végezhető el. Az alacsonyabb rétegek konfigurációjának nagy részét azonban a szerverkonzolnál, az INETCFG, FILTCFG és NWCCON segédprogramokkal kell elvégezni. Két további segédprogram – a VPNCFG és a BRDCFG – használatos még, valamint egy NIASCFG nev átjáró NLM az összes segédprogramhoz.
A csomagszrés és a NAT tipikusan két olyan szolgáltatás, amelyet a szerverkonzolnál kell konfigurálni.
A csomagszrés a legegyszerbb hálózatihatár-védelmi mechanizmus. A szrők a hálózati és szállítási rétegekben mködnek, és minden más BorderManager-komponens előtt hajtódnak végre. A szrőket a FILTCFG.NLM-mel konfigurálhatjuk.
A dinamikus NAT (vagy az útválasztás nélküli IP-átjáró) egyfajta "természetes" tzfalat biztosít abban az értelmeben, hogy az Internetről senki nem tud párbeszédet kezdeményezni egy belső csomóponttal. Nem védi ugyanakkor magát a BMEE-szervert, sem a statikus NAT-ra beállított gépeket. A hozzáférési szabályok hiánya esetén e funkciók azt sem tudják korlátozni, hogy a felhasználók milyen forgalmat kezdeményezhetnek. A csomagszrők képesek kitölteni ezeket a hézagokat.
Jellemzően kétfajta hozzáállás van a csomagszrés (és a hálózati határ védelmének) kialakítása során: az egyik az "engedni mindent és külön tiltani", illetve a "tiltani mindent és külön engedélyezni". A BorderManager alapértelmezés szerint az utóbbit alkalmazza. Ha a telepítés során még nem tettük volna meg, az alapértelmezés szrők és kivételek a BRDCFG elindításával hozhatók létre. Ez az alábbi tagadó TCP/IP csomagszrőket hozza létre:
| Forrás-interfész | Célinterfész | Protokoll ID | Forrásport | Célport | Forráscím | Célcím |
| Public | Bármi | IP | Mind | Mind | Bármi | Bármi |
| Bármi | Public | IP | Mind | Mind | Bármi | Bármi |
A BRDCFG ezenkívül létrehozza az alábbi szrési kivételeket is:
| Forrás-interfész | Célinterfész | Protokoll ID | Forrásport | Célport | Forráscím | Célcím |
| Public | Bármi | TCP | Mind | 443 | Bármi | Bármi* |
| Public | Bármi | TCP | Mind | 1024-65535 | Bármi | Bármi |
| Public | Bármi | UDP | Mind | 1024-65535 | Bármi | Bármi |
| Public | Bármi | TCP | Mind | 213 | Bármi | Bármi |
| Public | Bármi | TCP | Mind | 353 | Bármi | Bármi |
| Public | Bármi | UDP | Mind | 353 | Bármi | Bármi |
| Public | Bármi | SKIP (57) | Mind | Mind | Bármi | Bármi |
| Public | Bármi | TCP | Mind | 80 | Bármi | Bármi |
| Bármi | Public | IP | Mind | Mind | Bármi | Bármi |
* Ez a nyilvános interfész tényleges IP-címe.
Ne feledjük, hogy a BorderManager 3.x képes állapotmegőrző (stateful) szrésre is. Amennyiben szükséges, az 1024-65536-os dinamikus portokhoz rendelt kivételek törölhetők. Ezután a BorderManager-szerveren és a statikus NAT-tal elért gépeken futó szolgáltatások stateful-szrői beírhatók. Ez így biztonságosabb konfiguráció, mivel a dinamikus portok blokkolva vannak, kivéve, ha ténylegesen egy párbeszédben vesznek részt.
Hálózati címfordítás (Network Address Translation, NAT)
A NAT használatával megoldható, hogy a BorderManager-szerver mögött, a szervezet belső hálózatán ún. "magán" ill. bejegyzetlen IP-címeket használjunk. A dinamikus NAT legnagyobb előnye a gyorsan fogyó nyilvános IPv4-címek megőrzése – hisz egyetlen bejegyzett cím képes kiszolgálni privát csomópontok ezreit. Kellemes mellékhatás ezenkívül, amit már említettünk az előző részben, hogy a dinamikus NAT egyfajta természetes tzfalat hoz létre, amely megakadályozza, hogy a nyilvános Internetről bárki párbeszédet kezdeményezzen egy belső csomóponttal.
Ha arra van szükség, hogy egy belső gépet is el lehessen érni az Internetről, akkor egy, a NAT-szerver nyilvános interfészéhez kötött nyilvános címet kell választani számára, azt leképezni az adott gép belső, privát címére. Ezt hívjuk "statikus NAT"-nak. A belső gép védelmére ezután szrőket tehetünk a nyilvános címre.
A nyilvános interfészen mködő dinamikus és statikus NAT-ot az INETCFG-ben állíthatjuk be (ld. 3. ábra), a Bindings | 3. ábra: A dinamikus és statikus NAT bekapcsolása az INETCFG.NLM-ben
A statikus NAT konfigurálásához válasszunk nyilvános címeket azon gépek számára, amelyek ezt igénylik. Vegyük fel ezeket a NAT-táblázatba, összerendelve a megfelelő belső, privát címekkel. Ezután adjuk a nyilvános címeket a BMEE-szerver nyilvános interfészéhez az "add secondary ipaddress xx.xx.xx.xx" konzolparanccsal (címenként külön kell kiadni). Ezek a címek automatikusan a megfelelő interfészhez lesznek rendelve. E parancsokat írjuk be az AUTOEXEC.NCF végére is, az INITSYS.NCF sor után. A másodlagos IP-címek konfigurációja a "display secondary ipaddress" konzolparanccsal ellenőrizhető.
A NAT bekapcsolása után lehetséges, hogy ki kell még adni a következő konzolparancsot: "set nat dynamic mode to pass thru = on". Ez akkor szükséges, ha a nyilvános Internetről elérendő alkalmazások (GWIA, HTTP és others) a NAT-ot mködtető gépen futnak.
A belső hálózaton tetszés szerinti címek használhatók. Ha viszont az Interneten valójában is létező címeket osztunk ki, akkor a belső csomópontok e címek valódi tulajdonosaival képtelenek lesznek kommunikálni.
Lezárva a hálózati határt a csomagszrőkkel és a NAT-tal, hozzáláthatunk az alkalmazási réteg szolgáltatásainak konfigurálásához az NWAdminban. Itt állíthatjuk be a VPN-t, a hozzáféréseket, a proxykat és a cache-t. Mielőtt hozzálátnánk a szolgáltatások konfigurálásához a "Szerver"-objektum BorderManager Setup lapján, feltétlenül vegyük fel a szerverre a szükséges IP-címeket és pontosan határozzuk meg, hogy azok nyilvános vagy privát címek. Az NDS-ben végrehajtott BMEE-beállítások automatikusan szinkronizálódnak az NLM-ekkel, és azonnal hatályba lépnek.
Hozzáférési szabályok
A hozzáférési szabályok a "Szerver"-objektum BorderManager Setup lapján az "Enforce Access Rules" négyzet kijelölésével kapcsolhatók be. A hozzáférési szabályok minden felhasználóra érvényesek, akik a BMEE-szerveren keresztül próbálnak haladni. Alapértelmezésként egy "Deny All" (minden tiltása) szabály rakódik a "Szerver"-objektumra, amely az új szabályok készítésével folyamatosan egyre lejjebb csúszik a listában (mindig az utolsó).
Szemben a ZENworks irányelveivel, a BorderManager-szabályok nem felhasználó- vagy konténer-, hanem szerverközpontúak. Minden egyes alkalommal, amikor egy BMEE-szerver üzembe áll, a szerver kikeresi a címtárfából a szabályokat, a "Szerver"-objektumtól egészen fel a címtárfa gyökeréig. Csak felfelé keres, más O-kban és OU-kban nem. Minden megtalált szabály a szerver ACL-jébe kerül, ahol az alábbiak szerint rakódik sorba:
Megjegyzés: Az ACLCheck a változásokat 15 percenként keresi ki, teljes frissítést pedig 24 óránként végez.
A szerver minden egyes felhasználói kérést összevet az ACL-ben lévő szabályokkal, ellenőrizve, hogy vonatkozik-e szabály az adott kérésre. Ha igen, a keresés leáll – vagyis a szerveralapú szabályok elsőbbséget élveznek.
Egy példa arra, hogyan is mködik mindez:
O=EMEA (szabály=DENY ALL)
Ha mindhárom konténerben találhatók felhasználók, akkor úgy gondolhatnánk, hogy kizárólag a Legal konténer felhasználói férhetnek hozzá a BMEE_Serverhez. Csakhogy a szerver a szabályokat a "Szerver"-objektumtól felfelé keresi ki, így már a az OU=Legal (szabály=Allow All) szinten talál megfelelő szabályt. Vagyis mindhárom konténer felhasználói teljes hozzáférést élvezhetnek.
Az egyes hálózatok igényei eltérő szabály-elhelyezési döntéseket eredményezhetnek. Kis környezetekben az összes szabály a "Szerver"-objektumokba beírásával egyszersíthető az élet. A konténerszinten megadott szabályok viszont nagyobb környezetben segíthetnek elkerülni a dupla munkát, hiszen az összes lejjebb található szerverre érvényesek. Szintén segíthenek a felügyeleti szerepek elosztásában – de ügyeljünk a replikák elhelyezésére. A szabványos NDS-tervezési elvek betartásával elkerülhető a címtárfában való felesleges keresés, a túl sok replika hasnzálata és a WAN-kapcsolatokon keresztüli replikálás. Ne felejtsük, hogy a CyberPatrol-szabályok csak a "Szerver"-objektumokon állíthatók be. Ez szándékosan van így, a licencrend betartása érdekében.
A BMEE konfigurációja: NetWare Administrator
|------OU=Corp (szabály =DENY ALL)
|------OU=Legal (szabály =ALLOW ALL)
|------CN=BMEE_Server
