{"id":31068,"date":"2019-10-31T21:39:16","date_gmt":"2019-10-31T18:39:16","guid":{"rendered":"https:\/\/prohoster.info\/blog\/kak-vzyat-setevuyu-infrastrukturu-pod-svoj-kontrol-glava-pervaya-uderzhanie\/"},"modified":"2019-10-31T21:39:16","modified_gmt":"2019-10-31T18:39:16","slug":"kak-vzyat-setevuyu-infrastrukturu-pod-svoj-kontrol-glava-pervaya-uderzhanie","status":"publish","type":"post","link":"https:\/\/prohoster.info\/nl\/blog\/administrirovanie\/kak-vzyat-setevuyu-infrastrukturu-pod-svoj-kontrol-glava-pervaya-uderzhanie","title":{"rendered":"Hoe je de netwerkinfrastructuur onder controle kunt krijgen. Hoofdstuk \u00e9\u00e9n. Behoud","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p><i>Dit artikel is het eerste in een serie artikelen genaamd 'Hoe de netwerkinfrastructuur onder controle te krijgen'. De inhoud van alle artikelen in deze serie en de links zijn te vinden <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/post\/447008\/\">hier<\/a><\/noindex><\/i>.<\/p>\n<p>Ik neem aan dat er voldoende bedrijven zijn waar een eenvoudige netwerkonderbreking van een uur of zelfs een dag niet kritisch is. Helaas of gelukkig heb ik nooit in zulke plekken gewerkt. Maar natuurlijk zijn er verschillende netwerken, verschillende eisen, verschillende benaderingen, en toch zal de onderstaande lijst in veel gevallen feitelijk als een 'must-do' gelden.<\/p>\n<p>Dus, de uitgangsvoorwaarden. <\/p>\n<p>Je bent op een nieuwe werkplek of je hebt een promotie gekregen, of je hebt besloten om je verantwoordelijkheden vanuit een nieuw perspectief te bekijken. Het netwerk van het bedrijf is jouw verantwoordelijkheid. Voor jou is dit in veel opzichten een uitdaging en iets nieuws, wat de mentor-achtige toon van dit artikel een beetje rechtvaardigt :). Maar ik hoop dat dit artikel ook nuttig kan zijn voor elke netwerkingenieur.<\/p>\n<p>Jouw eerste strategische doel is om de entropie tegen te gaan en het niveau van de geboden service te handhaven. <\/p>\n<p>Veel van de hieronder beschreven taken kunnen op verschillende manieren worden opgelost. Ik breng bewust het onderwerp van technische implementatie niet ter sprake, omdat het in principe vaak niet zo belangrijk is hoe je een bepaalde taak oplost, maar het belangrijkste is hoe je het gebruikt en of je het \u00fcberhaupt gebruikt. Het heeft bijvoorbeeld weinig zin om een professioneel opgezet monitoringssysteem te hebben als je er niet naar kijkt en niet reageert op waarschuwingen.<br \/>\n<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<h2>Apparatuur<\/h2>\n<p>\nEerst moet je begrijpen waar de grootste risico's liggen.<\/p>\n<p>Het kan weer verschillend zijn. Ik neem aan dat dit ergens bijvoorbeeld veiligheidskwesties zijn, terwijl het ergens anders kan gaan om continu\u00efteit van de service, en misschien zijn er ergens helemaal andere zaken. Waarom niet?<\/p>\n<p>Laten we ter verduidelijking aannemen dat het toch continu\u00efteit van de service is (dat was het in alle bedrijven waar ik heb gewerkt).<\/p>\n<p>Begin dan met de apparatuur. Hier is een lijst van onderwerpen waarop je moet letten:<\/p>\n<ul>\n<li>classificatie van apparatuur op basis van kriticiteit<\/li>\n<li>redundantie van kritische apparatuur<\/li>\n<li>ondersteuning, licenties<\/li>\n<\/ul>\n<p>\nJe moet nadenken over mogelijke storingen, vooral met apparatuur die aan de top van je kriticiteit classificatie staat. Gewoonlijk wordt de kans op dubbele problemen genegeerd; anders kunnen je oplossing en ondersteuning onterecht duur worden. Maar in het geval van echt kritische netwerkcomponenten, waarvan het falen een aanzienlijke impact op het bedrijf kan hebben, moet je hier ook aan denken.<\/p>\n<blockquote><p><b>Voorbeeld<\/b><\/p>\n<p>Laten we aannemen dat we het hebben over de root-switch in het datacenter. <\/p>\n<p>Aangezien we overeen zijn gekomen dat de continu\u00efteit van de service het belangrijkste criterium is, is het verstandig om een 'hot' redundantie van deze apparatuur te waarborgen. Maar dat is nog niet alles. Je moet ook bepalen hoe lang, in het geval van een storing van de eerste switch, het voor jou acceptabel is om met slechts \u00e9\u00e9n overgebleven switch te werken, aangezien er een risico is dat ook deze uitvalt.<\/p>\n<p><b>Belangrijk! Je moet deze kwestie niet alleen oplossen. Je moet de risico's, mogelijke oplossingen en kosten aan je leidinggevende of het management van het bedrijf voorleggen. Zij moeten de beslissingen nemen.<\/b><\/p>\n<p>Dus, als is besloten dat, gezien de kleine kans op een dubbele storing, het werk gedurende 4 uur op \u00e9\u00e9n switch in principe acceptabel is, dan kun je gewoon de bijbehorende ondersteuning nemen (waarbij de apparatuur binnen 4 uur wordt vervangen). <\/p>\n<p>Maar er is het risico dat het niet op tijd geleverd wordt. Helaas zaten we eenmaal in zo'n situatie. In plaats van vier uur duurde het een week voordat de apparatuur arriveerde!!!<\/p>\n<p>Daarom moet dit risico ook besproken worden en misschien is het voor jou verstandiger om een extra switch (de derde) aan te schaffen en deze in reserve te houden ('cold' redundantie) of voor laboratoriumdoeleinden te gebruiken.<\/p><\/blockquote>\n<p>\n<b>Belangrijk! Maak een tabel van alle ondersteuning die je hebt met de vervaldatums en voeg deze toe aan je agenda, zodat je minstens een maand van tevoren een bericht ontvangt dat je je moet voorbereiden op het verlengen van de ondersteuning.<\/b><\/p>\n<p>Ze zullen je niet vergeven als je vergeet de ondersteuning te verlengen en de volgende dag na afloop van de ondersteuning je apparatuur stuk gaat.<\/p>\n<h2>Noodwerkzaamheden<\/h2>\n<p>\nWat er ook gebeurt in jouw netwerk, idealiter moet je toegang tot je netwerkapparatuur behouden. <\/p>\n<p><b>Belangrijk! U moet console-toegang hebben tot alle apparatuur en deze toegang mag niet afhankelijk zijn van de werking van het datanetwerk.<\/b><\/p>\n<p>U moet ook vooraf mogelijke negatieve scenario's overwegen en de noodzakelijke acties documenteren. De beschikbaarheid van dit document is ook cruciaal, dus het moet niet alleen op een centrale bron voor de afdeling worden geplaatst, maar ook lokaal op de computers van de ingenieurs worden behouden.<\/p>\n<p>Er moet verplicht daarin staan <\/p>\n<ul>\n<li>informatie die nodig is om een verzoek bij de ondersteuning van de leverancier of integrator in te dienen <\/li>\n<li>informatie over hoe toegang te krijgen tot elk apparaat (console, management)<\/li>\n<\/ul>\n<p>\nVerder kan het natuurlijk ook andere nuttige informatie bevatten, bijvoorbeeld een beschrijving van de upgradeprocedure van verschillende apparaten en nuttige diagnostische commando's.<\/p>\n<h2>Partners<\/h2>\n<p>\nNu moet u de risico's beoordelen die verband houden met partners. Gewoonlijk zijn dit<\/p>\n<ul>\n<li>internetproviders en peeringpunten (IX)<\/li>\n<li>aanbieders van communicatiediensten <\/li>\n<\/ul>\n<p>\nWelke vragen moet u zichzelf stellen? Net als bij de apparatuur moet u verschillende noodscenario's overwegen. Voor internetproviders kan dit iets zijn als:<\/p>\n<ul>\n<li>wat gebeurt er als internetprovider X om welke reden dan ook stopt met het aanbieden van diensten? <\/li>\n<li>hebben de andere providers voldoende bandbreedte?<\/li>\n<li>hoe goed blijft de connectiviteit?<\/li>\n<li>hoe onafhankelijk zijn uw internetproviders en zal een ernstige storing bij een van hen problemen bij anderen veroorzaken?<\/li>\n<li>hoeveel optische invoeren zijn er in uw datacenter? <\/li>\n<li>wat gebeurt er als een van de invoeren volledig verwoest wordt?<\/li>\n<\/ul>\n<p>\nWat betreft de invoeren, in mijn ervaring in twee verschillende bedrijven, in twee verschillende <a class=\"wpil_keyword_link\" href=\"https:\/\/prohoster.info\/nl\/kompaniya\/data-centers\/\"   title=\"datacenters\" data-wpil-keyword-link=\"linked\"  data-wpil-monitor-id=\"4668\">datacenters<\/a> heeft een graafmachine putten verwoest en alleen door toeval was onze glasvezel niet geraakt. Het is geen zeldzaam geval.<\/p>\n<p>En natuurlijk moet u niet alleen deze vragen stellen, maar ook, wederom met de steun van het management, zorgen voor een aanvaardbare oplossing in elke situatie. <\/p>\n<h2>Back-up<\/h2>\n<p>\nDe volgende prioriteit kan het maken van een back-up van de configuraties van de apparatuur zijn. Hoe dan ook, dit is een zeer belangrijk punt. Ik ga niet alle gevallen opsommen waarin u uw configuratie kunt verliezen, het is beter om regelmatig een back-up te maken en er niet over na te denken. Bovendien kan een regelmatige back-up zeer nuttig zijn voor het beheersen van wijzigingen.<\/p>\n<p><b>Belangrijk! Maak dagelijkse back-ups. Het is niet zo'n grote hoeveelheid data dat je hierop moet besparen. In de ochtend moet de dienstdoende engineer (of jij) een rapport van het systeem ontvangen, waarin duidelijk staat of de back-up succesvol was of niet. In geval van een mislukte back-up moet het probleem worden opgelost of moet er een ticket worden aangemaakt (zie de processen van de netwerkafdeling). <\/b><\/p>\n<h2>Softwareversies<\/h2>\n<p>\nDe vraag of het verstandig is om de software van de hardware te upgraden, is niet zo duidelijk. Aan de ene kant zijn oude versies bekend om hun bugs en kwetsbaarheden, maar aan de andere kant is nieuwe software niet altijd een pijnloze upgradeprocedure, en kunnen er bovendien nieuwe bugs en kwetsbaarheden optreden.<\/p>\n<p>Hier moet je de optimale oplossing vinden. Enkele voor de hand liggende aanbevelingen<\/p>\n<ul>\n<li>installeer alleen stabiele versies<\/li>\n<li>het is echter niet aan te raden om volledig op verouderde versies van software te blijven leven<\/li>\n<li>maak een tabel met informatie over welke software waar staat<\/li>\n<li>lees periodiek de rapporten over kwetsbaarheden en bugs in de softwareversies, en bij kritieke problemen moet je overwegen te upgraden<\/li>\n<\/ul>\n<p>\nOp dit punt, met consoletoegang tot de hardware, informatie over de ondersteuning en een beschrijving van de upgradeprocedure, ben je in principe klaar voor deze stap. Het ideale scenario is wanneer je laboratoriumapparatuur hebt waarop je de gehele procedure kunt testen, maar dit komt helaas niet vaak voor.<\/p>\n<p>In het geval van kritieke apparatuur kun je de leverancier om ondersteuning vragen voor het uitvoeren van de upgrade.<\/p>\n<h2>Ticketsysteem<\/h2>\n<p>\nNu kun je om je heen kijken. Je moet processen voor interactie met andere afdelingen en binnen de afdeling op gang brengen. <\/p>\n<p>Misschien is dit niet verplicht (bijvoorbeeld als je bedrijf klein is), maar ik zou sterk aanbevelen om het werk zo te organiseren dat alle externe en interne taken via het ticketsysteem verlopen.<\/p>\n<p>Het ticketsysteem is in wezen jouw interface voor interne en externe communicatie, en je moet deze interface met voldoende detail beschrijven.<\/p>\n<p>Laten we ter illustratie een belangrijke en vaak voorkomende taak bekijken voor het verlenen van toegang. Ik zal het algoritme beschrijven dat uitstekend heeft gewerkt in een van de bedrijven.<\/p>\n<blockquote><p><b>Voorbeeld<\/b><\/p>\n<p>Laten we beginnen met het feit dat klanten vaak hun toegangseisen formuleren in een taal die voor netwerkingenieurs onduidelijk is, namelijk in de taal van de applicatie, bijvoorbeeld: \u201cgeef mij toegang tot 1C\u201d. <\/p>\n<p>Daarom hebben we nooit verzoeken rechtstreeks van dergelijke gebruikers aangenomen. <br \/>\nEn dat was de eerste vereiste.<\/p>\n<ul>\n<li>Verzoeken om toegang moeten komen van technische afdelingen (in ons geval waren dat Unix-, Windows- en helpdeskingenieurs).<\/li>\n<\/ul>\n<p>\nDe tweede vereiste is dat. <\/p>\n<ul>\n<li>deze toegang gedocumenteerd moet zijn (door de technische afdeling van wie we het verzoek hebben ontvangen) en als verzoek krijgen we een link naar deze gedocumenteerde toegang. <\/li>\n<\/ul>\n<p>\nDe vorm van dit verzoek moet voor ons duidelijk zijn, dat wil zeggen. <\/p>\n<ul>\n<li>het verzoek moet informatie bevatten over van welk subnet en naar welk subnet de toegang moet worden geopend, alsook over het protocol en (in het geval van tcp\/udp) de poorten.<\/li>\n<\/ul>\n<p>\nOok moet er aangegeven worden. <\/p>\n<ul>\n<li>een beschrijving voor welk doel deze toegang wordt geopend.<\/li>\n<li>tijdelijk of permanent (als tijdelijk, tot welke datum).<\/li>\n<\/ul>\n<p>\nEn een zeer belangrijk punt is de goedkeuring.<\/p>\n<ul>\n<li>van de leidinggevende van de afdeling die de toegang heeft aangevraagd (bijvoorbeeld de boekhouding).<\/li>\n<li>van de leidinggevende van de technische afdeling van waaruit dit verzoek naar de netwerkafdeling is gestuurd (bijvoorbeeld helpdesk).<\/li>\n<\/ul>\n<p>\nBij dit alles wordt de 'eigenaar' van deze toegang beschouwd als de leidinggevende van de afdeling die de toegang heeft aangevraagd (boekhouding in ons voorbeeld), en hij is verantwoordelijk voor ervoor te zorgen dat de pagina met gedocumenteerde toegangen voor deze afdeling actueel blijft.\n<\/p><\/blockquote>\n<p><\/p>\n<h2>Logging<\/h2>\n<p>\nDit is waar je in kunt verdrinken. Maar als je een proactieve benadering wilt implementeren, moet je leren omgaan met deze stroom van gegevens.<\/p>\n<blockquote><p>Hier zijn een paar praktische aanbevelingen:<\/p>\n<ul>\n<li>controleer logboeken dagelijks.<\/li>\n<li>Bij een geplande controle (en niet bij een noodsituatie) kun je je beperken tot de ernstniveaus (severity) 0, 1, 2 en extra gekozen patronen uit andere niveaus toevoegen als je dat nodig acht.<\/li>\n<li>Schrijf een script dat de logboeken doorzoekt en de logboeken negeert waarvan de patronen je in de ignor-lijst hebt toegevoegd.<\/li>\n<\/ul>\n<p>\nDeze aanpak zal je in de loop van de tijd in staat stellen een herinneringslijst op te stellen van logboeken die niet interessant voor je zijn, en alleen die te behouden die je echt belangrijk acht.<br \/>\nBij ons werkte dit uitstekend.<\/p><\/blockquote>\n<p><\/p>\n<h2>Monitoring<\/h2>\n<p>\nHet is niet ongebruikelijk dat een bedrijf geen monitortoepassing heeft. Je kunt bijvoorbeeld hopen op logs, maar de apparatuur kan simpelweg 'overlijden' zonder iets te 'zeggen', of een UDP-pakket van het syslog-protocol kan verloren gaan en niet aankomen. Kortom, actieve monitoring is natuurlijk belangrijk en noodzakelijk.<\/p>\n<blockquote><p>Twee veelgevraagde voorbeelden uit mijn praktijk:<\/p>\n<ul>\n<li>monitoring van de bandbreedte van kritieke verbindingen (zoals verbindingen naar providers). Ze stellen je in staat om proactief potenti\u00eble problemen met de degradatie van de service door verkeersverlies te zien en deze te voorkomen.<\/li>\n<li>grafieken gebaseerd op NetFlow. Ze stellen je in staat om gemakkelijk anomalie\u00ebn in het verkeer te vinden en zijn zeer nuttig voor het detecteren van sommige eenvoudige, maar significante soorten hackeraanvallen.<\/li>\n<\/ul>\n<\/blockquote>\n<p>\n<b>Belangrijk! Stel SMS-meldingen in voor de meest kritieke gebeurtenissen. Dit geldt zowel voor monitoring als voor logging. Als je geen ploegendienst hebt, moeten SMS'jes ook buiten kantooruren binnenkomen. <\/b><\/p>\n<p>Denk het proces zo te structureren dat niet alle ingenieurs wakker worden. We hadden hiervoor een waakende ingenieur.<\/p>\n<h2>Wijzigingscontrole<\/h2>\n<p>\nNaar mijn mening is het niet noodzakelijk om alle wijzigingen te controleren. Maar, hoe dan ook, je moet in staat zijn om gemakkelijk te achterhalen wie en waarom bepaalde wijzigingen in het netwerk heeft aangebracht, indien nodig. <\/p>\n<blockquote><p>Enkele tips:<\/p>\n<ul>\n<li>gebruik een ticketsysteem voor een gedetailleerde beschrijving van wat er in het kader van dit ticket is gedaan, bijvoorbeeld door de toegepaste configuratie in het ticket te kopi\u00ebren<\/li>\n<li>gebruik de opmerkingen van netwerkapparatuur (zoals commit comment op Juniper). Je kunt het ticketnummer noteren<\/li>\n<li>gebruik diff van je configuratieback-ups<\/li>\n<\/ul>\n<p>\nJe kunt dit als een proces invoeren door dagelijks alle tickets te bekijken op wijzigingen.<\/p><\/blockquote>\n<p><\/p>\n<h2>Processen<\/h2>\n<p>\nJe moet de processen in je team formaliseren en beschrijven. Als je dit punt hebt bereikt, zouden er al minimaal de volgende processen in je team moeten zijn:<\/p>\n<p>Dagelijkse processen:<\/p>\n<ul>\n<li>werk met tickets<\/li>\n<li>werk met logs<\/li>\n<li>wijzigingscontrole<\/li>\n<li>dagelijks checklist<\/li>\n<\/ul>\n<p>\nJaarlijkse processen:<\/p>\n<ul>\n<li>verlenging van garanties, licenties<\/li>\n<\/ul>\n<p>\nAsynchrone processen:<\/p>\n<ul>\n<li>reactie op verschillende noodsituaties<\/li>\n<\/ul>\n<p><\/p>\n<h2>Conclusie van het eerste deel<\/h2>\n<p>\nJe hebt misschien opgemerkt dat dit nog niet over netwerkinstellingen gaat, niet over ontwerp, niet over netwerkprotocollen, niet over routering, niet over beveiliging... Het gaat om iets eromheen. Maar dit zijn, hoewel misschien saai, uiteraard zeer belangrijke elementen van het functioneren van een netwerkafdeling. <\/p>\n<p>Tot nu toe, zoals je kunt zien, heb je niets verbeterd in je netwerk. Als er beveiligings kwetsbaarheden waren, zijn ze er nog steeds, als het ontwerp slecht was, is het dat nog steeds. Totdat je je vaardigheden en kennis als netwerktechnicus hebt toegepast, waarmee waarschijnlijk veel tijd, moeite en soms zelfs geld is gemoeid. Maar eerst moet je een fundament cre\u00ebren (of versterken), en pas daarna kun je met de bouw beginnen.<\/p>\n<p>Over hoe je fouten kunt zoeken en oplossen, en vervolgens je infrastructuur kunt verbeteren \u2013 daarover gaan de volgende delen.<\/p>\n<p>Natuurlijk is het niet nodig alles opeenvolgend te doen. Tijd kan cruciaal zijn. Doe dit parallel, als de middelen dat toelaten.<\/p>\n<p>En een belangrijke aanvulling. Communiceer, vraag, overleg met je team. Uiteindelijk zijn zij het die dit alles moeten onderhouden en uitvoeren.<br \/>\n<br \/>Bron: <a content=\"nofollow\" rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/post\/433614\/\">habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"<p>\u042d\u0442\u0430 \u0441\u0442\u0430\u0442\u044c\u044f \u044f\u0432\u043b\u044f\u0435\u0442\u0441\u044f \u043f\u0435\u0440\u0432\u043e\u0439 \u0432 \u0446\u0438\u043a\u043b\u0435 \u0441\u0442\u0430\u0442\u0435\u0439 \u00ab\u041a\u0430\u043a \u0432\u0437\u044f\u0442\u044c \u0441\u0435\u0442\u0435\u0432\u0443\u044e \u0438\u043d\u0444\u0440\u0430\u0441\u0442\u0440\u0443\u043a\u0442\u0443\u0440\u0443 \u043f\u043e\u0434 \u0441\u0432\u043e\u0439 \u043a\u043e\u043d\u0442\u0440\u043e\u043b\u044c\u00bb. \u0421\u043e\u0434\u0435\u0440\u0436\u0430\u043d\u0438\u0435 \u0432\u0441\u0435\u0445 \u0441\u0442\u0430\u0442\u0435\u0439 \u0446\u0438\u043a\u043b\u0430 \u0438 \u0441\u0441\u044b\u043b\u043a\u0438 \u043c\u043e\u0436\u043d\u043e \u043d\u0430\u0439\u0442\u0438 \u0437\u0434\u0435\u0441\u044c. \u0412\u043f\u043e\u043b\u043d\u0435 \u0434\u043e\u043f\u0443\u0441\u043a\u0430\u044e, \u0447\u0442\u043e \u0441\u0443\u0449\u0435\u0441\u0442\u0432\u0443\u0435\u0442 \u0434\u043e\u0441\u0442\u0430\u0442\u043e\u0447\u043d\u043e\u0435 \u043a\u043e\u043b\u0438\u0447\u0435\u0441\u0442\u0432\u043e \u043a\u043e\u043c\u043f\u0430\u043d\u0438\u0439, \u0433\u0434\u0435 \u043f\u0440\u043e\u0441\u0442\u043e\u0439 \u0441\u0435\u0442\u0438 \u0432 \u043e\u0434\u0438\u043d \u0447\u0430\u0441 \u0438\u043b\u0438 \u0434\u0430\u0436\u0435 \u043e\u0434\u0438\u043d \u0434\u0435\u043d\u044c \u043d\u0435 \u044f\u0432\u043b\u044f\u0435\u0442\u0441\u044f \u043a\u0440\u0438\u0442\u0438\u0447\u043d\u044b\u043c. \u041c\u043d\u0435, \u043a \u0441\u043e\u0436\u0430\u043b\u0435\u043d\u0438\u044e \u0438\u043b\u0438 \u043a \u0441\u0447\u0430\u0441\u0442\u044c\u044e, \u043d\u0435 \u0434\u043e\u0432\u0435\u043b\u043e\u0441\u044c \u0440\u0430\u0431\u043e\u0442\u0430\u0442\u044c \u0432 \u0442\u0430\u043a\u0438\u0445 \u043c\u0435\u0441\u0442\u0430\u0445. [&hellip;]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-31068","post","type-post","status-publish","format-standard","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t<!-- All in One SEO 5.0.3 - aioseo.com -->\n\t<meta name=\"description\" content=\"\u042d\u0442\u0430 \u0441\u0442\u0430\u0442\u044c\u044f \u044f\u0432\u043b\u044f\u0435\u0442\u0441\u044f \u043f\u0435\u0440\u0432\u043e\u0439 \u0432 \u0446\u0438\u043a\u043b\u0435 \u0441\u0442\u0430\u0442\u0435\u0439 \u00ab\u041a\u0430\u043a \u0432\u0437\u044f\u0442\u044c \u0441\u0435\u0442\u0435\u0432\u0443\u044e \u0438\u043d\u0444\u0440\u0430\u0441\u0442\u0440\u0443\u043a\u0442\u0443\u0440\u0443 \u043f\u043e\u0434 \u0441\u0432\u043e\u0439 \u043a\u043e\u043d\u0442\u0440\u043e\u043b\u044c\u00bb.\" \/>\n\t<meta name=\"robots\" content=\"max-image-preview:large\" \/>\n\t<meta name=\"author\" content=\"Yuri Gagarin\"\/>\n\t<link rel=\"canonical\" href=\"https:\/\/prohoster.info\/nl\/blog\/administrirovanie\/kak-vzyat-setevuyu-infrastrukturu-pod-svoj-kontrol-glava-pervaya-uderzhanie\" \/>\n\t\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.3\" \/>\n\t\t<meta property=\"og:locale\" content=\"nl_NL\" \/>\n\t\t<meta property=\"og:site_name\" content=\"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b\" \/>\n\t\t<meta property=\"og:type\" content=\"article\" \/>\n\t\t<meta property=\"og:title\" content=\"\ud83e\udd47\u041a\u0430\u043a \u0432\u0437\u044f\u0442\u044c \u0441\u0435\u0442\u0435\u0432\u0443\u044e \u0438\u043d\u0444\u0440\u0430\u0441\u0442\u0440\u0443\u043a\u0442\u0443\u0440\u0443 \u043f\u043e\u0434 \u0441\u0432\u043e\u0439 \u043a\u043e\u043d\u0442\u0440\u043e\u043b\u044c. \u0413\u043b\u0430\u0432\u0430 \u043f\u0435\u0440\u0432\u0430\u044f. \u0423\u0434\u0435\u0440\u0436\u0430\u043d\u0438\u0435 | ProHoster\" \/>\n\t\t<meta property=\"og:description\" content=\"\u042d\u0442\u0430 \u0441\u0442\u0430\u0442\u044c\u044f \u044f\u0432\u043b\u044f\u0435\u0442\u0441\u044f \u043f\u0435\u0440\u0432\u043e\u0439 \u0432 \u0446\u0438\u043a\u043b\u0435 \u0441\u0442\u0430\u0442\u0435\u0439 \u00ab\u041a\u0430\u043a \u0432\u0437\u044f\u0442\u044c \u0441\u0435\u0442\u0435\u0432\u0443\u044e \u0438\u043d\u0444\u0440\u0430\u0441\u0442\u0440\u0443\u043a\u0442\u0443\u0440\u0443 \u043f\u043e\u0434 \u0441\u0432\u043e\u0439 \u043a\u043e\u043d\u0442\u0440\u043e\u043b\u044c\u00bb.\" \/>\n\t\t<meta property=\"og:url\" content=\"https:\/\/prohoster.info\/nl\/blog\/administrirovanie\/kak-vzyat-setevuyu-infrastrukturu-pod-svoj-kontrol-glava-pervaya-uderzhanie\" \/>\n\t\t<meta property=\"og:image\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:secure_url\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:width\" content=\"350\" \/>\n\t\t<meta property=\"og:image:height\" content=\"350\" \/>\n\t\t<meta property=\"article:published_time\" content=\"2019-10-31T18:39:16+00:00\" \/>\n\t\t<meta property=\"article:modified_time\" content=\"2019-10-31T18:39:16+00:00\" \/>\n\t\t<meta property=\"article:publisher\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<meta property=\"article:author\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<!-- All in One SEO -->\n\n","aioseo_head_json":{"title":"\ud83e\udd47Hoe je de netwerkinfrastructuur onder controle kunt krijgen. Hoofdstuk \u00e9\u00e9n. Behoud | ProHoster","description":"Dit artikel is het eerste in de serie artikelen \"Hoe je de netwerkinfrastructuur onder controle kunt krijgen\".","canonical_url":"https:\/\/prohoster.info\/nl\/blog\/administrirovanie\/kak-vzyat-setevuyu-infrastrukturu-pod-svoj-kontrol-glava-pervaya-uderzhanie","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"nl_NL","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47\u041a\u0430\u043a \u0432\u0437\u044f\u0442\u044c \u0441\u0435\u0442\u0435\u0432\u0443\u044e \u0438\u043d\u0444\u0440\u0430\u0441\u0442\u0440\u0443\u043a\u0442\u0443\u0440\u0443 \u043f\u043e\u0434 \u0441\u0432\u043e\u0439 \u043a\u043e\u043d\u0442\u0440\u043e\u043b\u044c. \u0413\u043b\u0430\u0432\u0430 \u043f\u0435\u0440\u0432\u0430\u044f. \u0423\u0434\u0435\u0440\u0436\u0430\u043d\u0438\u0435 | ProHoster","og:description":"\u042d\u0442\u0430 \u0441\u0442\u0430\u0442\u044c\u044f \u044f\u0432\u043b\u044f\u0435\u0442\u0441\u044f \u043f\u0435\u0440\u0432\u043e\u0439 \u0432 \u0446\u0438\u043a\u043b\u0435 \u0441\u0442\u0430\u0442\u0435\u0439 \u00ab\u041a\u0430\u043a \u0432\u0437\u044f\u0442\u044c \u0441\u0435\u0442\u0435\u0432\u0443\u044e \u0438\u043d\u0444\u0440\u0430\u0441\u0442\u0440\u0443\u043a\u0442\u0443\u0440\u0443 \u043f\u043e\u0434 \u0441\u0432\u043e\u0439 \u043a\u043e\u043d\u0442\u0440\u043e\u043b\u044c\u00bb.","og:url":"https:\/\/prohoster.info\/nl\/blog\/administrirovanie\/kak-vzyat-setevuyu-infrastrukturu-pod-svoj-kontrol-glava-pervaya-uderzhanie","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2019-10-31T18:39:16+00:00","article:modified_time":"2019-10-31T18:39:16+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"31068","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":"2026-01-21 04:23:19","breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-03-01 03:24:13","updated":"2026-01-21 04:23:19","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/posts\/31068","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/comments?post=31068"}],"version-history":[{"count":1,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/posts\/31068\/revisions"}],"predecessor-version":[{"id":164546,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/posts\/31068\/revisions\/164546"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/media?parent=31068"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/categories?post=31068"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/tags?post=31068"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}