SCCM konzol küzdés

Egyik kedves ügyfélnél erősen proxyzott környezet van. A SCCM-nek engedélyezték az auth nélküli proxy-t, meghatározott URL listával.

A feladat az SCCM co-management beállitása volt. Pár kattintás, Azure bejelentkezés, semmi extra. Aham…

Jól rákészültünk a proxybeállitásokra:

  • Winhttp proxyt beállitottuk (netsh winhttp show proxy szépen visszaadta)
  • SCCM site server opciónál a proxy-t belőttük
  • Az Edge böngészőben is definiáltuk a proxyszervert
  • Még a .NET frameworkbe is beillesztettük a proxy konfigot

 

Ezek után az SCCM konzol a csatlakozáskor úgy befagyott mint a szög. Pár percig nézegette a köldökét, a proxy szerver felé semmilyen forgalom nem ment, aztán feldobta a microsoft loginablakot, végigment a név/jelszó/mfa, majd nem történt semmi.

“Mindig a hálózat a hibás. Mindig.” ezt régi kollégától hallottam, szeretjük is mindenre ráhúzni, de mivel forgalom nem ment a proxy felé, nehéz volt rásütni. De négy helyen is definiálva van a proxy, miért nem talál oda?

Végül process monitorral vizsgálva előbújt, hogy a Microsoft Configuration Management.exe küzd kihivásokkal. Szerencsére neki is lehet proxyt beállitani (az ötödiket!), mégpedig a C:\Program Files (x86)\Microsoft Endpoint Manager\AdminConsole\bin folderben a Microsoft.ConfigurationManagement.exe.config fileba kell definiálni:

<system.net>
<defaultProxy useDefaultCredentials=”true” />
</system.net>

Ezek után már gond nélkül kitalált a proxyn keresztül és sikerült a co-management beállitás…

Exchange 2019 CU 14 megjelent

Megjelent az idei első Cumultative Update az Exchange Server 2019-hez: Download Cumulative Update 14 for Exchange Server 2019 (KB5035606) from Official Microsoft Download Center

A CU alapból bekapcsolja majd az Extended Protection feature-t (Windows Extended Protection <extendedProtection> | Microsoft Learn), aki ezt nem szeretné, az telepítse powershellből a CU-t a /DoNotEnableEP vagy /DoNotEnableEPFEEWS kapcsolóval.

A TLS 1.3 támogatás Windows 2022 Serveren csúszik, a CU15-be fogják (remélhetőleg) implementálni.

SCCM szívás

Kb. 2009 óta foglalkozom az SCCM-mel, persze az utóbbi években egyre kevesebbszer, de azért előkerül. Ez az a termék, ami mindig lenyűgöz, hogy úgy érzem, értek már hozzá, aztán arculcsap a valóság…sokszor prózai okokból.

Ügyfélnél telepitettem SCCM-et, szépen működgetett, majd csendben lejárt a trial időszak (ritkán nyomogattam a konzolt). Sebaj, termékkulcs megad, konzol feléled, menjünk karácsonyozni.

Most újra elővettem a konzolt, szép zöld minden (system status, component status), de valahogy mégsem csinál semmit….a logokban nincs error, csupán azt tűnt fel, hogy kb az összes logfile egyszerre megállt december 15. 13:45-kor.

Benéztem a szervizek közé, de felesleges, mert fut minden…és hoppá!..az össze főbb service stopped állapotban van, Manual start opcióval.

Gyorsan visszaállitottam Automaticra őket és a service-ek elinditása után feléledt a SCCM is (a screenshot felúton készült) Hogy ezek mitől mentek manualba, tippem sincs…

Újabb lecke, hogy sosincs unásig tudott dolog, meglepi mindig érhet…

Nem divat a frissítés

Elgondolkodtató…

…in late November there were 30,635 machines on the public web with an unsupported version of Microsoft Exchange:

  • 275 instances of Exchange Server 2007
  • 4,062 instances of Exchange Server 2010
  • 26,298 instances of Exchange Server 2013

 

MS-220 vizsgaélmény

