Hello mindenkinek, a nevem Sergey Emelyanchik. Az Audit-Telecom cég vezetője vagyok, a Veliam rendszer fő fejlesztője és szerzője. Elhatároztam, hogy írok egy cikket arról, hogyan hoztunk létre a barátommal egy outsourcing céget, írtunk szoftvert magunknak, majd elkezdtük azt mindenkinek terjeszteni a SaaS rendszeren keresztül. Arról, hogy kategorikusan nem hittem el, hogy ez lehetséges. A cikk nemcsak történetet, hanem technikai részleteket is tartalmaz majd a Veliam termék létrehozásáról. Beleértve néhány forráskód darabot. Később elmondom, milyen hibákat követtünk el, és hogyan javítottuk ki azokat. Kétségek merültek fel, hogy publikáljanak-e egy ilyen cikket. De úgy gondoltam, jobb megtenni, visszajelzést kapni és fejlődni, mint nem közzétenni a cikket, és átgondolni, mi lett volna, ha...
őstörténet
Egy cégnél dolgoztam informatikai alkalmazottként. A cég meglehetősen nagy volt, kiterjedt hálózati struktúrával. Nem térek ki a munkaköri feladataimra, csak annyit mondok, hogy semmi fejlesztést biztosan nem tartalmaztak.
Volt megfigyelésünk, de pusztán tudományos érdeklődésből meg akartam próbálni megírni a saját legegyszerűbbet. Az ötlet a következő volt: azt akartam, hogy az interneten legyen, hogy könnyen be tudjak lépni anélkül, hogy klienseket telepítenék, és megnézhetem, mi történik a hálózattal bármilyen eszközről, beleértve a Wi-Fi-n keresztüli mobileszközt is, és valóban gyorsan szerettem volna megérteni, hogy mi van a helyiségben olyan berendezés, amely „bolond” lett, mert... nagyon szigorú követelmények vonatkoztak az ilyen problémákra adott válaszidőre. Ennek eredményeként megszületett a fejemben egy terv, hogy írok egy egyszerű weboldalt, amelyen jpeg háttér található hálózati diagrammal, ezen a képen kivágom magukat az eszközöket az IP-címükkel, és a tetejére dinamikus tartalmat mutatok. képet a kívánt koordinátákkal zöld vagy villogó piros IP-cím formájában. A feladat kitűzve, kezdjük.
Korábban Delphiben, PHP-ben, JS-ben és nagyon felületesen C++-ban programoztam. Nagyon jól tudom, hogyan működnek a hálózatok. VLAN, Útválasztás (OSPF, EIGRP, BGP), NAT. Ez elég volt ahhoz, hogy magam írjak egy primitív monitorozási prototípust.
PHP-ben írtam amit terveztem. Az Apache és a PHP szerver Windowson volt, mert... A Linux abban a pillanatban számomra valami érthetetlen és nagyon összetett volt, mint később kiderült, nagyon tévedtem, és sok helyen a Linux sokkal egyszerűbb, mint a Windows, de ez egy külön téma, és mindannyian tudjuk, hogy hány holivar van ez a téma. A Windows feladatütemezője kis időközönként (nem emlékszem pontosan, de valami olyasmi, mint három másodpercenként) előhúzott egy PHP-szkriptet, amely banális ping-el lekérdezte az összes objektumot, és elmentette az állapotot egy fájlba.
system(“ping -n 3 -w 100 {$ip_address}“);
Igen, igen, az adatbázissal való munka abban a pillanatban szintén nem volt elsajátítva számomra. Nem tudtam, hogy lehetséges a folyamatok párhuzamosítása, és az összes hálózati csomópont átjárása sokáig tartott, mert... ez egy szálban történt. Problémák különösen akkor merültek fel, ha több csomópont nem volt elérhető, mert mindegyik késleltette a szkriptet 300 ms-ig. A kliens oldalon volt egy egyszerű looping funkció, amely néhány másodperces időközönként Ajax kéréssel letöltötte a frissített információkat a szerverről, és frissítette a felületet. Nos, akkor 3 egymás utáni sikertelen ping után, ha a számítógépen megnyílt egy weblap monitorozással, akkor egy vidám szerzemény szólalt meg.
Amikor minden sikerült, nagyon megihletett az eredmény, és arra gondoltam, hogy (tudásomnak és képességeimnek köszönhetően) még hozzá tudnék tenni. De mindig nem szerettem a milliós grafikonnal rendelkező rendszereket, amelyekről akkor is és a mai napig azt gondoltam, hogy a legtöbb esetben feleslegesek. Csak azt akartam beletenni, ami igazán segít a munkámban. Ez az elv a mai napig alapvető a Veliam fejlődésében. Továbbá rájöttem, hogy nagyon klassz lenne, ha nem kellene folyamatosan figyelnem, és nem kellene tudni a problémákat, és amikor ez megtörtént, akkor nyissa meg az oldalt, és nézze meg, hol található ez a problémás hálózati csomópont, és mit kezdjek vele. . Valahogy akkoriban nem olvastam e-mailt, egyszerűen nem használtam. A neten akadtam rá, hogy vannak olyan SMS átjárók, ahova lehet küldeni GET vagy POST kérést, és küldenek SMS-t a mobilomra azzal a szöveggel, amit írok. Azonnal rájöttem, hogy ezt nagyon szeretném. És elkezdtem tanulmányozni a dokumentációt. Egy idő után sikerült, és most kaptam egy SMS-t a mobiltelefonomon a hálózati problémákról egy „leesett tárgy” néven. Bár a rendszer primitív volt, én magam írtam, és a legfontosabb, ami motivált a fejlesztésre, az volt, hogy ez egy olyan alkalmazási program, ami igazán segített a munkámban.
Aztán eljött a nap, amikor az egyik internetes csatorna leállt a munkahelyemen, és a monitorozásom nem értesített erről. Mivel a Google DNS továbbra is tökéletesen pingált. Ideje elgondolkodni azon, hogyan tudja nyomon követni, hogy a kommunikációs csatorna él-e. Különböző ötletek születtek, hogyan kell ezt megtenni. Nem fértem hozzá minden felszereléshez. Ki kellett találnunk, hogyan lehet megérteni, hogy melyik csatorna van élőben, de anélkül, hogy magán a hálózati berendezésen meg tudnánk nézni. Aztán egy kolléga azzal az ötlettel állt elő, hogy lehetséges, hogy a nyilvános szerverek útvonalkövetése eltérő lehet attól függően, hogy éppen melyik kommunikációs csatornát használják az internet elérésére. Megnéztem és így alakult. A nyomkövetés során különböző útvonalak voltak.
system(“tracert -d -w 500 8.8.8.8”);
Megjelent tehát egy másik szkript, vagy inkább valamiért ugyanannak a szkriptnek a végére került a nyomkövetés, ami a hálózat összes eszközét pingelte. Végül is ez egy másik hosszú folyamat, amelyet ugyanabban a szálban hajtottak végre, és lelassította az egész szkript munkáját. De akkor ez nem volt annyira nyilvánvaló. De így vagy úgy, elvégezte a dolgát, a kód szigorúan meghatározta, hogy az egyes csatornák esetében milyen legyen a nyomkövetés. Így kezdett el működni a rendszer, amely már felügyelte (hangosan mondták, mert nem volt mérőszám gyűjtés, hanem csak ping) hálózati eszközöket (routerek, switchek, wi-fi stb.) és kommunikációs csatornákat a külvilággal. . Rendszeresen érkeztek SMS-ek, és a diagramon mindig jól látható, hol a probléma.
Továbbá a mindennapi munkában keresztezést kellett végeznem. És belefáradtam abba, hogy minden alkalommal a Cisco switch-eket keressem, hogy megnézzem, melyik felületet használjam. Milyen jó lenne egy objektumra kattintani a megfigyelésben, és megnézni az interfészeinek listáját leírásokkal együtt. Időt takarítana meg. Sőt, ebben a sémában nincs szükség a Putty vagy a SecureCRT futtatására a fiókok és parancsok beviteléhez. Csak rákattintottam a monitorozásra, láttam, hogy mire van szükség, és elmentem a munkámhoz. Elkezdtem keresni a módokat a kapcsolókkal való interakcióra. Rögtön 2 lehetőséggel találkoztam: SNMP vagy SSH-n keresztül bejelentkezés a switchbe, a szükséges parancsok beírása és az eredmény elemzése. Elutasítottam az SNMP-t a megvalósítás bonyolultsága miatt; türelmetlenül vártam az eredményt. az SNMP-vel sokáig kellene a MIB-ben ásni, és ezen adatok alapján adatokat generálni az interfészekről. Egy csodálatos csapat van a CISCO-nál
show interface statusPontosan mutatja, mire van szükségem a kereszteződésekhez. Miért bajlódnék az SNMP-vel, amikor csak ennek a parancsnak a kimenetét szeretném látni, gondoltam. Egy idő után rájöttem erre a lehetőségre. Egy weboldalon lévő objektumra kattintott. Kiváltott egy esemény, amivel az AJAX kliens felvette a kapcsolatot a szerverrel, és az SSH-n keresztül csatlakozott az általam szükséges kapcsolóhoz (a hitelesítő adatok be voltak kódolva a kódba, nem volt kedvem finomítani, külön menüt csinálni, ahol felületről lehetne fiókot váltani , kellett az eredmény és gyorsan) oda beírtam a fenti parancsot és visszaküldtem a böngészőbe. Így aztán egyetlen egérkattintással elkezdtem látni az interfészekkel kapcsolatos információkat. Ez rendkívül kényelmes volt, különösen akkor, ha ezeket az információkat egyszerre különböző kapcsolókon kellett megtekinteni.
A nyomkövetés alapú csatornafigyelés végül nem volt a legjobb ötlet, mert... néha munkát végeztek a hálózaton, és a nyomkövetés változhatott, és a felügyelet elkezdett kiabálni velem, hogy problémák vannak a csatornával. De miután sok időt töltöttem az elemzéssel, rájöttem, hogy minden csatorna működik, és a monitorozásom megtéveszt. Ennek eredményeként megkértem a csatornaképző kapcsolókat felügyelő kollégáimat, hogy egyszerűen küldjenek rendszernaplót, amikor megváltozott a szomszédok láthatósági állapota. Ennek megfelelően sokkal egyszerűbb, gyorsabb és pontosabb volt, mint a nyomkövetés. Egy olyan esemény érkezett, mint a szomszéd elveszett, és azonnal értesítek a csatorna leállásáról.
Továbbá számos további parancs jelent meg, amikor egy objektumra kattintottunk, és az SNMP hozzáadásra került, hogy összegyűjtsön néhány mérőszámot, és lényegében ennyi. A rendszer soha nem fejlődött tovább. Mindent megtett, amire szükségem volt, jó eszköz volt. Valószínűleg sok olvasó azt mondja nekem, hogy az interneten már rengeteg szoftver található ezeknek a problémáknak a megoldására. De valójában akkoriban még nem kerestem a google-ban ilyen ingyenes termékeket, és nagyon szerettem volna fejleszteni a programozási készségeimet, és mi is lehetne jobban ennek érdekében, mint egy valós alkalmazási probléma. Ezen a ponton a megfigyelés első verziója elkészült, és már nem módosították.
Az Audit-Telecom társaság létrehozása
Ahogy telt az idő, más cégeknél kezdtem el részmunkaidőben dolgozni, szerencsére a munkabeosztásom lehetővé tette ezt. Amikor különböző cégeknél dolgozol, nagyon gyorsan fejlődnek a különböző területeken szerzett képességeid, és jól fejlődik a látóköröd. Vannak olyan társaságok, amelyekben – ahogy mondani szokás – svéd, arató és trombitás. Egyrészt nehéz, másrészt ha nem vagy lusta, akkor generalista leszel és ezzel gyorsabban és hatékonyabban oldhatod meg a problémákat, mert tudod, hogyan működik a kapcsolódó terület.
Pavel barátom (szintén informatikus) folyamatosan próbált arra ösztönözni, hogy indítsam be saját vállalkozást. Számtalan ötlet volt, különféle változatokkal, amit csinálnak. Ezt évek óta vitatják. És végül nem lett volna szabad semmivé válnia, mert én szkeptikus vagyok, Pavel pedig álmodozó. Valahányszor ötletet javasolt, mindig nem hittem benne, és nem voltam hajlandó részt venni benne. De nagyon szerettük volna nyitni a saját üzletünket.
Végül sikerült megtalálnunk a mindkettőnknek megfelelő lehetőséget, és azt csináltuk, amit tudunk. 2016-ban úgy döntöttünk, hogy létrehozunk egy informatikai céget, amely segíti a vállalkozásokat az informatikai problémák megoldásában. Ez az informatikai rendszerek (1C, terminálszerver, levelezőszerver, stb.) telepítése, karbantartása, klasszikus HelpDesk felhasználóknak és hálózati adminisztráció.
Őszintén szólva, a cég létrehozásakor nem hittem benne 99,9%-ban. De Pavel valahogy rá tudott venni, hogy megpróbáljam, és előretekintve kiderült, hogy igaza volt. Pavel és én fejenként 300 000 rubelt fizettünk be, bejegyeztünk egy új „Audit-Telecom” LLC-t, béreltünk egy pici irodát, remek névjegykártyákat készítettünk, nos, általában, mint valószínűleg a legtöbb tapasztalatlan, kezdő üzletember, és elkezdtünk ügyfeleket keresni. Az ügyfelek keresése teljesen más történet. Talán írunk egy külön cikket a céges blog részeként, ha valakit érdekel. Hideghívások, szórólapok stb. Ez nem hozott eredményt. Ahogy most sok üzletről szóló történetből olvasok, így vagy úgy, sok múlik a szerencsén. Szerencsések voltunk. és szó szerint pár héttel a cég létrehozása után megkeresett minket Vlagyimir bátyám, aki elhozta nekünk az első ügyfelünket. Nem untatlak az ügyfelekkel való munka részleteivel, a cikk nem erről szól, csak annyit mondok, hogy elmentünk egy auditra, azonosítottuk a kritikus területeket, és ezek a területek megszakadtak, miközben megszületett a döntés arról, hogy folyamatosan együttműködnek velünk, mint kihelyezőkkel. Ezt követően azonnal pozitív döntés született.
Aztán főleg szájról szájra, barátokon keresztül más szolgáltató cégek kezdtek megjelenni. A Helpdesk egy rendszerben volt. A hálózati berendezésekhez és szerverekhez való csatlakozások eltérőek, vagy inkább eltérőek. Néhányan parancsikonokat mentettek el, mások RDP címjegyzéket használtak. A monitoring egy másik külön rendszer. Nagyon kényelmetlen egy csapat számára eltérő rendszerekben dolgozni. A fontos információkat szem elől tévesztik. Nos, például az ügyfél terminálszervere elérhetetlenné vált. A kliens felhasználóitól érkező kérelmek azonnal megérkeznek. A támogatási szakember megnyit egy kérést (telefonon érkezett). Ha az incidenseket és kéréseket egy rendszerben regisztrálták, akkor a támogatási szakember azonnal látja, hogy mi a felhasználó problémája, és elmondja neki azt, miközben egyidejűleg csatlakozik a kívánt objektumhoz a helyzet megoldásához. Mindenki tisztában van a taktikai helyzettel és harmonikusan dolgozik. Nem találtunk olyan rendszert, ahol mindez kombinálva lenne. Világossá vált, hogy itt az ideje, hogy saját terméket készítsünk.
Folytatjuk a munkát a felügyeleti rendszeren
Nyilvánvaló volt, hogy a korábban megírt rendszer teljesen alkalmatlan a jelenlegi feladatokra. Sem funkcionalitásban, sem minőségben. És úgy döntöttek, hogy a rendszert a nulláról írják. Grafikailag teljesen másképp kellett volna kinéznie. Hierarchikus rendszernek kellett lennie, hogy gyorsan és kényelmesen meg lehessen nyitni a megfelelő objektumot a megfelelő ügyfél számára. Az első változathoz hasonló séma jelen esetben abszolút nem volt indokolt, mert Az ügyfelek különbözőek, és egyáltalán nem mindegy, hogy a berendezés melyik helyiségben található. Ez már átkerült a dokumentációba.
Tehát a feladatok a következők:
- Hierarchikus struktúra;
- Valamilyen szerver alkatrész, amit virtuális gép formájában elhelyezhetünk a kliens telephelyén, hogy összegyűjtsük a számunkra szükséges mérőszámokat és elküldjük a központi szerverre, amely mindezt összefoglalva megmutatja nekünk;
- Figyelmeztetések. Akiket nem lehet kihagyni, mert... akkoriban nem lehetett valakinek leülni és csak nézni a monitort;
- Pályázati rendszer. Kezdtek megjelenni olyan ügyfelek, akiknek nem csak szerver- és hálózati berendezéseket, hanem munkaállomásokat is kiszolgáltunk;
- Képes gyorsan csatlakozni szerverekhez és berendezésekhez a rendszerről;
A feladatok ki vannak tűzve, elkezdjük írni. Útközben az ügyfelektől érkező kérések feldolgozása. Ekkor már 4-en voltunk. Egyszerre kezdtük megírni a két részt: a központi szervert és a kliensekhez való telepítéshez szükséges szervert. Ekkorra a Linux már nem volt idegen számunkra, és úgy döntöttünk, hogy a kliensek virtuális gépei Debianon lesznek. Nem lesznek telepítők, csak elkészítünk egy szerverrész projektet egy adott virtuális gépen, majd csak klónozzuk a kívánt kliensre. Ez egy újabb hiba volt. Később világossá vált, hogy egy ilyen sémában a frissítési mechanizmus teljesen kidolgozatlan volt. Azok. adtunk hozzá néhány új funkciót, és ott volt az egész probléma, hogy ezt az összes kliens szerverre terjesztjük, de erre később visszatérünk, minden rendben.
Elkészítettük az első prototípust. Meg tudta pingelni a kliens hálózati eszközöket és szervereket, amelyekre szükségünk volt, és elküldte ezeket az adatokat a központi szerverünkre. Ő pedig ömlesztve frissítette ezeket az adatokat a központi szerveren. Itt nem csak arról írok egy történetet, hogyan és mi volt a siker, hanem arról is, hogy milyen amatőr hibákat követtek el, és hogyan kellett később idővel fizetni érte. Tehát az objektumok teljes fáját egyetlen fájlban tárolták soros objektum formájában. Miközben több klienst is csatlakoztattunk a rendszerhez, többé-kevésbé minden normális volt, bár néha voltak olyan műtermékek, amelyek teljesen érthetetlenek voltak. De amikor egy tucat szervert csatlakoztattunk a rendszerhez, csodák történtek. Néha, valamilyen ismeretlen okból, a rendszer összes objektuma egyszerűen eltűnt. Itt fontos megjegyezni, hogy azok a szerverek, amelyeknek a kliensei POST kéréssel néhány másodpercenként küldtek adatokat a központi szervernek. Egy figyelmes olvasó és egy tapasztalt programozó már sejtette, hogy éppen ahhoz a fájlhoz van a probléma, amelyben a szerializált objektum egyidejűleg különböző szálakból került tárolásra. És éppen akkor, amikor ez megtörtént, csodák történtek a tárgyak eltűnésével. A fájl egyszerűen üres lett. De mindezt nem azonnal fedezték fel, hanem csak több szerverrel való működés közben. Ez idő alatt bekerült a portszkennelés funkció (a szerverek nem csak az eszközök elérhetőségéről, hanem a rajtuk nyitott portokról is információt küldenek a központinak). Ez a parancs meghívásával történt:
$connection = @fsockopen($ip, $port, $errno, $errstr, 0.5);
az eredmények gyakran helytelenek voltak, és a szkennelések hosszú ideig tartottak. Teljesen megfeledkeztem a pingről, fping-en keresztül történt:
system("fping -r 3 -t 100 {$this->ip}");
Ez szintén nem párhuzamos, ezért a folyamat nagyon hosszú volt. Később az ellenőrzéshez szükséges IP-címek teljes listáját egyben elküldtük az fping-nek, visszafelé pedig kész listát kaptunk a válaszolókról. Velünk ellentétben az fping képes volt párhuzamosítani a folyamatokat.
Egy másik gyakori rutinfeladat néhány szolgáltatás WEB-en keresztüli beállítása volt. Nos, például az MS Exchange ECP-je. Alapvetően ez csak egy link. És úgy döntöttünk, hogy az ilyen hivatkozásokat közvetlenül a rendszerhez kell adnunk, hogy ne kelljen a dokumentációban vagy valahol máshol a könyvjelzők között keresgélnünk, hogyan lehet elérni egy adott kliens ECP-jét. Így jelent meg a rendszer erőforráshivatkozásainak koncepciója, funkcionalitásuk a mai napig elérhető és nem változott, nos, szinte.
Hogyan működnek az erőforrás-hivatkozások a Veliamban
Távoli kapcsolatok
Így néz ki működés közben a Veliam jelenlegi verziójában
Az egyik feladat a szerverekhez való gyors és kényelmes csatlakozás volt, amelyekből már sok volt (több mint száz), és a milliónyi előre elmentett RDP parancsikon válogatása rendkívül kényelmetlen volt. Szükség volt egy eszközre. Léteznek az interneten olyan szoftverek, mint egy címjegyzék az ilyen RDP-kapcsolatokhoz, de nincsenek integrálva a felügyeleti rendszerrel, és a fiókokat nem lehet menteni. A különböző ügyfelek fiókjainak minden alkalommal történő megadása pokol, ha naponta több tucatszor csatlakozik különböző szerverekhez. Az SSH-val a dolgok egy kicsit jobbak; sok jó szoftver létezik, amely lehetővé teszi az ilyen kapcsolatok mappákba rendezését és a fiókok emlékezetét. De van 2 probléma. Az első az, hogy egyetlen programot sem találtunk az RDP és SSH kapcsolatokhoz. A második az, hogy ha egy ponton nem vagyok a számítógépemnél, és gyorsan csatlakoznom kell, vagy csak újratelepítettem a rendszert, akkor be kell mennem a dokumentációba, hogy megtekintsem az ügyfél fiókját. Ez kényelmetlen és időpocsékolás.
A kliensszerverekhez szükséges hierarchikus struktúra már elérhető volt a belső termékünkben. Már csak arra kellett rájönnöm, hogyan lehet ott gyorscsatlakozókat rögzíteni a szükséges felszerelésekhez. Kezdetnek legalább a hálózaton belül.
Figyelembe véve, hogy a rendszerünkben a kliens egy böngésző volt, amely nem fér hozzá a számítógép helyi erőforrásaihoz, hogy egyszerűen elindítsuk a szükséges alkalmazást valamilyen paranccsal, azt találták ki, hogy mindent a „Windows egyéni URL-séma”. Így jelent meg a rendszerünkhöz egy bizonyos „bővítmény”, amely egyszerűen a Putty-t és a Remote Desktop Plus-t tartalmazza, és a telepítés során egyszerűen regisztrálta az URI-sémát a Windowsban. Most, amikor RDP-n vagy SSH-n keresztül akartunk csatlakozni egy objektumhoz, erre a műveletre kattintottunk a rendszerünkön, és az egyéni URI működött. Elindult a Windowsba vagy puttyba épített szabvány mstsc.exe, amely a „plugin” része volt. A plugin szót idézőjelbe tettem, mert ez nem a klasszikus értelemben vett böngészőbővítmény.
Ez legalább volt valami. Kényelmes címjegyzék. Sőt, a Putty esetében általában minden rendben volt, bemeneti paraméterként lehetett IP kapcsolatokat, bejelentkezést és jelszót adni. Azok. Már csatlakoztunk hálózatunk Linux szervereihez egyetlen kattintással, jelszavak megadása nélkül. De az RDP-vel ez nem ilyen egyszerű. A szabványos mstsc nem tud hitelesítő adatokat megadni paraméterként. A Remote Desktop Plus segített. Megengedte, hogy ez megtörténjen. Ma már nélkülözhetjük, de sokáig hűséges segédje volt rendszerünknek. A HTTP(S) oldalakkal minden egyszerű, az ilyen objektumok egyszerűen megnyílnak a böngészőben, és kész. Kényelmes és praktikus. De ez csak a belső hálózaton volt boldogság.
Mivel a problémák túlnyomó részét távolról, az irodából oldottuk meg, a legegyszerűbb az volt, hogy a VPN-eket elérhetővé tesszük az ügyfelek számára. És akkor a rendszerünkből lehetett csatlakozni hozzájuk. De ez így is kissé kényelmetlen volt. Minden kliensnél meg kellett tartani egy csomó megjegyzett VPN-kapcsolatot minden számítógépen, és mielőtt bármelyikhez csatlakozna, engedélyezni kellett a megfelelő VPN-t. Elég sokáig használtuk ezt a megoldást. De a kliensek száma növekszik, a VPN-ek száma is nő, és mindez elkezdett feszülni, és tenni kellett valamit. Főleg a rendszer újratelepítése után szöktek könnyek a szemembe, amikor több tucat VPN-kapcsolatot kellett újra megadnom egy új Windows-profilban. Ne tűrd ezt, mondtam, és elkezdtem gondolkodni, mit tehetnék ez ellen.
Történt, hogy minden ügyfélnek a jól ismert Mikrotik cég eszközei voltak routerek. Nagyon funkcionálisak és kényelmesek szinte bármilyen feladat elvégzésére. Hátránya, hogy „eltérítettek”. Ezt a problémát egyszerűen úgy oldottuk meg, hogy minden hozzáférést kívülről lezártunk. De valahogy hozzá kellett férni anélkül, hogy az ügyfélhez jött volna, mert... ez hosszú. Egyszerűen alagutakat készítettünk minden ilyen Mikrotik számára, és külön medencévé választottuk őket. mindenféle útválasztás nélkül, hogy ne legyen kapcsolata hálózatának a kliensek hálózataival és hálózataik egymással.
Megszületett az ötlet, hogy amikor rákattintok a rendszerben arra az objektumra, amelyre szükségem van, a központi felügyeleti szerver az összes Mikrotik kliens SSH-fiókját ismerve csatlakozzon a kívánthoz, és létrehozzon egy továbbítási szabályt a kívánt gazdagépre a szükséges port. Itt több pont is van. A megoldás nem univerzális - csak a Mikrotik esetében fog működni, mivel a parancs szintaxisa minden útválasztónál eltérő. Ezenkívül az ilyen továbbításokat valahogy törölni kellett, és a rendszerünk szerver része lényegében semmilyen módon nem tudta követni, hogy befejeztem-e az RDP-munkamenetet. Nos, az ilyen továbbítás egy lyuk az ügyfél számára. De nem az egyetemességre törekedtünk, mert... a terméket csak cégünkön belül használták, és nem is merült fel a nyilvánosság előtt való megjelenés.
Mindegyik probléma a maga módján megoldódott. A szabály létrehozásakor ez a továbbítás csak egy adott külső IP-címhez volt elérhető (ahonnan a kapcsolat inicializálva lett). Így elkerülték a biztonsági rést. De minden ilyen kapcsolatnál egy Mikrotik-szabály került a NAT-oldalra, és nem törlődött. És mindenki tudja, hogy minél több szabály van, annál jobban le van töltve a router processzora. És általában nem tudtam elfogadni, hogy egyszer majd elmegyek valami Mikrotikba, és ott több száz halott, haszontalan szabály lesz.
Mivel szerverünk nem tudja nyomon követni a kapcsolat állapotát, hagyja, hogy a Mikrotik maga kövesse őket. És írtam egy szkriptet, ami folyamatosan figyelt minden továbbítási szabályt egy adott leírással, és ellenőrizte, hogy a TCP kapcsolatnak van-e megfelelő szabálya. Ha egy ideje nem volt, akkor a kapcsolat valószínűleg már befejeződött, és ez az továbbítás törölhető. Minden rendben volt, a forgatókönyv is jól sikerült.
Egyébként itt van:
global atmonrulecounter {"dontDelete"="dontDelete"}
:foreach i in=[/ip firewall nat find comment~"atmon_script_main"] do={
local dstport [/ip firewall nat get value-name="dst-port" $i]
local dstaddress [/ip firewall nat get value-name="dst-address" $i]
local dstaddrport "$dstaddress:$dstport"
#log warning message=$dstaddrport
local thereIsCon [/ip firewall connection find dst-address~"$dstaddrport"]
if ($thereIsCon = "") do={
set ($atmonrulecounter->$dstport) ($atmonrulecounter->$dstport + 1)
#:log warning message=($atmonrulecounter->$dstport)
if (($atmonrulecounter->$dstport) > 5) do={
#log warning message="Removing nat rules added automaticaly by atmon_script"
/ip firewall nat remove [/ip firewall nat find comment~"atmon_script_main_$dstport"]
/ip firewall nat remove [/ip firewall nat find comment~"atmon_script_sub_$dstport"]
set ($atmonrulecounter->$dstport) 0
}
} else {
set ($atmonrulecounter->$dstport) 0
}
}
Biztosan lehetett volna szebbet, gyorsabbat stb., de működött, nem terhelte a Mikrotik-ot és kiváló munkát végzett. Végre egyetlen kattintással kapcsolódhattunk az ügyfelek szervereihez és hálózati berendezéseihez. VPN megnyitása vagy jelszavak megadása nélkül. A rendszerrel igazán kényelmes lett a munka. A szolgáltatási idő csökkent, és mindannyian munkával töltöttük az időt, nem pedig a szükséges objektumokhoz való csatlakozással.
Mikrotik biztonsági mentés
Az összes Mikrotik biztonsági mentését FTP-re konfiguráltuk. És összességében minden rendben volt. De amikor biztonsági másolatot kellett készítenie, meg kellett nyitnia ezt az FTP-t, és ott meg kellett keresnie. Van egy rendszerünk, ahol az összes router össze van kötve, SSH-n keresztül tudunk kommunikálni az eszközökkel. Miért nem csináljuk úgy, hogy maga a rendszer naponta készít biztonsági másolatot az összes Mikrotikról, gondoltam. És elkezdte megvalósítani. Csatlakoztunk, biztonsági másolatot készítettünk és elvittük a tárolóba.
Script kód PHP-ben a Mikrotikból való biztonsági másolat készítéséhez:
<?php
$IP = '0.0.0.0';
$LOGIN = 'admin';
$PASSWORD = '';
$BACKUP_NAME = 'test';
$connection = ssh2_connect($IP, 22);
if (!ssh2_auth_password($connection, $LOGIN, $PASSWORD)) exit;
ssh2_exec($connection, '/system backup save name="atmon" password="atmon"');
stream_get_contents($connection);
ssh2_exec($connection, '/export file="atmon.rsc"');
stream_get_contents($connection);
sleep(40); // Waiting bakup makes
$sftp = ssh2_sftp($connection);
// Download backup file
$size = filesize("ssh2.sftp://$sftp/atmon.backup");
$stream = fopen("ssh2.sftp://$sftp/atmon.backup", 'r');
$contents = '';
$read = 0;
$len = $size;
while ($read < $len && ($buf = fread($stream, $len - $read))) {
$read += strlen($buf);
$contents .= $buf;
}
file_put_contents ($BACKUP_NAME . ‘.backup’,$contents);
@fclose($stream);
sleep(3);
// Download RSC file
$size = filesize("ssh2.sftp://$sftp/atmon.rsc");
$stream = fopen("ssh2.sftp://$sftp/atmon.rsc", 'r');
$contents = '';
$read = 0;
$len = $size;
while ($read < $len && ($buf = fread($stream, $len - $read))) {
$read += strlen($buf);
$contents .= $buf;
}
file_put_contents ($BACKUP_NAME . ‘.rsc’,$contents);
@fclose($stream);
ssh2_exec($connection, '/file remove atmon.backup');
ssh2_exec($connection, '/file remove atmon.rsc');
?>
A biztonsági mentés két formában készül - bináris és szöveges konfigurációban. A bináris segít gyorsan visszaállítani a szükséges konfigurációt, a szöveges pedig lehetővé teszi, hogy megértse, mit kell tenni, ha kényszerű berendezéscserére kerül sor, és a bináris nem tölthető fel rá. Ennek eredményeként egy másik kényelmes funkciót kaptunk a rendszerben. Ráadásul az új Mikrotik hozzáadásakor nem kellett semmit konfigurálni, egyszerűen hozzáadtam az objektumot a rendszerhez, és SSH-n keresztül beállítottam neki egy fiókot. Ezután maga a rendszer gondoskodott a biztonsági mentésekről. A SaaS Veliam jelenlegi verziója még nem rendelkezik ezzel a funkcióval, de hamarosan portolni fogjuk.
Képernyőképek arról, hogyan nézett ki a belső rendszerben
Áttérés normál adatbázis-tárolásra
Fentebb már írtam, hogy megjelentek a műtárgyak. Előfordult, hogy a rendszerben lévő objektumok teljes listája egyszerűen eltűnt, néha egy objektum szerkesztésekor az információ nem került mentésre, és az objektumot háromszor át kellett nevezni. Ez mindenkit rettenetesen felbosszantott. Az objektumok eltűnése ritkán fordult elő, és ennek a fájlnak a visszaállításával könnyen visszaállítható, de az objektumok szerkesztése során gyakran előfordultak hibák. Valószínűleg kezdetben nem az adatbázison keresztül tettem ezt, mert nem fért bele a fejembe, hogyan lehet egy fát az összes kapcsolattal egy lapos táblában tartani. Lapos, de a fa hierarchikus. De jó megoldás a többszörös hozzáféréshez, és ezt követően (a rendszer bonyolultabbá válásával) a tranzakciókhoz egy DBMS. Valószínűleg nem én vagyok az első, aki szembesül ezzel a problémával. Elkezdtem guglizni. Kiderült, hogy mindent már előttem feltaláltak, és több olyan algoritmus is létezik, ami egy lapos asztalból fát épít. Miután mindegyiket megnéztem, egyet megvalósítottam. De ez már a rendszer új verziója volt, mert... Sőt, emiatt elég sokat kellett átírnom. Az eredmény természetes volt, a rendszer véletlenszerű viselkedésének problémái megszűntek. Egyesek azt mondhatják, hogy a hibák nagyon amatőr jellegűek (egyszálú szkriptek, különböző szálakból egyidejűleg többször elért információk tárolása egy fájlban stb.) a szoftverfejlesztés területén. Lehet, hogy ez igaz, de a fő munkám az adminisztráció volt, a programozás pedig mellékes volt a lelkemnek, és egyszerűen nem volt tapasztalatom olyan programozói csapatban, ahol az ilyen alapvető dolgokat azonnal javasolta volna a felsősöm. bajtársak. Ezért ezeket a dudorokat egyedül töltöttem be, de az anyagot nagyon jól megtanultam. A munkámhoz tartozik még az ügyfelekkel való találkozás, a cég népszerűsítését célzó akciók, a cégen belüli adminisztratív problémák és még sok minden más. De így vagy úgy, amire már volt, arra volt kereslet. A srácok és én magam is használtuk a terméket a mindennapi munkánk során. Őszintén szólva voltak sikertelen ötletek és megoldások, amelyekre elvesztegették az időt, de végül kiderült, hogy ez nem egy működő eszköz, és senki sem használta, és nem Veliamba került.
Helpdesk - HelpDesk
Nem lenne helytelen megemlíteni, hogyan alakult a HelpDesk. Ez egy teljesen más történet, mert... Veliamban ez már a 3. teljesen új verzió, ami eltér az összes korábbitól. Mostantól ez egy egyszerű rendszer, intuitív, szükségtelen csengések és sípok nélkül, képes integrálni egy domainnel, valamint bárhonnan elérheti ugyanazt a felhasználói profilt egy e-mailben található hivatkozás segítségével. És ami a legfontosabb: VPN vagy port továbbítás nélkül, bárhonnan (otthon vagy az irodában) közvetlenül az alkalmazásból lehet csatlakozni a kérelmezőhöz VNC-n keresztül. Elmondom, hogyan jutottunk el idáig, mi történt korábban, és milyen szörnyű döntéseket hoztak.
A jól ismert TeamVieweren keresztül kapcsolódtunk a felhasználókhoz. Minden számítógépen, amelynek felhasználóit kiszolgáljuk, TV van telepítve. Az első dolog, amit rosszul csináltunk, és ezt követően eltávolítottuk, az volt, hogy minden HD klienst összekapcsoltunk a hardverrel. Hogyan jelentkezett be a felhasználó a HD rendszerbe, hogy kérést hagyjon? A tévén kívül mindenkinek egy speciális segédprogram volt telepítve a számítógépére, Lazarus nyelven írva (itt sokan lesütik a szemüket, és talán még a Google-ba is rákeresnek, hogy mi az, de a legjobb fordítási nyelv, amit ismertem, a Delphi volt, a Lazarus pedig kb. ugyanaz, csak ingyenes). Általában a felhasználó elindított egy speciális kötegfájlt, amely elindította ezt a segédprogramot, amely viszont beolvassa a rendszer HWID-jét, majd ezt követően elindult a böngésző, és megtörtént az engedélyezés. Miért tették ezt? Egyes cégeknél a kiszolgált felhasználók számát egyedileg számolják, a szolgáltatási ár minden hónapra a létszám alapján történik. Ez érthető, mondod, de miért kötődik hardverhez? Nagyon leegyszerűsítve, néhány személy hazajött, és az otthoni laptopjáról olyan kérést nyújtott be, hogy „tegyetek széppé itt nekem mindent”. A rendszer HWID beolvasása mellett a segédprogram kihúzta az aktuális Teamviewer azonosítót a registry-ből, és továbbította nekünk is. A Teamviewer API-val rendelkezik az integrációhoz. És megcsináltuk ezt az integrációt. De volt egy fogás. Ezeken az API-kon keresztül lehetetlen csatlakozni a felhasználó számítógépéhez, ha nem kezdeményezi kifejezetten ezt a munkamenetet, és miután megpróbált csatlakozni hozzá, rá kell kattintania a „megerősítés” gombra. Akkor logikusnak tűnt számunkra, hogy a felhasználó kérése nélkül senki ne csatlakozzon, és mivel az illető a számítógépnél van, ő kezdeményezi a munkamenetet, és igennel válaszol a távoli kapcsolódási kérésre. Minden rosszra fordult. A pályázók elfelejtették megnyomni az ülés kezdeményezését, és ezt egy telefonbeszélgetésben kellett nekik elmondani. Ez időt vesztegetett, és a folyamat mindkét oldaláról frusztráló volt. Sőt, egyáltalán nem ritka az ilyen pillanat, amikor az ember elhagy egy kérést, de csak akkor csatlakozhat, amikor elmegy ebédelni. Mert a probléma nem kritikus, és nem akarja, hogy a munkafolyamat megszakadjon. Ennek megfelelően nem fog megnyomni egyetlen gombot sem a csatlakozás engedélyezéséhez. Így jelentek meg további funkciók a HelpDeskbe való bejelentkezéskor - Teamviwer azonosítójának olvasása. Ismertük a Teamviwer telepítésekor használt állandó jelszót. Pontosabban csak a rendszer tudta, hiszen a telepítőbe és a mi rendszerünkbe is beépült. Ennek megfelelően volt egy kapcsolódási gomb az alkalmazásból, amire kattintva nem kellett semmit sem várni, hanem azonnal megnyílt a Teamviewer és létrejött a kapcsolat. Ennek eredményeként kétféle lehetséges kapcsolat volt. A hivatalos Teamviewer API-n és a saját készítésű API-n keresztül. Meglepetésemre szinte azonnal abbahagyták az első használatát, bár volt egy utasítás, hogy csak speciális esetekben és akkor, amikor a felhasználó maga adja az utat, használjuk. Mégis, most adj biztonságot. De kiderült, hogy a jelentkezőknek erre nincs szükségük. Mindegyik teljesen rendben van, ha megerősítő gomb nélkül csatlakozik hozzájuk.
Váltás többszálú megoldásra Linuxban
Már régóta felmerül a kérdés, hogy fel kell gyorsítani a hálózati szkenner áthaladását egy előre meghatározott portlista megnyitása és a hálózati objektumok egyszerű pingelése érdekében. Itt természetesen elsőként a többszálú megoldás jut eszünkbe. Mivel a ping fő ideje a csomag visszaküldésére vár, és a következő ping nem kezdődhet el addig, amíg az előző csomag vissza nem érkezik, így azoknál a cégeknél, ahol még 20+ szerver és hálózati berendezés is volt, ez már elég lassan működött. A lényeg az, hogy egy csomag eltűnhet, de erről ne azonnal értesítse a rendszergazdát. Egyszerűen nagyon gyorsan abbahagyja az ilyen spam elfogadását. Ez azt jelenti, hogy minden objektumot többször meg kell pingelnie, mielőtt következtetést vonhatna le a hozzáférhetetlenségről. Anélkül, hogy túlságosan részleteznénk, párhuzamba kell állítani, mert ha ez nem történik meg, akkor nagy valószínűséggel a rendszergazda a klienstől fog értesülni a problémáról, nem pedig a felügyeleti rendszertől.
Maga a PHP nem támogatja a többszálú kivezetést. Képes több feldolgozásra, villát lehet. Valójában azonban már megírtam egy lekérdezési mechanizmust, és úgy akartam csinálni, hogy egyszer megszámolom az összes szükséges csomópontot az adatbázisból, mindent egyszerre pingelek, megvárom mindegyiktől a választ, és csak ezután írok azonnal. az adat. Ez megtakarítja az olvasási kérelmek számát. A többszálas megoldás tökéletesen illeszkedik ebbe az ötletbe. A PHP-hez van egy PThreads modul, amely lehetővé teszi a valódi többszálú feldolgozást, bár elég sok trükközésbe telt, hogy ezt PHP 7.2-re beállítsák, de sikerült. A portkeresés és a ping most már gyors. És ahelyett, hogy például körönként 15 másodperc volt korábban, ez a folyamat 2 másodpercig tartott. Jó eredmény volt.
Új cégek gyors auditálása
Hogyan jött létre a különféle mutatók és hardverjellemzők összegyűjtésére szolgáló funkcionalitás? Ez egyszerű. Néha egyszerűen csak a jelenlegi informatikai infrastruktúra auditálására kapunk megbízást. Nos, ugyanez szükséges egy új ügyfél auditálásának felgyorsításához. Szükségünk volt valamire, ami lehetővé teszi, hogy eljöjjünk egy közepes vagy nagy céghez, és gyorsan rájöjjünk, mi van. A belső hálózaton a pinget szerintem csak azok blokkolják, akik saját életüket akarják bonyolítani, és tapasztalataink szerint kevesen vannak. De vannak ilyen emberek is. Ennek megfelelően egy egyszerű ping segítségével gyorsan megkeresheti a hálózatokat az eszközök jelenlétére. Ezután hozzáadhatjuk őket, és megkereshetjük a minket érdeklő nyitott portokat. Valójában ez a funkció már létezett, csak egy parancsot kellett hozzáadni a központi szerverről a slave szerverhez, hogy az átvizsgálja a megadott hálózatokat, és mindent hozzáadjon a listához, amit talált. Elfelejtettem megemlíteni, azt feltételezték, hogy már van egy kész képünk egy konfigurált rendszerrel (slave monitoring szerver), amit egy audit során egyszerűen ki tudtunk görgetni a kliensből és csatlakoztatni a felhőnkhoz.
De az audit eredménye általában egy csomó különböző információt tartalmaz, és ezek egyike az, hogy milyen eszközök vannak a hálózaton. Mindenekelőtt a Windows szerverek és Windows munkaállomások érdekeltek minket egy tartomány részeként. Mivel a közép- és nagyvállalatoknál a domain hiánya valószínűleg kivétel a szabály alól. Egy nyelvet beszélni, véleményem szerint az átlag 100+ ember. Ki kellett találni egy olyan módszert, amellyel az összes Windows-gépről és szerverről gyűjthetünk adatokat, az IP- és tartományadminisztrátori fiókjuk ismeretében, de anélkül, hogy mindegyikre szoftvert telepítenénk. A WMI interfész segít. A Windows Management Instrumentation (WMI) szó szerint azt jelenti, hogy Windows felügyeleti eszközök. A WMI a Windows platformot futtató számítógépes infrastruktúra különböző részei működésének központosított kezelésének és felügyeletének egyik alaptechnológiája. Wikiből vettük. Ezután újra kellett trükköznöm, hogy lefordítsam a wmic-et (ez egy WMI kliens) Debianra. Miután minden készen állt, nem maradt más hátra, mint egyszerűen lekérdezni a szükséges csomópontokat a wmic-en keresztül a szükséges információkért. A WMI-n keresztül szinte bármilyen információt megkaphatunk egy Windows-os számítógépről, sőt, ezen keresztül is irányíthatjuk a gépet, például elküldhetjük újraindításra. Így jelent meg rendszerünkben a Windows állomásokról és szerverekről szóló információgyűjtés. Ezen kívül aktuális információk voltak az aktuális rendszerterhelési jelzőkről. Gyakrabban kérünk, hardverre vonatkozó információkat pedig ritkábban. Ezt követően kicsit élvezetesebbé vált az auditálás.
Szoftverterjesztési döntés
Mi magunk is nap mint nap használjuk a rendszert, amely mindig nyitva áll minden műszaki munkatárs számára. És arra gondoltunk, hogy megoszthatjuk másokkal azt, amink van. A rendszer még nem állt készen a terjesztésre. Sokat kellett átdolgozni, hogy a helyi verzióból SaaS legyen. Ezek közé tartozik a rendszer különféle technikai vonatkozásaiban bekövetkezett változások (távkapcsolatok, támogatási szolgáltatás), a licenceléshez szükséges modulok elemzése, az ügyféladatbázisok felosztása, az egyes szolgáltatások méretezése, valamint az összes részhez tartozó automatikus frissítési rendszerek fejlesztése. De ez lesz a cikk második része.
Frissítések
Forrás: will.com