Nem, még ebben a részben sem fogunk checkboxokat kattogtatni. Jelen írásban szeretném felvázolni, milyen teszteket tervezek, hová akarok eljutni. Emellett szeretném bemutatni a tesztkörnyezetet is.
From Segédlet |
Nos, ez a játszótér. Habár az ábra szépen strukturált, de valójában csak a Microtik router, a laptopom és a Hyper-v szerver fizikai gép, minden más elem virtuális, természetesen a megfelelő virtuális switchekbe dugdosva. Ezt nem részletezem, úgyis tudod.
A DNS kicsit kacifántos, a szimulált internet miatt. A belső hálózaton (vt12.kft.net) sima AD van, az annak megfelelő DNS-sel. A forwardere a Homelab szerveren lévő DNS szerver. A loadbalancer eth0 lába szintén ugyanezt a DNS szervert használja. Ebben az a trükk, hogy ez a DNS szerver beelőzi az igazi internetes DNS szervereket, azaz akármelyik igazi zónát meg tudom rajta hamisítani, illetve fel tudok venni kamu, internetesnek tűnő zónákat. Logikus, hogy a C2013 kliensgép és a Hyper-v szerveren futó Hmail levelezőszerver is ezt a DNS szervert használja. A Homelab szerveren lévő DNS szerver forwardere a Microtik DNS szervere és innen már szabad az út az igazi internet felé. A laptopom nem vesz részt a kísérletben, onnan csak a Hyper-v szerveren lévő virtuális gépeket tekergetem a Hyper-v menedzseren keresztül.
Mivel alapvetően levelezési rendszer működését akarom tesztelni, értelemszerűen kell egy “internetes” levelezőszerver. Erre tökéletes az ingyenes, egyszerűen konfigurálható Hmail.
A kísérletben szereplő külső kliens nem véletlenül Windows 8.1: ebben már beépítve létezik egy metrós Posta program, mely ActiveSync-et használ. Emulált mobiltelefon helyett ezzel lehet tesztelni az Exchange ActiveSync (EAS) protokoll működését az ‘internet” felől.
A belső hálózaton szerepel még egy vt12-rpx01 nevű szerver: ezen majd egy teljesen kiépített RDS szerver (RemoteApp, RDweb, RDGW) publikálását szeretném tesztelni.
Nagyjából ennyit a környezetről. Nézzük a terveket.
1. Router
- Az eszköz működjön routerként.
- Route tábla szerkesztése.
- Lehessen ki/bekapcsolni a natolást, esetleg külön beállítani az egyes hálózatok között.
- Tudjam a routert konfigurálni: ACL-ek, port forwarding.
- Konfigurálható packet filter, protokoll alapú szűrés.
- Interfészeken VLAN-ok kezelése.
2. Webproxy
- Kifelé menő webes protokollok proxyzása.
- Beavatkozás a webes protokollok kezelésébe (szűrés).
3. Reverse Proxy
- Exchange 2013 szolgáltatások publikálása.
- SMTP forgalom kezelése.
- RDS szolgáltatások publikálása, az Exchange szolgáltatásokkal párhuzamosan.
4. Load Balancer
- Két Exchange 2010 közötti terheléselosztás. (Igen, 2010. A tesztszerverem már nem bírna el olyan környezetet, ahol két 2013-as működne egymás mellett.)
5. Full terhelés
Hosszabb távon nem csak egy belső hálózatot tervezek a loadbalancer mögé. Homokozós/játszós hálózatból is lehet több. Aztán vannak tanfolyami környezetek, melyeket itthon is össze kell raknom, ha fel akarok készülni az oktatásra. (Bár ezeknél nem annyira fontos a külső elérés.) Aztán van egy csomó olyan ügyfél, akiknek az informatikai rendszerében vannak kritikus elemek. Ezeket lemodelleztem itthon, hogy tudjak rajtuk kisérletezni. Ezt a sok-sok alhálózatot jó lenne valahogy összerendezni, elérhetővé tenni. Valahogy.
Amit nem fogok tesztelni, illetve amiben nem vagyok biztos
- Lync, illetve ADFS publikálások. Vannak hozzájuk template-k, de egyelőre ezek nem érdekelnek.
- Minden, amihez ESP kell. Egyelőre nem világos, hogy az ingyenes verzióval mi a helyzet. (A template-kben választhatók ESP opciók, de nem tudom, hogy működnek-e? Ilyenekre gondolok, mint SSO, preautentikáció, illetve SMTP relay.)
- Loadbalancer cluster, azaz magas rendelkezésreállás. Ez hiányzik az ingyenes verzióból.
És akkor most egy hosszabb kihagyás jön az írásokkal. Jelenleg még a tesztkörnyezet sincs teljesen készen és még nekem is hátravan többszáz oldal a Kemp dokumentációjából. Stay tuned.
2015-05-17 at 09:22
Csak szolok, hogy vagy a kep, vagy a cikk van elirva, mindenesetre a kepen az alhalo jelzese alatt (192.168.199.0/24) vt.kft.net van a vt12.kft.net helyett.