Múltkor utaltam az Exchange vizsgára (Volt vizsga, nem lesz vizsga – E-mail és a detektívek (emaildetektiv.hu) ma nekiláttam.

Sikerült megugrani 800 ponttal, de elég érdekesre rakták össze. A kérdésekről nem beszélek, sokáig úgysem aktuálisak, de tartsuk az NDA-t.

Szóval, csomó powershelles kérdés volt, még a Case Study-kban is. Ezen picit húzom a számat, nem feltétlenül ez a jó tudásmérő, hogy kétsoros ps-eket kell összeraknod. A sima kérdések közül sok olyan volt, ami a való életben felmerült, bár vagy 10 kérdés a journalinggal foglalkozott, talán ez sem olyan releváns.

És nem lehet MS-vizsga félreérthetőség nélkül. Van egy device-od, ami mailt küld az EXO-n keresztül. Melyik a jó válasz, felveszed az ip-t az spf rekordba vagy veszel neki O365 licenszet és azon keresztül állitod be. Tipikusan az attól függ kérdés, de ilyen kevés infóval csak találgathatsz, mire gondolt az MS.

Jó vizsga volt összeségében, sajnálom hogy megszűntetik, mert aktuális a tudásanyaga, de igy alakult. Aki kedvet kapott hozzá (:D) július 31-ig levizsgázhat.

Exchange Server Security Updates – June 2023

Nincs új a nap alatt; ebben a hónapban is kapnak Security Update-et az Exchange Serverek

Exchange 2016 CU 23: Download Security Update For Exchange Server 2016 CU23 SU8 (KB5025903) from Official Microsoft Download Center

Exchange 2019 CU 13: Download Security Update For Exchange Server 2019 CU13 SU1 (KB5026261) from Official Microsoft Download Center

Exchange 2019 CU 12: Download Security Update For Exchange Server 2019 CU12 SU8 (KB5026261) from Official Microsoft Download Center

Grafikus segédlet:

Exchange Online és a throttling/blocking

Nem vadonatúj az infó, de nem árt észben tartani: az EXO blokkolni fogja a sebezhető Exchange szerverektől érkező leveleket.

Sebezhető=nem támogatott verzió/nem megfelelő patch verzió

Kétkörös lesz a bekeményítés:

  • Throttling
    • ha a küldő szerver nem megfelelő, az EXO egy “450 4.7.230 Connecting Exchange server version is out-of-date; connection to Exchange Online throttled for 5 mins/hr. For more information see https://aka.ms/BlockUnsafeExchange” üzenetet fog visszadobni
  • Blocking:
    • Ha a throttling után sem lett belőle támogatott Exchange verzió, akkor jön a “550 5.7.230 Connecting Exchange server version is out-of-date; connection to Exchange Online blocked for 10 mins/hr. For more information see https://aka.ms/BlockUnsafeExchange” üzenet.

 

Nézzük a timeline-t, hogyan történik majd:

Stage 1: ez a report-only mode, az adminnak 30 napja van hogy rendbeszedje az Exchange kiszolgálót.

Stage 2-4: elkezdődik a throttling és minden 10 napban növekszik.

Stage 5-7: beindul a throttlink ÉS blocking, a blokkolás is 10 naponta növekszik.

Stage 8: az EXO nem fogad el leveleket az Exchange szervertől.

 

Az első áldozata a fenti szigorításnak az Exchange 2007 lesz, abban az esetben ha van outbound connectora az EXO-ba. Bízzunk benne hogy nincs sok ilyen, de soha ne mondd hogy biztos.

A következő körökben a Microsoft bővíti majd a blokkolandó termékek körét, függetlenül attól, hogy EXO konnektoron vagy sima SMTP-n csatlakozna be. Ezekről a Message Centerben lehet majd tájékozódni.

Exchange Server vagy Exchange Online – melyiket válasszuk?

A múltkori cikkben megnéztük, milyen támogatott on-prem verziók maradtak, most járjuk körbe, hogy maradjunk-e a földön vagy költöztessük a felhőbe az egész levelezés miskulanciát.

Tegyük fel hogy szerencsés helyzetben vagyunk, nem vonatkozik ránk az 50-es törvény, egyéb szabályozások, szabadon mehetünk a felhőbe, ha szeretnénk. Ott állunk tehát a döntés küszöbén:

  • Maradjon teljesen on-prem az Exchange?
  • Migrájunk az Exchange Online-ba és végre kapcsoljuk ki az utolsó Exchange Servert?

A döntéshez segitséget adhat a Microsoft Shared Responsibility modeljének áttanulmányozása (Shared responsibility in the cloud – Microsoft Azure | Microsoft Learn) . Egy ábrát emelnék ki, elég beszédes:

Ahogy látjuk, ha on-premise maradunk, akkor bizony minden felelősség a miénk, mindent nekünk kell megoldani; a fizikai szervereinket, storage-okat, hálózatot stb. Ok, eddig is ezt tettük, de manapság ez komoly nyűg is lehet.

Félmegoldásnak felmerülhetne, hogy akkor legyen IaaS, hiszen akkor a Microsoft megoldja helyettünk a datacenter-szerverek üzemeltetésének problémáját.  Ez nagyon rossz ötlet, amellett hogy drága lenne, nem is olyan a performancia, mint pl. az Exchange Online esetén. Egyszóval ne futtassunk felhőben Exchange Servert.

A harmadik út a SaaS, azaz az Exchange Online. Ahogy a fenti képen látjuk, ez tűnik a legkényelmesebbnek, a gyártó szinte minden feladatot levesz rólunk. Technikailag is nehéz érvelni ellene (ok, a felhő is leállhat néha, illetve ha féltjük az adatainkat, hybrid esetén vissza is migrálhatjuk a postafiókokat a földi környezetbe).

Mivel gyakorlatilag minden szervezet használ már O365 vagy M365 licenszeket (főleg a Teams miatt), amikben benne van Exchange Online licensz is (sőt, hybrid esetén a Microsoft ad ingyen Exchange 2019 licenszet is, csak migrálj), adja magát a verdikt: költöztessük fel a felhőbe a levelezést.

Hozzáteszem, hogy ez egy általános megközelítés; minden cégnek a saját szempontjai alapján kell mérlegelni, egyedi igényeket és külső szabályozásokat figyelembe venni.

Exchange Server – miből gazdálkodjunk

Kis áttekintés 2023 júniusában, hogy milyen on-prem Exchange rendszerekkel dolgozhatunk.

Bár gondolnánk, hogy egy levelező szerveren nem kell annyit frissítgetni, a gyártója másképp látja. Nézzük meg az ismert verziókat, hogy állunk most.

  • Exchange 2010 SP3: 2020 október 13-án megszűnt mindenféle támogatás. Váltani kell.
  • Exchange 2013 SP1 : idén április 11-én befejezte földi (haha) pályafutását, no longer supported. Váltani kell.
  • Exchange 2016: még állja a sarat, bár az alap támogatás megszűnt 2020 október 13-án, az utolsó CU 2022-ben jelent meg (CU23) , a security update-ek érkeznek majd egészen 2025 október 25-ig. Microsoft világban jártasak már elkezdenek előre tekinteni.
  • Exchange 2019: jelen tudásunk szerint az utolsó legény a vártán. Egészen 2025 októberéig támogatott lesz, amikor megérkezik az Exchange v.Next (?) Már akinek, mert a Software Assurance kötelező lesz hozzá.

 

Aki tehát a földön szeretne (vagy kötelező neki) maradni, az üzenet világos: migrálj minél hamarabb Exchange 2019-re (hunyorítsunk együtt, hogy elvileg 128 GB RAM a beugró…) és húzd ki 2025-ig, amíg megjelenik a “v.Next”. Aki pedig már 2019-et használ, szorgalmasan frissítse a CU/SU-kat hónapról-hónapra.

 

Hová tartunk?

Üdvözlet az Exchange-szcéna megmaradt tagjainak.

Aki követi kicsit a termék életútját, láthatja, hogy az Exchange halott. A Microsoft gőzerővel tol mindenkit a felhő felé, egyre inkább az a mantra, hogy ne üzemeltesd már, hanem migrálj az EXO-ba és megoldódnak gondjaid.

Borús is lehetne a hangulatunk, de inkább nézzük meg, mit lehet manapság kihozni az Exchange-ből és hogyan lehet összeilleszteni a felhős testvérével. Ezekről szeretnék a jövőben írni, még ha nem is csak szívásokat megörökíteni, de hátha hasznos lesz.

Nemsokára folytatjuk…

Valami lesz

Gondolom, mindenki észrevette, hogy az utóbbi időben a blog bejegyzései megritkultak. Na jó, megszűntek. Tulajdonképpen csak azért nem zártam még be, mert jó volt tesztelgetni rajta azokat a dizájn megoldásokat, melyeket később be szerettem volna vezetni a mivanvelem blogon.

Hogy miért szűnt meg?
Erről nem akarok litániákat írni, a legfontosabb ok, hogy már nem volt mit megírnunk. Gömöri Zoli (SUF) teljesen eltávolodott az Exchange-től, a munka melletti hobbijáról meg külön blogokban irkál. (Magyar nyelvű, angol nyelvű.)
Én ugyan az Exchange/M365 közelében maradtam, de már sok éve nem végzek operatív munkát. Innentől szívjanak a fiatalok. Ha nagyon elakadnak, akkor még megpróbálom irányba állítani őket, de ezek már az ő történeteik.

Ebbe az egyre jobban kiszáradó pocsolyába dobott bele egy követ Istvánffy Zoli. Nemrég megkeresett, hogy ő is szokott szívni és ezeket szívesen publikálná a blogon. Természetesen elutasítottam. Viszont felajánlottam neki, hogy ha van hozzá kedve, akkor vigye tovább az oldalt. Volt.

Nekem ez az utolsó írásom ezen a blogon, egyfajta búcsú, Gömöri Zoli pedig itt integet mellettem.
Az átadás-átvétel folyamata elindult. Istvánffy Zoli gondolom majd megírja, mik a tervei a bloggal. Az eddigi szakmai jelenléte alapján úgy gondolom, nem lesz gond a folytatással.

Semmi rendkívüli

Annyi év, annyi cucli után nem igaz, hogy még mindig ilyesmiket csinálok. SCCM-et telepítettem és az istennek sem akart összejönni az SQL kapcsolat. Pedig lassan már a reménytelen dolgokat is kipróbáltam. Végül a Wireshark egyik csomagjának elemzése során vettem észre, hogy elgépeltem egy betűt az instance megadásakor. (Sccm vs scmm.) Mondhatni klasszikus.

Most azt kellene írnom, hogy amint javítottam a nevet, egyből hasított… de nem. Jó vicc, akkor nem töltötte volna ki a telepítés a délutánomat. Szexuált működni. Igaz, ekkor már tényleg a belső tűzfal volt a saras, amint kikapcsoltam, ment minden. Csak hát… ez nem annyira korrekt. Viszont nem tudtam mást csinálni: az SCCM folyamatosan lehetetlen RPC portokra kapcsolódott az SQL-en, olyanokra, melyeket komoly rendszerszolgáltatások használtak. Hiába korlátoztam én le az SQL-t statikus portokra, ha ennek a szerencsétlennek annyi más is kellett. Végül hagytam a francba, a két szerver között engedélyeztem az any-any kapcsolatot, így van is tűzfal, meg a kommunikáció is megy.
Majdnem azzal fejeztem be, hogy hurrá, tkp mindenki örül, de jobban belegondolva, ez inkább az a szituáció, amikor mindenki szomorú egy kicsit.

Hoppá

Ezt az írást érdemes alaposan átolvasni – és végiggondolni. Az internet alapműködését feszegeti a téma.

A lépések számottevő problémát jelentenek, a Symantec-csoporthoz tartozó CA-k (a Symantec, VeriSign, az Equifax, a GeoTrust, a Thawte, RapidSSL és más kisebb márkák) által kibocsátott tanúsítványok ugyanis széles körben elfogadottnak számítanak.
link

Azaz a Google, konkrétabban a Chrome felül fogja bírálni a fenti CA-k által kiadott tanúsítványokat, sőt, az is benne van a pakliban, hogy nem fogja elfogadni ezeket. Ugye te is észrevetted a VeriSign nevét a felsorolásban? Az sem érdektelen, hogy a Symantec válaszként beszüntette az RA programot, azaz innentől a fenti CA-k mellett nem működhetnek külsős RA szolgáltatók.

Az a szerencsétlen Edge

Már eddig is csak úgy fityegett. Adott valamennyi pluszt, de cserébe pénzt kért és komplikációkat okozott.
Most jött a bejelentés, hogy az MS támogatási elveiben változás történt.

  • A Windows Server 2016-ra telepített Edge szerver nem támogatott.
  • A Windows Server 2016-ra telepített Exchange antispam ügynökök nem támogatottak.
  • A korábbi Windows szervereken használhatod ezeket, de tudjál róla, hogy az a bizonyos Smartscreen – azaz gyakorlatilag a content filter szupertitkos algoritmusa – visszavonásra került, pontosabban, van, de nem frissül. Azaz nincs.

Mit tehetsz? Használd a Microsoft online megoldását, az Exchange Online Protection-t, vagy használj külső gyártótól származó offline megoldást.

Ennyi. A magam részéről annyira nem bánom. Az Edge jelentősége már régóta periférikus volt, az antispam ügynököket lehetett ugyan használni egy utolsó utáni védelmi vonalként, de a menedzselésük tragikus volt, hasonlóan a hatásfokuk is. Vegyük le a kalapunkat és egy perces néma csönd.

Kemp, az új TMG 05

Nos, eddig csak karcolgattuk a felszínt. Ne felejtsük el, ez egy loadbalancer, értelemszerűen ezen a területen kell neki nagyot domborítania.
Ha szigorúan nézzük, akkor egy szerver reverz proxyzása tulajdonképpen a terheléselosztás speciális esete, ekkor ugyanis csak egy szerver között kell elosztanunk a terhelést. Viszont ha már ezen a területen jók vagyunk, akkor nem nagy ugrás a terhelést két, vagy több szerver közé teríteni.

Nézzük először azt a reverz proxyt. Jelen esetben a felállás egyértelmű: van a belső hálón – vagy a DMZ-ben – egy szerverem, ennek egy, vagy több szolgáltatását szeretném a külvilág felől elérhetővé tenni.

A Kemp szóhasználatában virtuális szerverek léteznek. Egy virtuális szerver (VS) rendelkezik mindennel, mely módon kívülről látni szeretnénk: IP címmel, porttal (portokkal) és viselkedéssel. A virtuális szerver mögött van egy, vagy több real szerver: ezek a publikálandó szerverek. (Nem, a real nem azt jelenti, hogy fizikai szerver.) Értelemszerűen a real szervereknek is vannak paraméterei. (A real szervereket kiválthatják ún. SubVS-ek, azaz a virtuális szerverekbe ágyazott alsóbb szintű virtuális szerverek. Ez egy csoda dolog, de majd később foglalkozunk velük. Viszont nem árt tudni, hogy a virtuális szerverek mögött mindig van real szerver, azaz a SubVS-ek mögött is lenniük kell.)

Akkor jöjjenek az ábrák.

From Segédlet

Jelen állapotban így néznek ki a virtuális szervereim. Aki szeret előrerohanni, már most szétnézhet, mit is lát. Az első négy sorban az egyes belső szervereim (192.168.199.0/24) 3389-es portjait sorra kipublikálom a loadbalancer 10.19.64.21-es címén, különböző custom portokon. Ezek mindegyike egy-egy virtuális szerver. (Két real szerver erőforrás problémák miatt le lett kapcsolva.) Az ötödik sorban pedig a szegény ember Exchange publikációja látszik: a belső Exchange szerver 443-as portja ki lett forgatva a loadbalancer külső lábára. Látható, az eszközön nincs tanúsítvány (certificate installed: on the real server). Szerencsére a Kemp ennél sokkal-sokkal többre képes.

Vegyünk észre egy furcsaságot: mindegyik virtuális szerver L7 szinten üzemel. Egy sima portforward. Vajon miért?

De előtte nézzük meg, hogyan hozhatunk létre egy virtuális szervert.

From Segédlet

Add New gomb, alapbeállítások. Töltsük ki értelemszerűen. (A 4444-es külső portra fogok fordítani.)

From Segédlet

Amikor létrehoztuk, megjelenik az első kilométer hosszúságú beállítóablak. Ne tévesszen meg, hogy elfértünk egy képernyőn: csak azért, mert egy csomó almenüt bezártam.
De nem úszod meg, ki fogom nyitogatni. Mindet.
Egyelőre azt vedd észre, hogy a Real Servers ablakban egymás mellett van az Add New és az Add SubVS gomb. Én mondtam.

A Basic ablakban sok meglepetés nincs. A virtuális szervert ki tudom publikálni másik IP címen is. Ha pedig deaktiválom a szervert, akkor a nyitólapon az éppen nem működó szerverek narancssárga színben jelennek meg. (Nem olyan ronda pirossal, mint fentebb.)

From Segédlet

Ez már a Standard panel. A továbbiakban nem áll szándékomban minden sort külön elmagyarázni, azért a beállítások elég beszédesek. (Ne feledjük el, hogy az alap cél a terheléselosztás szerverek között, nem pedig a publikálás.)

From Segédlet

Az SSL beállítások. Elég karcsú. Ja. Addig, amíg nem engedélyezzük az SSL Acceleration funkciót. Akkor viszont akkora ablak lesz belőle, hogy ihaj.

From Segédlet

Én megmondtam. Na, ezekbe a beállításokba most biztosan nem fogunk belemenni. (SNI? Kiváncsi vagyok, kinél szólal meg a csengő.)

From Segédlet

Advanced panel. Itt lehet beállítani, ha az LB cluster egyik node-ja sem működik, akkor melyik szerver melyik portjára küldje a forgalmat. Állíthatunk külön default GW-t a virtuális szerver számára és külön Access List-et is.

From Segédlet

Adjuk már végre hozzá a real szervert. Látható, hogy jelen példában a DC RPC Endpoint Mapper szolgáltatását (135-ös port) publikálom ki. (Mert meszet ettem.) Ha L7 LB-t választunk, akkor a NAT-ot nem lehet megváltoztatni.

From Segédlet

Nos, ezt hoztuk össze. Látható, hogy átböktem L4-re a boszme nevű virtuális szervert, de egyébként semmi különös. Innentől már nyomulhatunk is a 4444-es portra, feltéve, hogy tudjuk, mire jó egy DC 135-ös portja.

Nem tartozik szorosan a tárgyhoz, de ha esetleg valaki nem ismeri, tudom ajánlani a portquery segédprogram-csomagot. Ez áll egy parancsoros programból és egy portqueryui.exe nevű grafikus felületből. Ezzel lehet letesztelni, hogy egy adott port nyitva van-e? Azért bánjunk óvatosan vele, IDS programok támadásnak vehetik, ha túl sokat szkennelünk vele. Nagy előnye a Windows gépekre jellemző port csomagok használata. Például tudja azt, hogy egy domain & trust működéshez milyen portokat kell vizsgálnia.

From Segédlet

Tudom, a hekkerprogramok ennél jóval többet tudnak, de hé, ez egy Microsoft által gyártott segédprogram!

Rögtön nézzük is meg vele, hogy mit csináltunk?

From Segédlet

Remek. Valaki figyel azon a 4444-es porton. Innentől törölhetjük is azt a böszme virtuális szervert.

Nem árt tudni, hogy nem minden esetben kell ennyire nulláról felépítenünk egy virtuális szervert. A Kemp oldaláról letölthető egy csomó template.

From Segédlet

Én például ennyit telepítettem. Valószínűleg nem fogom mindet használni, de már csak az is tanulságos, ha átnézegetem ezeket. A félreértések elkerülése végett, egyik sablonban sincs olyan dolog, melyeket a fenti képernyőkön nem láthattunk. (Illetve, de: az ESP és az SSO még be fog kavarni.) A lényeg, hogy már előre ki van töltve minden, amire szükségünk lehet.

A valóságban azért ennyire nem rózsás a helyzet. Először is tudnod kell, hogy neked éppen jó-e a kiválasztott sablon? Ha nem, akkor tudnod kell, melyik másik sablonból kell építkezned és utána mit kell rajta átállítanod.

From Segédlet

Sablont a virtuális szerver létrehozásánál lehet választani, rögtön az első képernyőnél. Ne lepődjünk meg, ha a fenti ábrákhoz képest _szűkebb_ lehetőségeink lesznek. Ha például RDP szolgáltatást publikálunk, akkor fel sem jön olyan lehetőség, hogy L4 LB. Ne kérdezd, miért. (De itt van a válasz arra a sok L7 értékre a VS-ek között.) Emellett egyszerűen nem kapunk meg néhány panelt. Úgy gondolták, hogy minek.

Nos, ennyi volt az egyszerű publikálás. Hamarosan belevágunk az SSL reencryption, a preautentikáció és az SSO világába, azaz az igazi Exchange publikációba. De most hosszabb szünet jön, mert egyelőre még nem akar kotta szerint muzsikálni az eszköz, nekem pedig éppen nincs időm rá.

Kemp, az új TMG 04

Nos, nézzük meg, hogy muzsikál az eszköz, mint router. De mielőtt mélyebben belemennénk, nem árt tudni, hogy nem routerként árulják. Senki ne várjon funkcióhegyeket, áttekinthetetlen beállítópaneleket.

Nagyjából ebből áll a készlet.

From Segédlet

Nem túl sok, de akár elég is lehet. A Route Management alatti első két menüpont a route tábla szerkesztéséhez kell, emellett van egy elég egyszerű VPN menüpont is. IPSec tunelling, közös titokkal. Egy VPN kapcsolatot ismer (egyelőre), de ehhez is plusz licensz kell. Sokatmondó, hogy a doksiban egy Azure csatlakozást mutatnak be.

Igazából az Access Control alatt vannak azok a dolgok, melyekre szükségünk lesz, ha kommunikálni szeretnénk az eszközön keresztül. ACL-ek. A panelen csak IP szinten állíthatunk fekete, illetve fehér listát. Port szinten nem. A packetfilter még durvább: bekapcsolod, vagy kikapcsolod. De erről még írok.

Első körben azt szerettem volna, ha a cucc routol a két hálózat között. A loadbalancer blogon azt írják (6-os pont), hogy alapértelmezésben a packetfilter ki van kapcsolva. Ha bekapcsoljuk, megöljük a routolást. A helyzet az, hogy egyik állítás sem igazán fedi a valóságot..
Engem például ez a képernyő fogadott.

From Segédlet

Hasonlítsd ezt össze a fenti linken lévő ábrával. A packetfilter engedélyezve van… és _nincs állítási lehetőség_. Újabb guglizás és meg is lett az eredmény.

From Segédlet

Először ki kell kapcsolni a GSLB-t, jelentsen ez bármit is.

From Segédlet

Utána pedig már ki/bekapcsolható a packetfilter.

Kikapcsoltam, két belső szerveren is elindítottam a windowsupdate-t… és nyálcsorgással a szám szélén csak néztem és néztem, hogyan jönnek le a csomagok… és csak néztem, csak néztem. Négy napig. Ez ugyanis egy elhanyagolt tesztkörnyezet volt korábban.

Valójában RRAS/ARR/WAP alapon szerettem volna összerakni egy Exchange kommunikációt a belső hálózat és a szimulált internet között, de beletört a bicskám. Nyilván a routolást azért meg lehetett volna csinálni, de jobban érdekelt a két másik komponens.

Hát, három szerver, egy kliens, legalább egy éve települtek és még soha nem láttak windowsupdate-t. Darabonként 200+ csomag, 2-3 GB. Mindez egy 20 mbps-re korlátozott csövön, egy erőforráshiányos virtuális infrastruktúrán. Úgy, hogy közben piszkálgattam is a routert. Még örülhetek is, hogy csak négy nap volt.

A megismeréshez a klasszikus rendszergazda filozófiát használtam: ignoráltam a manuált. Valószínűleg emiatt voltak a korábban írt szívások is.
Mostanra azért már jobban kiismertem ezt a packetfiltert.

1. Először is, tényleg ennyi. Gondoltam, belépek a karakteres felületen, hátha ott cizelláltabbak a menüpontok.

From Segédlet

Ennyi. Az Access Control Lists alatt ugyanaz van, mint a webes felületen. De mi lehet ez a Local Port Control? Nem ezt keresem?

From Segédlet

Oké. Next.

2. Később elolvasva a manuált (igen, opportunista disznó vagyok), az alábbiakat lehet elmondani erről a csodáról:

  • Ha ki van kapcsolva, akkor nem foglalkozik az ACL-ekkel. Se a tiltással, se az engedélyezéssel. Azaz a packetfilter csak és kizárólagosan arra szolgál, hogy nem ész nélkül routol, hanem az IP címekre korlátozott ACL-ek alapján.
  • A szerver publikálásokat a packetfilter beállítása nem érdekli. (De mindegyik virtuális szerveren állíthatunk külön ACL-eket, melyek a publikálás során figyelembe lesznek véve, ez viszont csak a konkrét virtuális szerver elérhetőségére fog vonatkozni.)
  • Ha a szerverek próbálnak kifelé kapcsolatot kezdeményezni bekapcsolt packetfilter esetén, akkor ha az SNAT (Server NAT) engedélyezve van, akkor megy nekik. Ha nem, akkor nem.
  • Bekapcsolt packetfilter esetén lehetőségünk van komplett interfészre forgalmat tiltani.

Ez az elmélet. Nem egészen vág egybe a tapasztalataimmal, de nem tudok mit mondani, hiszen eleinte ész nélkül állítgattam mindent. Lehet, belejátszott a tiltásokba a windowsupdate forgalom is. Nem tudom. De mára lement minden frissítés, a doksinak megfelelően beállítgattam mindent és most rendben működik. Ahogy kell neki.

Miket igértem még?

  • Hálózati kártyák között route/nat állítás. Ilyet nem találtam. Viszont globálisan is, illetve virtuális szerver szinten is állítható, ami szvsz pont elég jó megoldás.
  • A port forwarding gyakorlatilag bekerült a virtuális szerverek közé, így majd ott foglalkozom velük.
  • Protokoll alapú szűrés. Ilyet egyelőre nem találtam. Viszont van WAF (Web Application Firewall) és van olyan, hogy content rules. De ezekből ránézésre semmit nem értettem, nyilván doksit kell hozzájuk olvasni.
  • Látható, hogy edge routernek nem igazán praktikus. Nem tudom beállítani rajta például, hogy a belső hálóról mindenki, vagy akár csak egy részhalmaza a gépeknek, elérje a netet, de csak a 80/443-as portokon. A packetfilter/ACL páros csak IP szinten működik. Lehet játszani egy elérakott proxy szerverrel, de azt sem fogjuk tudni port szinten kontrollálni.
  • Igen, proxy. Ez a funkcionalitás hiányzik az eszközből, azaz a TMG kényelmes webproxy szolgáltatását nélkülözni leszünk kénytelenek. Reverse proxy van, szűrni ekkor valószínűleg a WAF-fal lehet, de proxy, az nincs. Kell elé valami opensource cucc.

Essen még pár szó a network interfészekről.
Alapvetően semmi különös, egyszerűen lehet konfigurálni.

From Segédlet

A beállítási lehetőségek magukért beszélnek. A VLAN Configuration gomb mögött VLAN ID-kat lehet a kártyához adni. Egyedül az Interface Bonding gomb gondolkoztathatja el a naív infomunkást, de ez gyakorlatilag a teaming, azaz így lehet összevonni több interfészt. Innentől nem ethX néven fogunk rájuk hivatkozni, hanem bondX néven. (Értelemszerűen ha bondolni akarunk, meg VLAN ID-ket is hozzáadni, akkor először a bond jön és utána adjuk csak hozzá VLAN ID-ket a bondx virtuális interfészhez.)

[Update]
Aztán eltelt egy újabb éjszaka és megint csak két szervert értem el RDP-n. Már kezdtem volna anyázni, amikor feltűnt, hogy most más a jelenség: az RDP kapcsolat létrejött ugyan (működött a telnet), egy pillanatra be is jött a távoli képernyő, aztán megszakadt a kapcsolat. Hmm? Itt van a megoldás: ez egy Remote Desktop Connection Manager bug. Szerencsére a javításhoz már nem kell Visual Studio-ban patkolni, egyszerűen le kell szedni a 2.7-es RDCM csomagot.
De azért felállt a szőr a hátamon, amikor a reggeli kávénál úgy tűnt, hogy megint vacakol a Kemp. (Innentől persze az is valószínű, hogy a korábbi RDP problémák is az RDCM memóriaproblémái miatt lehettek.)