Ahoj všichni, jmenuji se Sergey Emelyanchik. Jsem šéfem společnosti Audit-Telecom, hlavním vývojářem a autorem systému Veliam. Rozhodl jsem se napsat článek o tom, jak jsme s kamarádem vytvořili outsourcingovou společnost, napsali software pro sebe a následně jej začali distribuovat všem prostřednictvím systému SaaS. O tom, jak jsem kategoricky nevěřil, že je to možné. Článek bude obsahovat nejen příběh, ale i technické detaily, jak produkt Veliam vznikal. Včetně některých částí zdrojového kódu. Později vám řeknu, jaké chyby jsme udělali a jak jsme je napravili. Panovaly pochybnosti, zda takový článek publikovat. Ale říkal jsem si, že je lepší to udělat, získat zpětnou vazbu a zlepšit se, než článek nezveřejnit a přemýšlet o tom, co by se stalo, kdyby...
pravěk
Pracoval jsem v jedné firmě jako IT zaměstnanec. Společnost byla poměrně velká s rozsáhlou strukturou sítě. Nebudu se zdržovat svými pracovními povinnostmi, jen řeknu, že rozhodně nezahrnovaly rozvoj čehokoli.
Měli jsme monitoring, ale čistě z akademického zájmu jsem chtěl zkusit napsat svůj vlastní nejjednodušší. Myšlenka byla tato: Chtěl jsem, aby to bylo na webu, abych mohl snadno vstoupit bez instalace jakýchkoli klientů a vidět, co se děje se sítí z jakéhokoli zařízení, včetně mobilního zařízení přes Wi-Fi, a také opravdu chtěl jsem rychle pochopit, co V místnosti je zařízení, které se stalo „mopey“, protože... existovaly velmi přísné požadavky na dobu odezvy na takové problémy. V důsledku toho se v mé hlavě zrodil plán napsat jednoduchou webovou stránku, na které by bylo pozadí ve formátu jpeg se síťovým diagramem, vystřihnout na tomto obrázku samotná zařízení s jejich IP adresami a na horní straně zobrazit dynamický obsah. obrázek v požadovaných souřadnicích ve formě zelené nebo blikající červené IP adresy. Úkol byl nastaven, můžeme začít.
Dříve jsem programoval v Delphi, PHP, JS a velmi povrchně C++. Moc dobře vím, jak sítě fungují. VLAN, Směrování (OSPF, EIGRP, BGP), NAT. To mi stačilo k tomu, abych sám napsal prototyp primitivního monitorování.
Napsal jsem v PHP, co jsem měl na mysli. Server Apache a PHP byly zapnuté. Windows protože Linux pro mě to v tu chvíli bylo něco nepochopitelného a velmi obtížného, jak se později ukázalo, velmi jsem se mýlil a na mnoha místech Linux mnohem jednodušší Windows, ale to je samostatné téma a všichni víme, kolik svatých válek se na toto téma vede. Plánovač úloh Windows Spouštěl jsem PHP skript v krátkých intervalech (nepamatuji si přesně, ale něco jako jednou za tři sekundy), který jednoduchým pingem dotazoval všechny objekty a ukládal stav do souboru.
system(“ping -n 3 -w 100 {$ip_address}“);
Ano, ano, práce s databází v tu chvíli pro mě také nebyla zvládnutá. Nevěděl jsem, že je možné paralelizovat procesy a procházení všech síťových uzlů trvalo dlouho, protože... stalo se to v jednom vláknu. Problémy nastaly zejména tehdy, když několik uzlů bylo nedostupných, protože každý z nich zdržel skript o 300 ms. Na straně klienta byla jednoduchá funkce smyčkování, která v intervalech několika sekund stahovala aktualizované informace ze serveru pomocí požadavku Ajax a aktualizovala rozhraní. No a pak, po 3 neúspěšných pingech za sebou, pokud byla na počítači otevřena webová stránka s monitoringem, zahrála veselá skladba.
Když se vše povedlo, výsledek mě velmi inspiroval a napadlo mě, že bych k němu mohl přidat další (vzhledem k mým znalostem a možnostem). Ale vždycky jsem neměl rád systémy s milionem grafů, o kterých jsem si tehdy a dodnes myslím, že jsou ve většině případů zbytečné. Chtěl jsem tam dát jen to, co by mi opravdu pomohlo v mé práci. Tento princip zůstává základním pro vývoj společnosti Veliam dodnes. Dále jsem si uvědomil, že by bylo velmi cool, kdybych nemusel mít monitorování otevřené a věděl o problémech, a když se to stane, pak otevřete stránku a uvidíte, kde se tento problematický síťový uzel nachází a co s ním dál dělat . Nějak jsem tenkrát nečetl e-maily, prostě jsem to nepoužíval. Na internetu jsem narazil na to, že existují SMS brány, na které lze poslat požadavek GET nebo POST a ony mi na mobil pošlou SMS s textem, který napíšu. Okamžitě jsem si uvědomil, že tohle opravdu chci. A začal jsem studovat dokumentaci. Po nějaké době se mi to podařilo a nyní mi na mobil přišla SMS o problémech v síti s názvem „spadlý předmět“. Přestože byl systém primitivní, napsal jsem ho sám a to nejdůležitější, co mě motivovalo k jeho vývoji, bylo, že to byl aplikační program, který mi v mé práci opravdu pomohl.
A pak přišel den, kdy jeden z internetových kanálů vypadl v práci a můj monitoring mi o tom nedal vědět. Protože Google DNS stále pingoval perfektně. Je čas přemýšlet o tom, jak můžete sledovat, zda je komunikační kanál naživu. Byly různé nápady, jak to udělat. Neměl jsem přístup ke všemu vybavení. Museli jsme přijít na to, jak porozumět tomu, který z kanálů je živý, ale aniž bychom to mohli nějak zobrazit na samotném síťovém zařízení. Pak kolega přišel s myšlenkou, že je možné, že se trasování trasy na veřejné servery může lišit v závislosti na tom, který komunikační kanál je aktuálně používán pro přístup k internetu. Kontroloval jsem a dopadlo to tak. Při trasování byly různé cesty.
system(“tracert -d -w 500 8.8.8.8”);
Objevil se tedy další skript, nebo spíše z nějakého důvodu bylo trasování přidáno na konec stejného skriptu, který pingl na všechna zařízení v síti. Přeci jen se jedná o další dlouhý proces, který byl proveden ve stejném vlákně a zpomalil práci celého skriptu. Ale pak to nebylo tak zřejmé. Ale tak či onak udělal svou práci, kód přesně definoval, jaký druh sledování by měl být pro každý z kanálů. Takto začal fungovat systém, který již monitoroval (hlasitě řečeno, protože neexistoval sběr žádných metrik, ale pouze ping) síťová zařízení (routery, switche, wi-fi atd.) a komunikační kanály s vnějším světem . SMS zprávy přicházely pravidelně a schéma vždy jasně ukazovalo, kde je problém.
Dále, v každodenní práci jsem musel dělat cross-crossing. A už mě unavovalo pokaždé chodit na přepínače Cisco, abych zjistil, jaké rozhraní použít. Jak skvělé by bylo kliknout na objekt v monitorování a zobrazit seznam jeho rozhraní s popisy. Ušetřilo by mi to čas. Navíc by v tomto schématu nebylo nutné spouštět Putty nebo SecureCRT pro zadávání účtů a příkazů. Prostě jsem kliknul na monitoring, viděl co bylo potřeba a šel dělat svou práci. Začal jsem hledat způsoby interakce s přepínači. Hned jsem narazil na 2 možnosti: SNMP nebo přihlášení do switche přes SSH, zadání potřebných příkazů a parsování výsledku. SNMP jsem zavrhl kvůli složitosti jeho implementace. Byl jsem netrpělivý, abych dostal výsledek. u SNMP byste se museli dlouze hrabat v MIB a na základě těchto dat generovat data o rozhraních. V CISCO je skvělý tým
show interface statusUkazuje přesně to, co potřebuji pro přejezdy. Proč se zatěžovat SNMP, když chci jen vidět výstup tohoto příkazu, říkal jsem si. Po nějaké době jsem si tuto příležitost uvědomil. Kliknutí na objekt na webové stránce. Byla spuštěna událost, při které klient AJAX kontaktoval server a ten se na oplátku připojil přes SSH k přepínači, který jsem potřeboval (přihlašovací údaje byly napevno zakódovány do kódu, nebylo potřeba je upřesňovat, vytvářet nějaké samostatné nabídky, kde bylo by možné změnit účty z rozhraní , potřeboval jsem výsledek a rychle) Zadal jsem tam výše uvedený příkaz a poslal zpět do prohlížeče. Takže jsem začal vidět informace o rozhraních jedním kliknutím myši. To bylo mimořádně výhodné, zvláště když jste museli tyto informace zobrazit na různých přepínačích najednou.
Sledování kanálů založené na trasování nakonec nebylo nejlepší nápad, protože... někdy se na síti pracovalo a trasování se mohlo změnit a monitorování na mě začalo křičet, že jsou problémy s kanálem. Ale poté, co jsem strávil spoustu času analýzou, jsem si uvědomil, že všechny kanály fungují a moje sledování mě klamalo. V důsledku toho jsem požádal své kolegy, kteří spravovali přepínače tvorby kanálů, aby mi jednoduše poslali syslog, když se změní stav viditelnosti sousedů. V souladu s tím to bylo mnohem jednodušší, rychlejší a přesnější než sledování. Přišla událost, jako je ztráta souseda, a okamžitě vydávám oznámení o výpadku kanálu.
Dále se při kliknutí na objekt objevilo několik dalších příkazů a bylo přidáno SNMP pro shromažďování některých metrik, a to je v podstatě vše. Systém se nikdy dále nevyvíjel. Udělal vše, co jsem potřeboval, byl to dobrý nástroj. Mnoho čtenářů mi asi dá za pravdu, že na internetu je již spousta softwaru, který tyto problémy řeší. Ale ve skutečnosti jsem tehdy takové bezplatné produkty negooglil a opravdu jsem chtěl rozvíjet své programátorské dovednosti a jaký lepší způsob, jak to prosadit, než skutečný problém s aplikací. V tomto okamžiku byla dokončena první verze monitorování a již nebyla upravována.
Vznik společnosti Audit-Telecom
Postupem času jsem začal pracovat na částečný úvazek v jiných společnostech, naštěstí mi to můj pracovní režim umožňoval. Když pracujete v různých společnostech, vaše dovednosti v různých oblastech velmi rychle rostou a vaše obzory se dobře rozvíjejí. Jsou společnosti, ve kterých jste, jak se říká, Švéd, sekáč a trubač. Na jednu stranu je to těžké, na druhou stranu, pokud nejste líní, stanete se generalistou a to vám umožní řešit problémy rychleji a efektivněji, protože víte, jak příbuzný obor funguje.
Můj kamarád Pavel (také IT specialista) se mě neustále snažil povzbuzovat k vlastnímu podnikání. Nápadů s různými variantami toho, co dělali, bylo nespočet. O tom se diskutuje už léta. A nakonec k ničemu nemělo dojít, protože já jsem skeptik a Pavel je snílek. Pokaždé, když navrhl nápad, vždy jsem mu nevěřil a odmítl se zúčastnit. Ale opravdu jsme chtěli otevřít vlastní podnik.
Nakonec se nám podařilo najít variantu, která nám oběma vyhovovala, a dělat to, co umíme. V roce 2016 jsme se rozhodli vytvořit IT společnost, která by pomáhala firmám řešit IT problémy. Jedná se o nasazení IT systémů (1C, terminálový server, mail server atd.), jejich údržbu, klasický HelpDesk pro uživatele a správu sítě.
Upřímně řečeno, v době zakládání společnosti jsem tomu nevěřil na 99,9%. Ale nějak mě Pavel dokázal přimět, abych to zkusil, a při pohledu dopředu se ukázalo, že měl pravdu. Pavel a já jsme vložili 300 000 rublů, zaregistrovali jsme novou LLC „Audit-Telecom“, pronajali si malou kancelář, vyrobili skvělé vizitky, no, obecně, jako pravděpodobně většina nezkušených začínajících obchodníků a začali hledat klienty. Hledání klientů je úplně jiný příběh. Možná napíšeme samostatný článek v rámci firemního blogu, pokud bude mít někdo zájem. Studené hovory, letáky atd. To nepřineslo žádné výsledky. Jak teď čtu z mnoha příběhů o podnikání, tak či onak, hodně záleží na štěstí. Měli jsme štěstí. a doslova pár týdnů po vzniku firmy nás oslovil můj bratr Vladimír, který nám přivedl prvního klienta. Nebudu vás nudit detaily práce s klienty, o tom článek není, jen řeknu, že jsme šli na audit, identifikovali kritické oblasti a tyto oblasti se rozpadly, když se rozhodovalo, zda průběžně s námi spolupracovat jako outsourcers. Poté bylo okamžitě přijato kladné rozhodnutí.
Poté, hlavně ústním podáním přátel, se začaly objevovat další servisní společnosti. Helpdesk byl v jednom systému. Připojení k síťovým zařízením a serverům jsou různá, nebo spíše odlišná. Někteří lidé ukládali zkratky, jiní používali adresáře RDP. Dalším samostatným systémem je monitorování. Pro tým je velmi nepohodlné pracovat v nesourodých systémech. Důležité informace jsou ztraceny ze zřetele. Například terminálový server klienta se stal nedostupným. Přihlášky od uživatelů tohoto klienta jsou okamžitě přijímány. Specialista podpory otevře žádost (byla přijata telefonicky). Pokud by byly incidenty a požadavky registrovány v jednom systému, specialista podpory by okamžitě viděl, jaký je problém uživatele, řekl by mu o tom a současně by se připojil k požadovanému objektu, aby situaci vyřešil. Všichni si uvědomují taktickou situaci a pracují harmonicky. Nenašli jsme systém, kde by se toto vše spojilo. Bylo jasné, že je čas vyrobit vlastní produkt.
Pokračujte v práci na vašem monitorovacím systému
Bylo jasné, že systém, který byl napsán dříve, je pro současné úkoly zcela nevhodný. Ani z hlediska funkčnosti, ani z hlediska kvality. A bylo rozhodnuto napsat systém od nuly. Graficky by to mělo vypadat úplně jinak. Musel to být hierarchický systém, aby bylo možné rychle a pohodlně otevřít správný objekt pro správného klienta. Schéma jako v první verzi nebylo v tomto případě absolutně opodstatněné, protože Klienti jsou různí a vůbec nezáleželo na tom, v jakých prostorách se zařízení nacházelo. To již bylo přeneseno do dokumentace.
Takže úkoly jsou:
- Hierarchická struktura;
- Nějaký druh serverové části, která může být umístěna v prostorách klienta ve formě virtuálního stroje pro sběr potřebných metrik a jejich odeslání na centrální server, který to vše shrne a ukáže nám to;
- Upozornění. Ty, které nesmí chybět, protože... v té době nebylo možné, aby někdo seděl a jen koukal na monitor;
- Systém aplikace. Začali se objevovat klienti, pro které jsme obsluhovali nejen serverová a síťová zařízení, ale i pracovní stanice;
- Schopnost rychlého připojení k serverům a zařízením ze systému;
Úkoly byly stanoveny a my jsme začali psát. Postupně jsme zpracovávali požadavky od klientů. V té době nás už byli čtyři. Začali jsme psát obě části najednou: centrální server a server pro instalaci klientů. V tomto okamžiku, Linux už nám nebylo cizí a bylo rozhodnuto, že virtuální počítače, které budou instalovány u klientů, budou na DebianNebudou k dispozici žádné instalační programy; jednoduše vytvoříme projekt na straně serveru na jednom virtuálním počítači a pak ho jednoduše naklonujeme na požadovaného klienta. To byla další chyba. Později se ukázalo, že toto nastavení nemá absolutně žádný mechanismus aktualizace. Takže bychom přidali nějakou novou funkci a pak by bylo opravdu otravné ji distribuovat na všechny klientské servery. Ale k tomu se dostaneme později, v pravý čas.
Vyrobili jsme první prototyp. Byl schopen pingnout na klientská síťová zařízení a servery, které jsme potřebovali, a odeslat tato data na náš centrální server. A on zase tato data hromadně aktualizoval na centrálním serveru. Napíšu zde nejen příběh o tom, jak a co se povedlo, ale také jaké amatérské chyby se dělaly a jak jsem na to později musel doplatit časem. Celý strom objektů byl tedy uložen v jediném souboru ve formě serializovaného objektu. Zatímco jsme do systému připojili několik klientů, vše bylo víceméně normální, i když se občas vyskytly nějaké artefakty, které byly naprosto nepochopitelné. Ale když jsme k systému připojili tucet serverů, začaly se dít zázraky. Někdy z neznámého důvodu všechny objekty v systému jednoduše zmizely. Zde je důležité poznamenat, že servery, které měli klienti, odesílali data na centrální server každých několik sekund prostřednictvím požadavku POST. Pozorný čtenář a zkušený programátor už tuší, že je problém s vícenásobným přístupem právě k souboru, ve kterém byl serializovaný objekt uložen z různých vláken současně. A právě když se to dělo, staly se zázraky se zmizením předmětů. Soubor se jednoduše vyprázdnil. To vše však nebylo objeveno okamžitě, ale až během provozu s několika servery. Během této doby byla přidána funkcionalita skenování portů (servery posílaly do centrály nejen informace o dostupnosti zařízení, ale také o portech na nich otevřených). To bylo provedeno zavoláním příkazu:
$connection = @fsockopen($ip, $port, $errno, $errstr, 0.5);
výsledky byly často nesprávné a dokončení skenování trvalo dlouho. Úplně jsem zapomněl na ping, dělalo se to přes fping:
system("fping -r 3 -t 100 {$this->ip}");
To také nebylo paralelní, a proto byl proces velmi dlouhý. Později byl celý seznam IP adres potřebných k ověření odeslán na fping najednou a zpět jsme dostali hotový seznam těch, kteří odpověděli. Na rozdíl od nás byl fping schopen paralelizovat procesy.
Další běžnou rutinní prací bylo nastavení některých služeb přes WEB. No třeba ECP od MS Exchange. V podstatě je to jen odkaz. A rozhodli jsme se, že takové odkazy musíme umět přidat přímo do systému, abychom nemuseli hledat v dokumentaci nebo někde jinde v záložkách, jak se dostat k ECP konkrétního klienta. Takto se objevil koncept odkazů na zdroje pro systém, jejich funkčnost je k dispozici dodnes a nezměnila se, no, skoro.
Jak fungují odkazy na zdroje ve Veliamu
Vzdálená připojení
Tak to vypadá v akci v aktuální verzi Veliamu
Jedním z úkolů bylo rychle a pohodlně se připojit k serverům, kterých již bylo mnoho (více než sto) a řazení mezi miliony předem uložených RDP zkratek bylo krajně nepohodlné. Byl potřeba nástroj. Na internetu existuje software, který je něco jako adresář pro taková připojení RDP, ale nejsou integrovány s monitorovacím systémem a účty nelze ukládat. Zadávání účtů pro různé klienty pokaždé je čiré peklo, když se připojujete desítkykrát denně k různým serverům. S SSH je to trochu lepší, existuje spousta dobrého softwaru, který vám umožňuje organizovat taková připojení do složek a pamatovat si z nich účty. Ale jsou tu 2 problémy. První je, že jsme nenašli jediný program pro připojení RDP a SSH. Druhým je, že pokud v určitou chvíli nejsem u počítače a potřebuji se rychle připojit, nebo jsem jen přeinstaloval systém, budu muset jít do dokumentace, abych se podíval na účet od tohoto klienta. Je to nepohodlné a ztráta času.
Hierarchická struktura, kterou jsme potřebovali pro klientské servery, byla již k dispozici v našem interním produktu. Jen jsem musel vymyslet, jak tam připevnit rychlé spoje k potřebnému vybavení. Pro začátek, alespoň v rámci vaší sítě.
Vzhledem k tomu, že klientem v našem systému byl prohlížeč, který neměl přístup k lokálním zdrojům počítače, bylo pro jednoduché spuštění aplikace, kterou jsme potřebovali, nějakým příkazem rozhodnuto vše provést prostřednictvím „Windows vlastní schéma adresy URL.“ Takto se objevil „plugin“ pro náš systém, který jednoduše obsahoval Putty a Remote Desktop Plus a po instalaci jednoduše zaregistroval schéma URI v WindowsKdykoli jsme se chtěli připojit k objektu přes RDP nebo SSH, klikli jsme na tuto akci v našem systému a aktivovalo se vlastní URI. Standardní soubor mstsc.exe zabudovaný do Windows nebo PuTTY, který byl součástí „pluginu“. Slovo „plugin“ jsem dal do uvozovek, protože se nejedná o plugin prohlížeče v klasickém slova smyslu.
To bylo alespoň něco. Pohodlný adresář. A v případě Putty bylo všechno v pořádku; jako vstupní parametry se dala zadat IP adresa připojení, přihlašovací jméno a heslo. Tedy, Linux Už jsme se připojovali k serverům v naší síti jedním kliknutím, bez zadávání hesel. RDP ale není tak jednoduché. Standardnímu mstsc nelze předat přihlašovací údaje jako parametry. Na pomoc přišel Remote Desktop Plus. Umožnil nám to. Od té doby jsme se bez něj obešli, ale dlouho to byl v našem systému spolehlivý pomocník. HTTP(S) weby jsou snadné; takové objekty se jednoduše otevřou v prohlížeči a to je vše. Pohodlné a praktické. Ale pro interní síť to bylo jen požehnání.
Protože jsme drtivou většinu problémů řešili na dálku z kanceláře, nejjednodušší způsob byl nastavit klientům VPN. Pak jsme se k nim mohli připojit z našeho systému. Ale i tak to bylo poněkud nepraktické. Pro každého klienta jsme museli na každém počítači uchovávat spoustu hesel. VPN Připojení a před připojením k jakémukoli musela být povolena odpovídající VPN. Toto řešení jsme používali poměrně dlouho. Počet klientů ale rostl, stejně jako počet VPN, a tohle všechno začínalo být otravné a muselo se s tím něco dělat. Obzvlášť k slzám to bylo po přeinstalování systému, kdy jsem musel znovu zadat desítky VPN připojení do nového profilu Windows. Řekl jsem si: „Už toho mám dost,“ a začal jsem přemýšlet, co se s tím dá dělat.
Stalo se, že všichni klienti měli jako routery zařízení od známé firmy Mikrotik. Jsou velmi funkční a pohodlné pro provádění téměř jakéhokoli úkolu. Nevýhodou je, že jsou „uneseny“. Tento problém jsme vyřešili jednoduše uzavřením všech přístupů zvenčí. Bylo ale nutné se k nim nějak dostat, aniž bychom přišli ke klientovi, protože... je to dlouhé. Pro každý takový Mikrotik jsme jednoduše udělali tunely a oddělili je do samostatného bazénu. bez jakéhokoliv routování, aby nedocházelo k propojení Vaší sítě se sítěmi klientů a jejich sítí mezi sebou.
Zrodil se nápad zajistit, že když kliknu na objekt, který v systému potřebuji, centrální monitorovací server, který zná SSH účty všech klientů Mikrotik, se připojí k požadovanému a vytvoří pravidlo předávání na požadovaný hostitel s požadovaný port. Je zde několik bodů. Řešení není univerzální – bude fungovat pouze pro Mikrotik, jelikož syntaxe příkazů je u všech routerů jiná. Taková přeposílání pak musela být nějak smazána a serverová část našeho systému v podstatě nemohla nijak sledovat, zda jsem dokončil relaci RDP. No a takové přeposílání je pro klienta díra. Ale neusilovali jsme o univerzálnost, protože... výrobek byl používán pouze v rámci naší společnosti a neuvažovalo se o jeho zpřístupnění veřejnosti.
Každý z problémů byl vyřešen po svém. Při vytvoření pravidla bylo toto předávání dostupné pouze pro jednu konkrétní externí IP adresu (ze které bylo inicializováno připojení). Bezpečnostní díra se tak vyhnula. Ale s každým takovým připojením bylo na stránku NAT přidáno pravidlo Mikrotiku a nebylo vymazáno. A každý ví, že čím více pravidel existuje, tím více je zatížen procesor routeru. A vůbec jsem se nemohl smířit s tím, že jednou půjdu na nějaký Mikrotik a budou tam stovky mrtvých zbytečných pravidel.
Protože náš server nemůže sledovat stav připojení, nechte Mikrotik, aby je sledoval sám. A napsal jsem skript, který neustále sledoval všechna pravidla předávání s konkrétním popisem a kontroloval, zda má TCP spojení vhodné pravidlo. Pokud po nějakou dobu žádné nebylo, pak již bylo připojení pravděpodobně dokončeno a toto přeposílání lze smazat. Všechno klaplo, scénář fungoval dobře.
Mimochodem, tady to je:
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
}
}
Určitě to šlo udělat krásnější, rychlejší atd., ale fungovalo to, nenačetlo Mikrotik a odvedlo výbornou práci. Konečně jsme se mohli připojit k serverům a síťovým zařízením klientů jediným kliknutím. Bez otevírání VPN nebo zadávání hesel. Práce se systémem se stala opravdu pohodlnou. Servisní čas se zkrátil a všichni jsme trávili čas spíše prací než připojováním k potřebným objektům.
Záloha Mikrotik
Nastavili jsme zálohování všech Mikrotiků na FTP. A celkově bylo vše v pořádku. Ale když jste potřebovali získat zálohu, museli jste otevřít tento FTP a hledat ho tam. Máme systém, kde jsou připojeny všechny routery, můžeme komunikovat se zařízeními přes SSH. Proč to neuděláme tak, aby si systém sám dělal zálohy ze všech Mikrotiků denně, říkal jsem si. A začal to realizovat. Připojili jsme se, udělali zálohu a vzali to do úložiště.
Kód skriptu v PHP pro vytvoření zálohy z Mikrotiku:
<?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');
?>
Záloha probíhá ve dvou formách – binární a textová konfigurace. Binární soubor pomáhá rychle obnovit požadovanou konfiguraci a textový vám umožňuje pochopit, co je třeba udělat, pokud dojde k nucené výměně zařízení a binární soubor do něj nelze nahrát. V důsledku toho jsme získali další pohodlnou funkci v systému. Navíc při přidávání nového Mikrotiku nebylo potřeba nic konfigurovat, jednoduše jsem objekt přidal do systému a nastavil mu účet přes SSH. O zálohování se pak staral sám systém. Aktuální verze SaaS Veliam zatím tuto funkcionalitu nemá, ale brzy ji přeneseme.
Screenshoty, jak to vypadalo v interním systému
Přechod do normálního databázového úložiště
Už jsem psal výše, že se objevily artefakty. Někdy prostě zmizel celý seznam objektů v systému, někdy se při editaci objektu informace neuložily a objekt se musel třikrát přejmenovat. To všechny strašně dráždilo. Ke zmizení objektů docházelo jen zřídka a bylo možné je snadno obnovit obnovením právě tohoto souboru, ale k selháním při úpravách objektů docházelo poměrně často. Pravděpodobně jsem to zpočátku nedělal prostřednictvím databáze, protože mi nezapadalo, jak je možné udržet strom se všemi spojeními v ploché tabulce. Je plochý, ale strom je hierarchický. Ale dobrým řešením pro vícenásobný přístup a následně (jak se systém stává složitějším) transakční je DBMS. Asi nejsem první, kdo se s tímto problémem setkal. Začal jsem googlovat. Ukázalo se, že všechno už bylo vynalezeno přede mnou a existuje několik algoritmů, které staví strom z plochého stolu. Po zhlédnutí každého z nich jsem jeden z nich implementoval. Ale to už byla nová verze systému, protože... Ve skutečnosti jsem kvůli tomu musel docela hodně přepisovat. Výsledek byl přirozený, problémy náhodného chování systému zmizely. Někdo by mohl říci, že chyby jsou v oblasti vývoje softwaru velmi amatérské (jednovláknové skripty, ukládání informací, ke kterým se přistupovalo vícekrát současně z různých vláken v souboru atd.). Možná je to pravda, ale mým hlavním zaměstnáním byla administrativa a programování byl pro mou duši jen shon a prostě jsem neměl zkušenosti s prací v týmu programátorů, kde by mi takové základní věci okamžitě navrhl můj starší soudruzi. Všechny tyto hrbolky jsem proto vyplnil sám, ale látku jsem se naučil velmi dobře. A také moje práce zahrnuje schůzky s klienty, akce zaměřené na propagaci společnosti, spoustu administrativních záležitostí v rámci společnosti a mnoho, mnoho dalšího. Ale tak či onak, to, co už tam bylo, bylo žádané. Kluci a já jsme produkt používali při každodenní práci. Byly tam upřímně nepovedené nápady a řešení, na kterých se plýtvalo časem, ale nakonec se ukázalo, že to není pracovní nástroj a nikdo ho nepoužíval a neskončil ve Veliamu.
Helpdesk - HelpDesk
Nebylo by od věci zmínit, jak HelpDesk vznikl. Tohle je úplně jiný příběh, protože... ve Veliamu je to již 3. zcela nová verze, která se liší od všech předchozích. Nyní se jedná o jednoduchý systém, intuitivní bez zbytečných zvonků a píšťalek, s možností integrace s doménou a také možností přístupu ke stejnému uživatelskému profilu odkudkoli pomocí odkazu z e-mailu. A hlavně je možné se k žadateli připojit přes VNC odkudkoli (doma nebo v kanceláři) přímo z aplikace bez VPN nebo přesměrování portů. Řeknu vám, jak jsme k tomu přišli, co se stalo předtím a jaká hrozná rozhodnutí byla učiněna.
K uživatelům jsme se připojili přes známý TeamViewer. Všechny počítače, jejichž uživatele obsluhujeme, mají nainstalovanou televizi. První věc, kterou jsme udělali špatně a následně ji odstranili, bylo propojení každého HD klienta s hardwarem. Jak se uživatel přihlásil do systému HD, aby mohl zanechat požadavek? Kromě TV měli všichni na svých počítačích nainstalovanou speciální utilitu napsanou v Lazarus (mnoho lidí tady bude valit oči a možná si i vygooglovat, co to je, ale nejlépe zkompilovaný jazyk, který jsem znal, bylo Delphi a Lazarus je skoro to samé, jen zdarma). Obecně uživatel spustil speciální dávkový soubor, který spustil tento nástroj, který zase načetl HWID systému a poté byl spuštěn prohlížeč a došlo k autorizaci. Proč se to udělalo? V některých společnostech se počet obsluhovaných uživatelů počítá individuálně a cena služby za každý měsíc se odvíjí od počtu osob. To je pochopitelné, říkáte si, ale proč je to vázáno na hardware? Jednoduše řečeno, někteří jedinci přišli domů a ze svého domácího notebooku vznesli požadavek ve stylu „udělej mi tady všechno krásné“. Kromě čtení systémového HWID utilita vytáhla aktuální ID Teamvieweru z registru a také nám je přenesla. Teamviewer má API pro integraci. A tuto integraci jsme provedli. Mělo to ale jeden háček. Prostřednictvím těchto API se nelze připojit k počítači uživatele, pokud tuto relaci výslovně nezahájí a po pokusu o připojení k ní musí také kliknout na „potvrdit“. Tehdy nám přišlo logické, že se nikdo nesmí připojovat bez požadavku uživatele, a jelikož je tento člověk u počítače, zahájí relaci a na požadavek vzdáleného připojení odpoví kladně. Všechno dopadlo špatně. Žadatelé zapomněli stisknout tlačítko iniciovat sezení a museli jim to sdělit v telefonickém rozhovoru. Tato ztráta času a frustrující na obou stranách procesu. Navíc není vůbec neobvyklé, že takové chvíle, kdy člověk zanechá žádost, ale smí se připojit, až když odchází na oběd. Protože problém není kritický a nechce, aby byl jeho pracovní proces přerušen. V souladu s tím nestiskne žádné tlačítko pro povolení připojení. Takto se objevila další funkce při přihlášení do HelpDesku - čtení Teamviwer's ID. Znali jsme trvalé heslo, které bylo použito při instalaci Teamviwer. Přesněji, věděl to pouze systém, protože byl zabudován do instalačního programu a do našeho systému. V souladu s tím zde bylo tlačítko pro připojení z aplikace kliknutím, na které nebylo třeba na nic čekat, ale okamžitě se otevřel Teamviewer a došlo k připojení. V důsledku toho existovaly dva typy možných spojení. Prostřednictvím oficiálního Teamviewer API a našeho vlastního. K mému překvapení ten první přestali téměř okamžitě používat, ačkoliv tam byl pokyn používat ho jen ve speciálních případech a když k tomu dá souhlas sám uživatel. Přesto mi teď dej jistotu. Ukázalo se však, že toto žadatelé nepotřebují. Všechny jsou naprosto v pořádku, když jsou k nim připojeny bez potvrzovacího tlačítka. A jelikož tomu tak je, byla následně funkce API připojení zrušena jako nepotřebná.
Přechod na multithreading v Linux
Otázka zrychlení průchodu síťového skeneru pro otevřenost předem stanoveného seznamu portů a jednoduché pingnutí síťových objektů se začala objevovat již dlouho. Zde samozřejmě první řešení, které mě napadá, je multithreading. Protože hlavní čas strávený pingem je čekání na vrácení paketu a další ping nemůže začít, dokud není vrácen předchozí paket, ve společnostech, které měly dokonce 20+ serverů plus síťové vybavení, to již fungovalo docela pomalu. Jde o to, že jeden balíček může zmizet, ale neinformujte o tom hned správce systému. Takový spam prostě velmi rychle přestane přijímat. To znamená, že musíte každý objekt pingnout více než jednou, než uděláte závěr o nepřístupnosti. Aniž bychom zacházeli do přílišných podrobností, je nutné to paralelizovat, protože pokud se tak nestane, správce systému se s největší pravděpodobností dozví o problému od klienta, nikoli od monitorovacího systému.
PHP samo o sobě nepodporuje multithreading hned po vybalení. Schopný multiprocessing, můžete fork. Ale ve skutečnosti už jsem měl napsaný mechanismus dotazování a chtěl jsem to udělat tak, že jednou spočítám všechny uzly, které potřebuji z databáze, pingnu vše najednou, čekám na odpověď od každého a teprve potom hned píšu data. Tím se ušetří počet požadavků na čtení. Multithreading do této myšlenky dokonale zapadá. Pro PHP existuje modul PThreads, který vám umožňuje provádět skutečný multithreading, i když nastavení tohoto nastavení v PHP 7.2 vyžadovalo značné množství práce, ale podařilo se. Skenování portů a ping jsou nyní rychlé. A místo například o 15 sekund na kolo dříve, tento proces začal trvat 2 sekundy. Byl to dobrý výsledek.
Rychlý audit nových společností
Jak vznikla funkcionalita pro sběr různých metrik a hardwarových charakteristik? Je to jednoduché. Někdy máme jednoduše nařízeno provést audit stávající IT infrastruktury. No a to samé je nutné pro urychlení auditu nového klienta. Potřebovali jsme něco, co by nám umožnilo přijít do střední nebo velké společnosti a rychle zjistit, co mají. Ping na vnitřní síti podle mě blokuje jen ten, kdo si chce zkomplikovat život a těch je podle našich zkušeností málo. Ale jsou i takoví lidé. V souladu s tím můžete rychle vyhledávat sítě na přítomnost zařízení pomocí jednoduchého pingu. Poté je můžeme přidat a vyhledat otevřené porty, které nás zajímají. Ve skutečnosti tato funkce již existovala, bylo pouze nutné přidat příkaz z centrálního serveru na podřízený, aby prohledal zadané sítě a přidal do seznamu vše, co našel. Zapomněl jsem zmínit, předpokládalo se, že již máme hotový image s nakonfigurovaným systémem (slave monitorovací server), který jsme mohli jednoduše vytáhnout z klienta během auditu a připojit jej k našemu cloudu.
Výsledek auditu ale obvykle obsahuje řadu různých informací a jednou z nich je, jaká zařízení jsou v síti. Nás primárně zajímalo Windows servery a pracovní stanice Windows Jako součást domény. Ve středních a velkých firmách je absence domény pravděpodobně spíše výjimkou než pravidlem. Abychom mluvili stejným jazykem, střední firma je podle mého názoru 100+ lidí. Potřebovali jsme přijít se způsobem, jak shromažďovat data ze všech počítačů a serverů s Windows, znát jejich IP adresy a účty správců domény, aniž bychom museli na každý z nich instalovat jakýkoli software. Na pomoc přišlo rozhraní WMI. Windows Management Instrumentation (WMI) doslova znamená instrumentace pro správu. WindowsWMI je jednou ze základních technologií pro centralizovanou správu a monitorování různých částí počítačové infrastruktury pod kontrolou platformy. WindowsPřevzato z wiki. Pak jsem musel znovu experimentovat s vytvořením wmic (WMI klienta) pro DebianJakmile bylo vše připraveno, zbývalo už jen dotazovat se na požadované uzly pomocí WMIC a získat potřebné informace. Prostřednictvím WMI můžete získat Windows počítače téměř jakékoli informace a navíc jej můžete také ovládat, například jej restartovat. Takto probíhá shromažďování informací o Windows stanice a servery v našem systému. Toto bylo doplněno aktuálními informacemi o aktuálních indikátorech zatížení systému. Tyto informace požadujeme častěji, zatímco informace o hardwaru jsou méně časté. Poté se audit stal o něco příjemnějším.
Rozhodnutí o distribuci softwaru
My sami systém používáme každý den a je vždy otevřený pro každého technického pracovníka. A napadlo nás, že bychom se mohli podělit s ostatními o to, co už máme. Systém ještě nebyl připraven k distribuci. Aby se místní verze proměnila v SaaS, muselo se toho hodně přepracovat. Patří mezi ně změny v různých technických aspektech systému (vzdálená připojení, služba podpory), analýza modulů pro licencování, sharding zákaznických databází, škálování každé služby a vývoj systémů automatické aktualizace pro všechny části. Ale to bude až druhá část článku.
Aktualizace
Zdroj: www.habr.com
