Hallo almal, my naam is Sergey Emelyanchik. Ek is die hoof van die Audit-Telecom-maatskappy, die hoofontwikkelaar en skrywer van die Veliam-stelsel. Ek het besluit om 'n artikel te skryf oor hoe ek en my vriend 'n uitkontrakteringsmaatskappy geskep het, sagteware vir onsself geskryf het en dit daarna aan almal via die SaaS-stelsel begin versprei het. Oor hoe ek kategories nie geglo het dat dit moontlik is nie. Die artikel sal nie net 'n storie bevat nie, maar ook tegniese besonderhede van hoe die Veliam-produk geskep is. Insluitend sommige stukke bronkode. Ek sal jou later vertel watter foute ons gemaak het en hoe ons dit reggestel het. Daar was twyfel of so 'n artikel gepubliseer moes word. Maar ek het gedink dit is beter om dit te doen, terugvoer te kry en te verbeter, as om nie die artikel te publiseer en te dink oor wat sou gebeur het as...
voorgeskiedenis
Ek het in een maatskappy gewerk as 'n IT-werknemer. Die maatskappy was redelik groot met 'n uitgebreide netwerkstruktuur. Ek sal nie stilstaan by my werksverantwoordelikhede nie, ek sal net sê dat dit beslis nie die ontwikkeling van enigiets ingesluit het nie.
Ons het monitering gehad, maar suiwer uit akademiese belangstelling wou ek probeer om my eie eenvoudigste een te skryf. Die idee was dit: ek wou hê dit moet op die web wees, sodat ek maklik kon ingaan sonder om enige kliënte te installeer en te sien wat met die netwerk gebeur vanaf enige toestel, insluitend 'n mobiele toestel via Wi-Fi, en ek het ook regtig wou vinnig verstaan wat Daar is toerusting in die kamer wat "mopey" geword het omdat... daar was baie streng vereistes vir reaksietyd op sulke probleme. Gevolglik is 'n plan in my kop gebore om 'n eenvoudige webblad te skryf waarop daar 'n jpeg-agtergrond met 'n netwerkdiagram was, die toestelle self met hul IP-adresse in hierdie prent uit te sny en dinamiese inhoud bo-op die prentjie in die vereiste koördinate in die vorm van 'n groen of flikkerende rooi IP-adres. Die taak is opgestel, kom ons begin.
Voorheen het ek geprogrammeer in Delphi, PHP, JS en baie oppervlakkig C++. Ek weet baie goed hoe netwerke werk. VLAN, Roetering (OSPF, EIGRP, BGP), NAT. Dit was genoeg vir my om self 'n primitiewe moniteringsprototipe te skryf.
Ek het geskryf wat ek beplan het in PHP. Die Apache- en PHP-bediener was op Windows omdat... Linux was vir my op daardie oomblik iets onverstaanbaars en baie kompleks, soos dit later geblyk het, het ek my baie misgis en op baie plekke is Linux baie eenvoudiger as Windows, maar dit is 'n aparte onderwerp en ons weet almal hoeveel holivars daar is op hierdie onderwerp. Die Windows-taakskeduleerder het met 'n klein interval (ek onthou nie presies nie, maar iets soos een keer elke drie sekondes) 'n PHP-skrip getrek wat alle voorwerpe met 'n banale ping gepols het en die toestand in 'n lêer gestoor het.
system(“ping -n 3 -w 100 {$ip_address}“);
Ja, ja, om op daardie oomblik met 'n databasis te werk was ook nie vir my bemeester nie. Ek het nie geweet dat dit moontlik was om prosesse te paralleliseer nie, en om deur al die netwerknodes te gaan het lank geduur, want ... dit het in een draad gebeur. Probleme het veral ontstaan toe verskeie nodusse nie beskikbaar was nie, want elkeen van hulle het die draaiboek vir 300 ms vertraag. Aan die kliëntkant was daar 'n eenvoudige lusfunksie wat met tussenposes van 'n paar sekondes opgedateerde inligting van die bediener afgelaai het met 'n Ajax-versoek en die koppelvlak opgedateer het. Wel, dan, na 3 onsuksesvolle pings in 'n ry, as 'n webblad met monitering op die rekenaar oop was, het 'n vrolike komposisie gespeel.
Toe alles uitgewerk het, was ek baie geïnspireer deur die resultaat en het gedink dat ek meer daarby kan voeg (weens my kennis en vermoëns). Maar ek het altyd nie van stelsels met 'n miljoen kaarte gehou nie, wat ek toe gedink het, en steeds dink tot vandag toe, in die meeste gevalle onnodig is. Ek wou net daar insit wat my regtig in my werk sou help. Hierdie beginsel bly fundamenteel tot die ontwikkeling van Veliam tot vandag toe. Verder het ek besef dat dit baie gaaf sou wees as ek nie hoef te bly moniteer en weet van probleme nie, en wanneer dit gebeur het, maak dan die bladsy oop en kyk waar hierdie problematiese netwerknodus geleë is en wat om volgende daarmee te doen . Op een of ander manier het ek nie destyds e-pos gelees nie, ek het dit eenvoudig nie gebruik nie. Ek het op die internet afgekom daar is SMS-poorte waarheen jy 'n GET- of POST-versoek kan stuur, en hulle sal 'n SMS na my selfoon stuur met die teks wat ek skryf. Ek het dadelik besef dat ek dit regtig wil hê. En ek het die dokumentasie begin bestudeer. Na 'n ruk het ek daarin geslaag, en nou het ek 'n SMS oor probleme op die netwerk op my selfoon ontvang met die naam van 'n "gevalle voorwerp". Alhoewel die stelsel primitief was, is dit self deur my geskryf, en die belangrikste ding wat my gemotiveer het om dit te ontwikkel, was dat dit 'n toepassingsprogram was wat my regtig in my werk gehelp het.
En toe kom die dag toe een van die internetkanale by die werk afgegaan het, en my monitering het my nie daarvan laat weet nie. Aangesien Google DNS steeds perfek geping het. Dit is tyd om te dink oor hoe jy kan monitor dat die kommunikasiekanaal lewendig is. Daar was verskillende idees oor hoe om dit te doen. Ek het nie toegang tot al die toerusting gehad nie. Ons moes uitvind hoe om te verstaan watter van die kanale regstreeks is, maar sonder om dit op een of ander manier op die netwerktoerusting self te kon sien. Toe kom 'n kollega met die idee dat dit moontlik is dat die roetesporing na publieke bedieners kan verskil afhangende van watter kommunikasiekanaal tans gebruik word om toegang tot die internet te verkry. Ek het nagegaan en dit het so uitgedraai. Daar was verskillende roetes tydens die opsporing.
system(“tracert -d -w 500 8.8.8.8”);
So het 'n ander skrif verskyn, of liewer, om een of ander rede is die spoor aan die einde van dieselfde skrif gevoeg, wat alle toestelle op die netwerk geping het. Dit is immers nog 'n lang proses wat in dieselfde draad uitgevoer is en die werk van die hele draaiboek vertraag het. Maar toe was dit nie so duidelik nie. Maar op een of ander manier, hy het sy werk gedoen, die kode het streng voorgeskryf watter soort opsporing vir elk van die kanale moet wees. Dit is hoe die stelsel begin werk het, wat reeds netwerktoestelle (routers, skakelaars, wi-fi, ens.) en kommunikasiekanale met die buitewêreld gemonitor het (hard gesê, want daar was geen versameling van enige maatstawwe nie, maar net ping). . SMS-boodskappe het gereeld opgedaag en die diagram het altyd duidelik gewys waar die probleem is.
Verder moes ek in die alledaagse werk kruising doen. En ek het moeg geword om elke keer na Cisco-skakelaars te gaan om te sien watter koppelvlak om te gebruik. Hoe gaaf sou dit wees om op 'n voorwerp in monitering te klik en 'n lys van sy koppelvlakke met beskrywings te sien. Dit sou my tyd spaar. Boonop sal dit in hierdie skema nie nodig wees om Putty of SecureCRT te laat loop om rekeninge en opdragte in te voer nie. Ek het net op die monitering geklik, gesien wat nodig is en my werk gaan doen. Ek het begin soek na maniere om met skakelaars te kommunikeer. Ek het dadelik op 2 opsies afgekom: SNMP of om via SSH by die skakelaar aan te meld, die opdragte wat ek nodig gehad het in te voer en die resultaat te ontleed. Ek het SNMP van die hand gewys weens die kompleksiteit van die implementering daarvan; Ek was ongeduldig om die resultaat te kry. met SNMP sal jy lank in die MIB moet delf en, gebaseer op hierdie data, data oor die koppelvlakke genereer. Daar is 'n wonderlike span by CISCO
show interface statusDit wys presies wat ek nodig het vir kruisings. Hoekom pla met SNMP as ek net die uitvoer van hierdie opdrag wil sien, het ek gedink. Na 'n ruk het ek hierdie geleentheid besef. Op 'n voorwerp op 'n webblad geklik. 'n Gebeurtenis is geaktiveer waardeur die AJAX-kliënt die bediener gekontak het, en dit het op sy beurt via SSH gekoppel aan die skakelaar wat ek nodig gehad het (die geloofsbriewe is hardkodeer in die kode, daar was geen begeerte om dit te verfyn nie, om 'n paar aparte spyskaarte te maak waar dit sou moontlik wees om rekeninge te verander vanaf die koppelvlak , ek het die resultaat nodig gehad en vinnig) Ek het die bogenoemde opdrag daar ingevoer en dit teruggestuur na die blaaier. Ek het dus met een klik van die muis inligting oor koppelvlakke begin sien. Dit was uiters gerieflik, veral wanneer jy hierdie inligting gelyktydig op verskillende skakelaars moes sien.
Spoor-gebaseerde kanaalmonitering was uiteindelik nie die beste idee nie, want ... soms is daar op die netwerk gewerk, en die opsporing kon verander en die monitering het vir my begin skree dat daar probleme met die kanaal is. Maar nadat ek baie tyd aan ontleding bestee het, het ek besef dat alle kanale werk, en my monitering het my bedrieg. Gevolglik het ek my kollegas wat kanaalvormende skakelaars bestuur het gevra om bloot vir my syslog te stuur wanneer die sigbaarheidstatus van bure verander. Gevolglik was dit baie eenvoudiger, vinniger en meer akkuraat as om op te spoor. 'n Gebeurtenis soos buurman verloor het aangebreek, en ek reik dadelik 'n kennisgewing oor die kanaal af.
Verder het verskeie meer opdragte verskyn wanneer op 'n voorwerp geklik is, en SNMP is bygevoeg om 'n paar statistieke te versamel, en dit is basies dit. Die stelsel het nooit verder ontwikkel nie. Dit het alles gedoen wat ek nodig gehad het, dit was 'n goeie hulpmiddel. Baie lesers sal seker vir my sê dat daar reeds baie sagteware op die internet is om hierdie probleme op te los. Maar om die waarheid te sê, ek het destyds nie sulke gratis produkte gegoogle nie en ek wou regtig my programmeringsvaardighede ontwikkel, en watter beter manier om hiervoor te druk as 'n werklike toepassingsprobleem. Op hierdie stadium is die eerste weergawe van monitering voltooi en is dit nie meer gewysig nie.
Skepping van die maatskappy Oudit-Telecom
Met verloop van tyd het ek deeltyds in ander maatskappye begin werk, gelukkig het my werkskedule my toegelaat om dit te doen. Wanneer jy in verskillende maatskappye werk, groei jou vaardighede op verskeie gebiede baie vinnig, en jou horisonne ontwikkel goed. Daar is geselskappe waarin, soos hulle sê, jy 'n Sweed, 'n maaier en 'n trompetspeler is. Aan die een kant is dit moeilik, aan die ander kant, as jy nie lui is nie, word jy 'n generalis en dit laat jou toe om probleme vinniger en meer doeltreffend op te los omdat jy weet hoe die verwante veld werk.
My vriend Pavel (ook 'n IT-spesialis) het my voortdurend probeer aanmoedig om sy eie besigheid te begin. Daar was talle idees met verskillende variasies van wat hulle doen. Dit word al jare lank bespreek. En op die ou end moes dit tot niks gekom het nie, want ek is 'n skeptikus, en Pavel is 'n dromer. Elke keer as hy 'n idee voorgestel het, het ek altyd nie daarin geglo nie en geweier om deel te neem. Maar ons wou regtig ons eie besigheid oopmaak.
Uiteindelik kon ons 'n opsie vind wat ons albei pas en doen wat ons weet hoe om te doen. In 2016 het ons besluit om 'n IT-maatskappy te skep wat besighede sal help om IT-probleme op te los. Dit is die ontplooiing van IT-stelsels (1C, terminale bediener, posbediener, ens.), die instandhouding daarvan, klassieke HelpDesk vir gebruikers en netwerkadministrasie.
Eerlik gesê, ten tyde van die stigting van die maatskappy, het ek omtrent 99,9% nie daarin geglo nie. Maar op een of ander manier kon Pavel my kry om te probeer, en vooruit gekyk het, blyk hy reg te wees. Ek en Pavel het elk 300 000 roebels ingeskiet, 'n nuwe LLC "Audit-Telecom" geregistreer, 'n klein kantoortjie gehuur, oulike besigheidskaartjies gemaak, wel, in die algemeen, soos waarskynlik die meeste onervare, beginner sakemanne, en begin om kliënte te soek. Om kliënte te vind is 'n heeltemal ander storie. Miskien sal ons 'n aparte artikel skryf as deel van die korporatiewe blog as iemand belangstel. Koue oproepe, pamflette, ens. Dit het geen resultate opgelewer nie. Soos ek nou uit baie stories oor besigheid lees, op een of ander manier, hang baie van geluk af. Ons was gelukkig. en letterlik 'n paar weke na die skepping van die maatskappy, het my broer Vladimir ons genader, wat ons ons eerste kliënt gebring het. Ek sal jou nie verveel met die besonderhede van die werk met kliënte nie, dit is nie waaroor die artikel gaan nie, ek sal net sê dat ons vir 'n oudit gegaan het, kritieke areas geïdentifiseer het en hierdie areas het afgebreek terwyl die besluit geneem is of ons werk op 'n deurlopende basis as uitkontrakteerders saam met ons. Hierna is dadelik 'n positiewe besluit geneem.
Toe, hoofsaaklik deur mond tot mond deur vriende, het ander diensmaatskappye begin verskyn. Hulptoonbank was in een stelsel. Verbindings met netwerktoerusting en bedieners is anders, of eerder anders. Sommige mense het kortpaaie gestoor, ander het HOP-adresboeke gebruik. Monitering is nog 'n aparte stelsel. Dit is baie ongerieflik vir 'n span om in uiteenlopende stelsels te werk. Belangrike inligting word uit die oog verloor. Wel, byvoorbeeld, die kliënt se terminale bediener het nie beskikbaar geraak nie. Aansoeke van gebruikers van hierdie kliënt word onmiddellik ontvang. Die ondersteuningspesialis maak 'n versoek oop (dit is per telefoon ontvang). As voorvalle en versoeke in een stelsel geregistreer is, sal die ondersteuningspesialis dadelik sien wat die gebruiker se probleem is en hom daarvan vertel, terwyl hy terselfdertyd met die vereiste voorwerp verbind om die situasie uit te werk. Almal is bewus van die taktiese situasie en werk harmonieus. Ons het nie 'n stelsel gevind waar dit alles gekombineer word nie. Dit het duidelik geword dat dit tyd was om ons eie produk te maak.
Voortgesette werk aan jou moniteringstelsel
Dit was duidelik dat die stelsel wat vroeër geskryf is, heeltemal ongeskik was vir die huidige take. Nóg in terme van funksionaliteit nóg in terme van kwaliteit. En daar is besluit om die stelsel van nuuts af te skryf. Grafies moes dit heeltemal anders gelyk het. Dit moes 'n hiërargiese stelsel wees sodat dit moontlik sou wees om vinnig en gerieflik die regte objek vir die regte kliënt oop te maak. Die skema soos in die eerste weergawe was absoluut nie geregverdig in die huidige geval nie, want Die kliënte verskil en dit het glad nie saak gemaak in watter perseel die toerusting geleë was nie. Dit is reeds na die dokumentasie oorgedra.
Dus, die take:
- Hiërargiese struktuur;
- Een of ander bedieneronderdeel wat op die kliënt se perseel geplaas kan word in die vorm van 'n virtuele masjien om die maatstawwe wat ons benodig in te samel en dit na die sentrale bediener te stuur, wat dit alles sal opsom en aan ons wys;
- Waarskuwings. Diegene wat nie misgeloop kan word nie, want... daardie tyd was dit nie moontlik vir iemand om net na die monitor te sit en kyk nie;
- Toepassingstelsel. Kliënte het begin verskyn vir wie ons nie net bediener- en netwerktoerusting gediens het nie, maar ook werkstasies;
- Vermoë om vinnig aan bedieners en toerusting vanaf die stelsel te koppel;
Die take is opgestel, ons begin skryf. Langs die pad, verwerking van versoeke van kliënte. Op daardie stadium was ons al 4. Ons het albei dele gelyktydig begin skryf: die sentrale bediener en die bediener vir installasie aan kliënte. Op hierdie stadium was Linux nie meer 'n vreemdeling vir ons nie en daar is besluit dat die virtuele masjiene wat kliënte sou hê op Debian sou wees. Daar sal geen installeerders wees nie, ons sal net 'n bedienerdeelprojek op een spesifieke virtuele masjien maak, en dan sal ons dit net na die gewenste kliënt kloon. Dit was nog 'n fout. Later het dit duidelik geword dat in so 'n skema die opdateringsmeganisme heeltemal onontwikkel was. Dié. ons het 'n nuwe kenmerk bygevoeg, en toe was daar die hele probleem om dit na alle kliëntbedieners te versprei, maar ons sal later hierna terugkom, alles in orde.
Ons het die eerste prototipe gemaak. Hy kon die kliëntnetwerktoestelle en -bedieners wat ons nodig gehad het ping en hierdie data na ons sentrale bediener stuur. En hy het op sy beurt hierdie data in grootmaat op die sentrale bediener opgedateer. Hier sal ek nie net 'n storie skryf oor hoe en wat suksesvol was nie, maar ook watter amateuristiese foute gemaak is en hoe ek later mettertyd daarvoor moes betaal. Dus, die hele boom van voorwerpe is gestoor in een enkele lêer in die vorm van 'n geserialiseerde voorwerp. Terwyl ons verskeie kliënte aan die stelsel gekoppel het, was alles min of meer normaal, hoewel daar soms 'n paar artefakte was wat heeltemal onverstaanbaar was. Maar toe ons 'n dosyn bedieners aan die stelsel gekoppel het, het wonderwerke begin gebeur. Soms, om een of ander onbekende rede, het alle voorwerpe in die stelsel eenvoudig verdwyn. Dit is belangrik om hier op te let dat die bedieners wat die kliënte gehad het data elke paar sekondes na die sentrale bediener gestuur het via 'n POST-versoek. 'n Oplettende leser en 'n ervare programmeerder het reeds geraai dat daar 'n probleem was met veelvuldige toegang tot die einste lêer waarin die geserialiseerde voorwerp van verskillende drade tegelyk gestoor is. En net toe dit gebeur het, het wonderwerke plaasgevind met die verdwyning van voorwerpe. Die lêer het eenvoudig leeg geword. Maar dit alles is nie onmiddellik ontdek nie, maar slegs tydens werking met verskeie bedieners. Gedurende hierdie tyd is poortskanderingfunksionaliteit bygevoeg (die bedieners wat na die sentrale gestuur is, nie net inligting oor die beskikbaarheid van toestelle nie, maar ook oor die poorte wat daarop oop is). Dit is gedoen deur die opdrag te noem:
$connection = @fsockopen($ip, $port, $errno, $errstr, 0.5);
die resultate was dikwels verkeerd en skanderings het lank geneem om te voltooi. Ek het heeltemal vergeet van ping, dit is gedoen via fping:
system("fping -r 3 -t 100 {$this->ip}");
Dit was ook nie geparalleliseer nie en daarom was die proses baie lank. Later is die hele lys van IP-adresse wat nodig is vir verifikasie op een slag na fping gestuur, en terug het ons 'n klaargemaakte lys ontvang van diegene wat gereageer het. Anders as ons, was fping in staat om prosesse te paralleliseer.
Nog 'n algemene roetine-werk was die opstel van sommige dienste via WEB. Wel, byvoorbeeld, ECP van MS Exchange. Basies is dit net 'n skakel. En ons het besluit dat ons sulke skakels direk by die stelsel moet kan voeg, sodat ons nie in die dokumentasie of iewers anders in boekmerke hoef te soek hoe om toegang tot die ECP van 'n spesifieke kliënt te kry nie. Dit is hoe die konsep van hulpbronskakels vir die stelsel verskyn het, hul funksionaliteit is tot vandag toe beskikbaar en het nie verander nie, wel, amper.
Hoe hulpbronskakels in Veliam werk
Afgeleë verbindings
Dit is hoe dit in aksie in die huidige weergawe van Veliam lyk
Een van die take was om vinnig en gerieflik aan bedieners te koppel, waarvan daar reeds baie (meer as honderd) was en om deur miljoene vooraf-gestoorde HOP-kortpaaie te sorteer was uiters ongerieflik. 'n Gereedskap was nodig. Daar is sagteware op die internet wat iets soos 'n adresboek vir sulke HOP-verbindings is, maar dit is nie geïntegreer met die moniteringstelsel nie, en rekeninge kan nie gestoor word nie. Om elke keer rekeninge vir verskillende kliënte in te voer is pure hel wanneer jy dosyne kere per dag aan verskillende bedieners koppel. Met SSH is dinge 'n bietjie beter; daar is baie goeie sagteware wat jou toelaat om sulke verbindings in dopgehou te organiseer en die rekeninge van hulle te onthou. Maar daar is 2 probleme. Die eerste is dat ons nie 'n enkele program vir RDP- en SSH-verbindings gevind het nie. Die tweede is dat as ek op 'n stadium nie by my rekenaar is nie en ek vinnig moet koppel, of ek het net die stelsel weer geïnstalleer, sal ek na die dokumentasie moet gaan om na die rekening van hierdie kliënt te kyk. Dit is ongerieflik en 'n mors van tyd.
Die hiërargiese struktuur wat ons vir kliëntbedieners benodig het, was reeds in ons interne produk beskikbaar. Ek moes net uitvind hoe om vinnige verbindings daar aan die nodige toerusting te koppel. Om mee te begin, ten minste binne jou netwerk.
Met inagneming van die feit dat die kliënt in ons stelsel 'n blaaier was wat nie toegang het tot die plaaslike hulpbronne van die rekenaar nie, om eenvoudig die toepassing wat ons nodig gehad het met 'n opdrag te begin, is dit uitgevind om alles te doen deur die "Windows pasgemaakte URL-skema”. Dit is hoe 'n sekere "inprop" vir ons stelsel verskyn het, wat eenvoudig Putty en Remote Desktop Plus ingesluit het en, tydens installasie, eenvoudig die URI-skema in Windows geregistreer het. Nou, toe ons via RDP of SSH aan 'n voorwerp wou koppel, het ons hierdie aksie op ons stelsel geklik en die Custom URI het gewerk. Die standaard mstsc.exe wat in Windows of stopverf ingebou is, wat deel was van die "inprop", is bekendgestel. Ek sit die woord plugin tussen aanhalingstekens omdat dit nie 'n blaaier-inprop in die klassieke sin is nie.
Dit was darem iets. Gerieflike adresboek. Boonop, in die geval van Putty, was alles oor die algemeen goed; dit kon IP-verbindings, aanmelding en wagwoord as invoerparameters gegee word. Dié. Ons het reeds met een klik aan Linux-bedieners op ons netwerk gekoppel sonder om wagwoorde in te voer. Maar met HOP is dit nie so eenvoudig nie. Standaard mstsc kan nie geloofsbriewe as parameters verskaf nie. Remote Desktop Plus het tot die redding gekom. Hy het toegelaat dat dit gebeur. Nou kan ons daarsonder klaarkom, maar vir 'n lang tyd was dit 'n getroue assistent in ons stelsel. Met HTTP(S)-webwerwe is alles eenvoudig, sulke voorwerpe word eenvoudig in die blaaier oopgemaak en dit is dit. Gerieflik en prakties. Maar dit was net geluk op die interne netwerk.
Aangesien ons die oorgrote meerderheid probleme op afstand vanaf die kantoor opgelos het, was die maklikste ding om VPN’s aan kliënte beskikbaar te stel. En dan was dit moontlik om vanaf ons stelsel met hulle te koppel. Maar dit was steeds ietwat ongerieflik. Vir elke kliënt was dit nodig om 'n klomp onthou VPN-verbindings op elke rekenaar te hou, en voordat u met enige koppel, was dit nodig om die ooreenstemmende VPN te aktiveer. Ons het hierdie oplossing vir 'n redelike lang tyd gebruik. Maar die aantal kliënte neem toe, die aantal VPN’s neem ook toe, en dit het alles begin druk en iets moes daaromtrent gedoen word. Trane het veral in my oë gekom nadat ek die stelsel herinstalleer het, toe ek weer tientalle VPN-verbindings in 'n nuwe Windows-profiel moes invoer. Hou op om dit te verdra, het ek gesê, en begin dink oor wat ek daaraan kan doen.
Dit het so gebeur dat alle kliënte toestelle van die bekende maatskappy Mikrotik as routers gehad het. Hulle is baie funksioneel en gerieflik om byna enige taak uit te voer. Die nadeel is dat hulle “gekaap” word. Ons het hierdie probleem eenvoudig opgelos deur alle toegang van buite af te sluit. Maar dit was nodig om op een of ander manier toegang tot hulle te hê sonder om na die kliënt se plek te kom, want ... dit is lank. Ons het sommer tonnels vir elke so 'n Mikrotik gemaak en dit in 'n aparte swembad geskei. sonder enige roetering, sodat daar geen verbinding van jou netwerk met die netwerke van kliënte en hul netwerke met mekaar is nie.
Die idee is gebore om seker te maak dat wanneer ek op die voorwerp wat ek nodig het in die stelsel klik, die sentrale moniteringsbediener, wat die SSH-rekeninge van alle kliënt Mikrotik ken, koppel aan die gewenste een, 'n aanstuurreël na die verlangde gasheer skep met die vereiste hawe. Hier is verskeie punte. Die oplossing is nie universeel nie - dit sal net vir Mikrotik werk, aangesien die opdragsintaksis verskil vir alle routers. Sulke aansendings moes ook dan op een of ander manier uitgevee word, en die bedienerdeel van ons stelsel kon in wese op geen manier naspoor of ek my RDP-sessie voltooi het nie. Wel, sulke aanstuur is 'n gat vir die kliënt. Maar ons het nie universaliteit nagestreef nie, want ... die produk is slegs binne ons maatskappy gebruik en daar was geen gedagtes om dit aan die publiek vry te stel nie.
Elkeen van die probleme is op sy eie manier opgelos. Toe die reël geskep is, was hierdie aanstuur slegs beskikbaar vir een spesifieke eksterne IP-adres (waaruit die verbinding geïnisialiseer is). ’n Sekuriteitsgat is dus vermy. Maar met elke so 'n verbinding is 'n Mikrotik-reël by die NAT-bladsy gevoeg en is nie skoongemaak nie. En almal weet dat hoe meer reëls daar is, hoe meer word die roeteerder se verwerker gelaai. En oor die algemeen kon ek nie aanvaar dat ek eendag na een of ander Mikrotik sou gaan nie, en daar sou honderde dooie, nuttelose reëls wees.
Aangesien ons bediener nie die verbindingstatus kan opspoor nie, laat Mikrotik dit self opspoor. En ek het 'n skrif geskryf wat voortdurend alle aanstuurreëls met 'n spesifieke beskrywing gemonitor het en gekyk het of die TCP-verbinding 'n geskikte reël het. As daar 'n geruime tyd nie een was nie, is die verbinding waarskynlik reeds voltooi en kan hierdie aanstuur uitgevee word. Alles het uitgewerk, die draaiboek het goed gewerk.
Terloops, hier is dit:
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
}
}
Dit kon sekerlik mooier, vinniger, ens. gemaak word, maar dit het gewerk, nie Mikrotik gelaai nie en uitstekende werk gedoen. Ons kon uiteindelik met net een klik aan kliënte se bedieners en netwerktoerusting koppel. Sonder om 'n VPN oop te maak of wagwoorde in te voer. Die stelsel het baie gerieflik geword om mee te werk. Dienstyd is verminder, en ons het almal tyd bestee aan werk eerder as om aan die nodige voorwerpe te koppel.
Mikrotik Rugsteun
Ons het rugsteun van alle Mikrotik na FTP gekonfigureer. En oor die algemeen was alles goed. Maar wanneer jy 'n rugsteun moes kry, moes jy hierdie FTP oopmaak en dit daar soek. Ons het 'n stelsel waar al die routers gekoppel is; ons kan via SSH met toestelle kommunikeer. Hoekom maak ons dit nie so dat die stelsel self daagliks rugsteun van alle Mikrotik neem nie, het ek gedink. En hy het dit begin implementeer. Ons het gekoppel, 'n rugsteun gemaak en dit na die stoor geneem.
Skripkode in PHP vir die neem van 'n rugsteun vanaf Mikrotik:
<?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');
?>
Die rugsteun word in twee vorme geneem - binêre en teksopstelling. Die binêre help om die vereiste konfigurasie vinnig te herstel, en die teks een laat jou toe om te verstaan wat gedoen moet word as daar 'n gedwonge vervanging van toerusting is en die binêre nie daarheen opgelaai kan word nie. As gevolg hiervan het ons nog 'n gerieflike funksionaliteit in die stelsel gekry. Verder, toe nuwe Mikrotik bygevoeg word, was dit nie nodig om enigiets op te stel nie; ek het eenvoudig die voorwerp by die stelsel gevoeg en 'n rekening daarvoor opgestel via SSH. Toe het die stelsel self gesorg vir die neem van rugsteun. Die huidige weergawe van SaaS Veliam het nog nie hierdie funksionaliteit nie, maar ons sal dit binnekort oordra.
Skermskote van hoe dit in die interne stelsel gelyk het
Oorgang na normale databasisberging
Ek het reeds hierbo geskryf dat artefakte verskyn het. Soms het die hele lys van voorwerpe in die stelsel eenvoudig verdwyn, soms wanneer 'n voorwerp gewysig is, is die inligting nie gestoor nie en moes die voorwerp drie keer hernoem word. Dit het almal vreeslik geïrriteer. Die verdwyning van voorwerpe het selde plaasgevind en is maklik herstel deur hierdie einste lêer te herstel, maar mislukkings met die redigering van voorwerpe het redelik gereeld voorgekom. Waarskynlik, ek het dit aanvanklik nie deur die databasis gedoen nie, want dit het nie in my gedagtes gepas hoe dit moontlik was om 'n boom met al die verbindings in 'n plat tafel te hou nie. Dit is plat, maar die boom is hiërargies. Maar 'n goeie oplossing vir meervoudige toegang, en daarna (namate die stelsel meer kompleks word) transaksionele, is 'n DBBS. Ek is waarskynlik nie die eerste wat hierdie probleem ondervind nie. Ek het begin google. Dit het geblyk dat alles reeds voor my uitgevind is en daar is verskeie algoritmes wat 'n boom van 'n plat tafel bou. Nadat ek na elkeen gekyk het, het ek een van hulle geïmplementeer. Maar dit was reeds 'n nuwe weergawe van die stelsel, want... Om die waarheid te sê, as gevolg hiervan moes ek nogal baie oorskryf. Die resultaat was natuurlik, die probleme van ewekansige gedrag van die stelsel het verdwyn. Sommige sal dalk sê dat die foute baie amateuragtig is (enkeldraadskrifte, stoor van inligting wat verskeie kere gelyktydig vanaf verskillende drade in 'n lêer verkry is, ens.) op die gebied van sagteware-ontwikkeling. Miskien is dit waar, maar my hooftaak was administrasie, en programmering was 'n bykomende druk vir my siel, en ek het eenvoudig nie ondervinding gehad om in 'n span programmeerders te werk nie, waar sulke basiese dinge onmiddellik deur my senior aan my voorgestel sou word. kamerade. Daarom het ek al hierdie knoppe op my eie gevul, maar ek het die materiaal baie goed geleer. En ook, my werk behels vergaderings met kliënte, aksies wat daarop gemik is om die maatskappy te probeer bevorder, 'n klomp administratiewe kwessies binne die maatskappy, en nog baie, baie meer. Maar op een of ander manier, wat reeds daar was, was in aanvraag. Ek en die ouens het self die produk in ons daaglikse werk gebruik. Daar was eerlikwaar onsuksesvolle idees en oplossings waarop tyd gemors is, maar op die ou end het dit duidelik geword dat dit nie 'n werkende hulpmiddel was nie en niemand het dit gebruik nie en dit het nie in Veliam beland nie.
Helpdesk - HelpDesk
Dit sal nie verkeerd wees om te noem hoe HelpDesk gevorm is nie. Dit is 'n heeltemal ander storie, want... in Veliam is dit reeds die 3de heeltemal nuwe weergawe, wat verskil van alle voriges. Nou is dit 'n eenvoudige stelsel, intuïtief sonder onnodige klokkies en fluitjies, met die vermoë om met 'n domein te integreer, sowel as die vermoë om toegang te verkry tot dieselfde gebruikersprofiel vanaf enige plek deur 'n skakel vanaf 'n e-pos te gebruik. En die belangrikste is dat dit moontlik is om vanaf enige plek (by die huis of op kantoor) direk vanaf die toepassing met die aansoeker via VNC te koppel sonder VPN of hawe-aanstuur. Ek sal jou vertel hoe ons hiertoe gekom het, wat voorheen gebeur het en watter verskriklike besluite geneem is.
Ons het aan gebruikers gekoppel deur die bekende TeamViewer. Alle rekenaars wie se gebruikers ons bedien, het TV geïnstalleer. Die eerste ding wat ons verkeerd gedoen het, en dit daarna verwyder het, was om elke HD-kliënt aan hardeware te koppel. Hoe het die gebruiker by die HD-stelsel aangemeld om 'n versoek te laat? Benewens TV het almal 'n spesiale hulpprogram op hul rekenaars laat installeer, geskryf in Lasarus (baie mense hier sal hul oë rol, en dalk selfs gaan Google wat dit is, maar die beste saamgestelde taal wat ek geken het was Delphi, en Lasarus is amper dieselfde ding, net gratis). Oor die algemeen het die gebruiker 'n spesiale bondellêer geloods wat hierdie program geloods het, wat op sy beurt die HWID van die stelsel gelees het en daarna is die blaaier geloods en magtiging het plaasgevind. Hoekom is dit gedoen? In sommige maatskappye word die aantal bediende gebruikers individueel getel, en die diensprys vir elke maand is gebaseer op die aantal mense. Dit is verstaanbaar, sê jy, maar hoekom is dit gekoppel aan hardeware? Dit is baie eenvoudig, sommige individue het huis toe gekom en 'n versoek vanaf hul tuisskootrekenaar gemaak in die styl van "maak alles vir my mooi hier." Benewens die lees van die stelsel HWID, het die hulpprogram die huidige Teamviewer ID uit die register getrek en dit ook aan ons oorgedra. Teamviewer het 'n API vir integrasie. En ons het hierdie integrasie gedoen. Maar daar was een vangs. Deur hierdie API's is dit onmoontlik om aan die gebruiker se rekenaar te koppel wanneer hy nie hierdie sessie uitdruklik inisieer nie en nadat hy probeer om daaraan te koppel, moet hy ook "bevestig" klik. Op daardie tydstip het dit vir ons logies gelyk dat niemand sonder die gebruiker se versoek moet koppel nie, en aangesien die persoon by die rekenaar is, sal hy die sessie begin en bevestigend reageer op die afstandverbindingsversoek. Alles het verkeerd uitgedraai. Aansoekers het vergeet om te druk om die sessie te begin, en moes hulle dit in 'n telefoongesprek vertel. Dit het tyd gemors en was frustrerend aan beide kante van die proses. Boonop is dit glad nie ongewoon vir sulke oomblikke wanneer 'n persoon 'n versoek verlaat nie, maar word toegelaat om slegs te koppel wanneer hy vir middagete vertrek. Want die probleem is nie kritiek nie en hy wil nie hê sy werksproses moet onderbreek word nie. Gevolglik sal hy geen knoppies druk om verbinding toe te laat nie. Dit is hoe bykomende funksionaliteit verskyn het toe u by HelpDesk aangemeld het - lees Teamviewer se ID. Ons het die permanente wagwoord geken wat gebruik is tydens die installering van Teamviewer. Meer presies, net die stelsel het dit geweet, aangesien dit in die installeerder en in ons stelsel ingebou is. Gevolglik was daar 'n verbindingsknoppie van die toepassing deur op te klik waarop dit nie nodig was om vir iets te wag nie, maar Teamviewer het onmiddellik oopgemaak en 'n verbinding het plaasgevind. As gevolg hiervan was daar twee tipes moontlike verbindings. Deur die amptelike Teamviewer API en ons selfgemaakte een. Tot my verbasing het hulle byna dadelik opgehou om die eerste een te gebruik, hoewel daar 'n opdrag was om dit slegs in spesiale gevalle te gebruik en wanneer die gebruiker self die trekpas gee. Gee my tog nou sekuriteit. Maar dit het geblyk dat die aansoekers dit nie nodig gehad het nie. Hulle is almal heeltemal in orde om aan hulle gekoppel te wees sonder 'n bevestigingsknoppie.
Skakel oor na multithreading in Linux
Die vraag om die deurgang van 'n netwerkskandeerder te bespoedig vir die oopheid van 'n voorafbepaalde lys poorte en eenvoudige ping van netwerkvoorwerpe het lankal begin ontstaan. Hier is natuurlik die eerste oplossing wat by my opkom multithreading. Aangesien die hooftyd wat aan ping spandeer word, wag vir die pakkie om teruggestuur te word, en die volgende ping nie kan begin voordat die vorige pakkie teruggestuur is nie, in maatskappye wat selfs 20+ bedieners plus netwerktoerusting gehad het, het dit reeds redelik stadig gewerk. Die punt is dat een pakket kan verdwyn, maar moenie dadelik die stelseladministrateur daaroor in kennis stel nie. Hy sal eenvoudig baie vinnig ophou om sulke strooipos te aanvaar. Dit beteken dat jy elke voorwerp meer as een keer moet ping voordat jy 'n gevolgtrekking maak oor ontoeganklikheid. Sonder om in te veel besonderhede in te gaan, is dit nodig om dit te paralleliseer, want as dit nie gedoen word nie, sal die stelseladministrateur heel waarskynlik van die probleem van die kliënt leer, en nie van die moniteringstelsel nie.
PHP self ondersteun nie multithreading uit die boks nie. In staat tot multiverwerking, kan jy vurk. Maar, in werklikheid, ek het reeds 'n stemmeganisme geskryf en ek wou dit so maak dat ek een keer al die nodusse wat ek nodig het van die databasis sou tel, alles op een slag sou ping, wag vir 'n antwoord van elkeen en eers daarna dadelik sou skryf die data. Dit bespaar op die aantal leesversoeke. Multithreading pas perfek by hierdie idee. Vir PHP is daar 'n PThreads-module wat jou toelaat om werklike multithreading te doen, alhoewel dit 'n redelike hoeveelheid peuterwerk geneem het om dit op PHP 7.2 op te stel, maar dit is gedoen. Poortskandering en ping is nou vinnig. En in plaas van byvoorbeeld 15 sekondes per rondte vroeër, het hierdie proses 2 sekondes begin neem. Dit was 'n goeie resultaat.
Vinnige oudit van nuwe maatskappye
Hoe het die funksionaliteit vir die versameling van verskeie metrieke en hardeware-eienskappe ontstaan? Dis eenvoudig. Soms word ons bloot beveel om die huidige IT-infrastruktuur te oudit. Wel, dieselfde ding is nodig om die oudit van 'n nuwe kliënt te bespoedig. Ons het iets nodig gehad wat ons in staat sou stel om na 'n medium of groot maatskappy te kom en vinnig uit te vind wat hulle het. Na my mening word ping op die interne netwerk slegs geblokkeer deur diegene wat hul eie lewens wil kompliseer, en volgens ons ervaring is daar min van hulle. Maar daar is ook sulke mense. Gevolglik kan u netwerke vinnig skandeer vir die teenwoordigheid van toestelle met 'n eenvoudige ping. Dan kan ons dit byvoeg en soek vir oop poorte wat ons interesseer. Trouens, hierdie funksionaliteit het reeds bestaan; dit was net nodig om 'n opdrag van die sentrale bediener by die slaaf een te voeg sodat dit die gespesifiseerde netwerke sou skandeer en alles wat dit gevind het by die lys sou voeg. Ek het vergeet om te noem, daar is aanvaar dat ons reeds 'n klaargemaakte beeld gehad het met 'n gekonfigureerde stelsel (slaafmoniteringbediener) wat ons eenvoudig tydens 'n oudit van die kliënt kon uitrol en dit aan ons wolk kon koppel.
Maar die resultaat van 'n oudit sluit gewoonlik 'n klomp verskillende inligting in, en een daarvan is watter soort toestelle op die netwerk is. Eerstens was ons geïnteresseerd in Windows-bedieners en Windows-werkstasies as deel van 'n domein. Aangesien in medium en groot maatskappye die gebrek aan 'n domein waarskynlik 'n uitsondering op die reël is. Om een taal te praat, is die gemiddelde, na my mening, 100+ mense. Dit was nodig om 'n manier te vind om data van alle Windows-masjiene en -bedieners in te samel, met kennis van hul IP- en domeinadministrateurrekening, maar sonder om enige sagteware op elkeen van hulle te installeer. Die WMI-koppelvlak kom tot die redding. Windows Management Instrumentation (WMI) beteken letterlik Windows-bestuurnutsmiddels. WMI is een van die basiese tegnologieë vir gesentraliseerde bestuur en monitering van die werking van verskeie dele van die rekenaarinfrastruktuur wat die Windows-platform bestuur. Van wiki geneem. Vervolgens moes ek weer peuter om wmic (dit is 'n WMI-kliënt) vir Debian saam te stel. Nadat alles gereed was, was al wat oorgebly het om bloot die nodige nodes deur wmic te poll vir die nodige inligting. Deur WMI kan jy byna enige inligting van 'n Windows-rekenaar kry, en bowendien kan jy ook die rekenaar daardeur beheer, byvoorbeeld, stuur om te herlaai. Dit is hoe die versameling van inligting oor Windows-stasies en -bedieners in ons stelsel verskyn het. Daarbenewens was daar huidige inligting oor huidige stelselladingsaanwysers. Ons versoek hulle meer gereeld, en inligting oor hardeware minder gereeld. Hierna het ouditering 'n bietjie lekkerder geword.
Sagteware verspreiding besluit
Ons self gebruik die stelsel elke dag, en dit is altyd oop vir elke tegniese werknemer. En ons het gedink dat ons met ander kan deel wat ons reeds het. Die stelsel was nog nie gereed om versprei te word nie. Baie moes herwerk word sodat die plaaslike weergawe in SaaS sou verander. Dit sluit in veranderinge in verskeie tegniese aspekte van die stelsel (afstandverbindings, ondersteuningsdiens), ontleding van modules vir lisensiëring, versplintering van kliëntedatabasisse, skaal van elke diens, en ontwikkeling van outomatiese opdateringstelsels vir alle onderdele. Maar dit sal die tweede deel van die artikel wees.
Werk
Bron: will.com