Kemp, az új TMG 03

Bár úgy terveztem, hogy a következő írások már a tesztekről szólnak, de rögtön az elején belefutottam két pofonba. Mondhatni, ez egy bréking nyúz.

1. Ne rúgd tökön magadat
Ez egyértelműen a saját hülyeségem. Utólag belegondolva logikus is, de mégis beszoptam.
A loadbalancernek van egy külső interfésze (eth0), ennek van egy IP címe. Ezen keresztül lehet elérni. Első kisérletnek ezen a címen kipublikáltam az Exchange szerver webes szolgáltatásait, nyilván https protokollon. Nem tesztelgettem, ezek még csak az első bátortalan kattogtatások voltak az UI-n. Aztán valamiért újra kellett indítanom az eszközt. És nem tudtam elérni a webes kezelőfelületét. Miért? Azért, mert az elérés az eth0 interfész IP címén a 443-as portra volt konfigurálva. Melyen frankón bejelentkezett az Exchange, amikor ráléptem. Hűha.
Brmennyire nem akartam ebbe a mélységbe leásni, be kellett lépnem a karakteres felületen. Hát, ha valaki arra gondolt, hogy itt kap egy klasszikus linux promptot, root jogosultsággal, nos, téved.

From Segédlet

Ez van. Egy karakteres képernyő, egy menüvel. És csak azt lehet tekergetni, amit a menü enged.
Szerencsére a hozzáférést lehet állítgatni. Local administration / web address.

From Segédlet

Gyorsan át is böktem a well-known 444-es portra, innentől már hozzáfértem a GUI-hoz. Felvettem egy másik IP címet az eth0 interfészre, átraktam erre az Exchange publikációt, a GUI elérést pedig a karakteres felületen visszaállítottam az eredeti portra. Utólag nem volt egy nagy ügy, de azért gondolkozhattam volna előtte. (Viszont itt van a megoldás arra az esetre, ha valaki nem dhcp-s környezetbe telepíti: a hostról be kell lépni a virtuális gépbe és beállítani a hálózati paramétereket.)

Csak kettő maradhat. Vagy mégsem?

Ha megnézed a tesztkörnyezetet mutató ábrát, láthatod, hogy a loadbalancer mögött négy virtuális gép figyel. Úgy igazából nem kell, hogy mind a négy gép kapcsolatban legyen a loadbalancerrel, hiszen csak az Exchange szerver és az rpx szerver szolgáltatásait terveztem publikálni, de különböző okok miatt (windows update, rdp hozzáférés) mind a négyet úgy állítottam be, hogy egyfelől a loadbalanceren keresztül elérjék a netet, illetve mindegyikről kipublikáltam az RDP szolgáltatást valami custom porton.
Na, ettől őrültem meg. Mind a négy gép hálózati szolgáltatása (subnet/DNS/DGW) tök ugyanúgy volt beállítva. A publikációik is ugyanarra a sémára épültek, eltekintve persze az egyedi portoktól. A DC-t és az Exchange szervert el is értem. Az RPX szervert és a munkaállomást viszont nem. Ezek a netet sem látták. Téptem a hajam. Wireshark. Semmi használható infó. Persze, hiszem a loadbalancer úgy volt beállítva, hogy ha valami nem jó, akkor eldobja a csomagokat, még RST-t sem küld vissza. (Nem mintha egy RST-vel boldogabb lettem volna.) Aztán jött egy váratlan váltás, hirtelen meghalt az Exchange/DC gépek elérhetősége, illetve internet hozzáférése, viszont hirtelen beindult a másik két gépé. Azaz nem konfigurációs hiba volt, egyszerűen a loadbalancer csak két párhuzamos kapcsolatot volt hajlandó kezelni.
Vakartam a fejemet. Erről eddig szó sem volt. Oké, elolvastam a doksikat, tudtam, hogy az ingyenes verziónál a sávszélesség le lett korlátozva 20 mbps-re.

From Segédlet

Látszik, ki is használtam. Windowsupdate két szerverre.

De a maximum két párhuzamos kapcsolatról sehol sem esik szó. Oké, ír a a cikk memóriakorlátról, de a mérések szerint nagyjából a rendelkezésre álló memória 10-15%-án üzemel a gép, a proci terhelése pedig maximum 10%. Egyelőre nem tudok mást mondani, mint hogy létezik darabszámra vonatkozó korlát. A tesztelésnél végülis nem zavar, terhelést elosztani lehet két szerver között is, de annak az elképzelésnek lőttek, hogy majd ezen a loadbalanceren kötöm össze a tesztelős alhálózataimat.

[Update1]
Aztán eltelt egy hétvége, miközben tekergettem ezt, meg azt. Először azt vettem észre, hogy hirtelen lett net mind a négy belső gépen. Nocsak. Vérszemet kaptam. RDP? Nem, az azért nem. Később felfigyeltem rá, hogy valahogy visszakapcsolódott a packetfilter. (Erről a jószágról hamarosan írok részletesebben is.) Kikapcsoltam, loadbalancer restart. Letöröltem az RDP publikálásokat, majd újra létrehoztam mindet. És innentől mind a négy működik. Ne kérdezd, mi volt a háttérben. Nem tudom.

[Update2]
Ma reggel megint fejreállt a publikálás. De most már tudom, hogy nem a Kemp volt a hibás. Részletek a következő írásban.