{"id":31067,"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-vtoraya-chistka-i-dokumentirovanie\/"},"modified":"2019-10-31T21:39:16","modified_gmt":"2019-10-31T18:39:16","slug":"kak-vzyat-setevuyu-infrastrukturu-pod-svoj-kontrol-glava-vtoraya-chistka-i-dokumentirovanie","status":"publish","type":"post","link":"https:\/\/prohoster.info\/nl\/blog\/administrirovanie\/kak-vzyat-setevuyu-infrastrukturu-pod-svoj-kontrol-glava-vtoraya-chistka-i-dokumentirovanie","title":{"rendered":"Hoe je de netwerkarchitectuur onder controle krijgt. Hoofdstuk twee. Opschonen en documenteren","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p><i>Dit artikel is de tweede in een reeks artikelen genaamd 'Hoe uw netwerkinfrastructuur onder controle te krijgen'. De inhoud van alle artikelen in de reeks en de links zijn te vinden <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/post\/447008\/\">hier<\/a><\/noindex><\/i>.<\/p>\n<p><img decoding=\"async\" alt=\"Hoe je de netwerkarchitectuur onder controle krijgt. Hoofdstuk twee. Opschonen en documenteren\" src=\"\/wp-content\/uploads\/2019\/04\/7b8e020272ed52ef0a119714b0a5d58b.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nOnze doelstelling op dit moment is het ordenen van de documentatie en de configuratie. <br \/>\nU moet aan het einde van dit proces een set documenten en een netwerk hebben dat hiermee is geconfigureerd.<\/p>\n<p>We zullen nu niet praten over de beveiligingsaudit \u2013 dit zal het onderwerp zijn van het derde deel. <\/p>\n<p>De complexiteit van de taak die in dit stadium moet worden uitgevoerd varieert sterk van bedrijf tot bedrijf.<\/p>\n<p>De ideale situatie is wanneer<\/p>\n<ul>\n<li>uw netwerk is opgebouwd volgens het ontwerp en u heeft een complete set documentatie<\/li>\n<li>er in uw bedrijf een <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/post\/433614\/\">proces voor controle en wijzigingsbeheer is ingevoerd<\/a><\/noindex> voor het netwerk<\/li>\n<li>overeenkomstig dit proces heeft u documenten (inclusief alle benodigde schema's) die volledige informatie geven over de actuele stand van zaken<\/li>\n<\/ul>\n<p>\nIn dat geval is uw taak vrij eenvoudig. U moet de documenten bestuderen en alle wijzigingen doornemen die zijn aangebracht. <\/p>\n<p>In het slechtste geval heeft u een<\/p>\n<ul>\n<li>netwerk dat zonder ontwerp is opgebouwd, zonder plan, zonder goedkeuring, door ingenieurs zonder voldoende kwalificaties,<\/li>\n<li>met chaotische, niet-gedocumenteerde wijzigingen, met veel 'rommel' en suboptimale oplossingen<\/li>\n<\/ul>\n<p>\nHet is duidelijk dat uw situatie ergens tussenin ligt, maar helaas, op deze schaal van beter \u2013 slechter, heeft u een grote kans dichter bij het slechte einde te zijn.<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<p>In dit geval zal het ook van u vragen dat u gedachten kunt lezen, omdat u moet leren begrijpen wat de 'ontwerpers' wilden doen, hun logica te reconstrueren, af te maken wat niet was afgerond en de 'rommel' te verwijderen. <br \/>\nEn natuurlijk moet u ook hun fouten corrigeren, het ontwerp (in deze fase zo minimaal mogelijk) veranderen en schema's aanpassen of opnieuw cre\u00ebren. <\/p>\n<p>Dit artikel claimt in geen geval compleet te zijn. Hier zal ik alleen de algemene principes beschrijven en stil staan bij enkele veelvoorkomende problemen die opgelost moeten worden.<\/p>\n<h2>Documentenset<\/h2>\n<p><\/p>\n<blockquote><p>Laten we beginnen met een voorbeeld.<\/p>\n<p>Hieronder staan enkele documenten die gebruikelijk zijn om te maken binnen Cisco Systems bij het ontwerpen.<\/p>\n<p><b>CR<\/b> \u2013 Klantvereisten, klantbehoeften (technische specificaties).<br \/>\nWordt gezamenlijk met de klant opgesteld en definieert de eisen voor het netwerk.<\/p>\n<p><b>HLD<\/b> \u2013 High Level Design, high-level ontwerp op basis van netwerkvereisten (CR). Dit document legt de gekozen architecturale beslissingen uit en onderbouwt deze (topologie, protocollen, apparatuurkeuze, ...). HLD bevat geen gedetailleerde ontwerpinformatie, zoals de gebruikte interfaces en IP-adressen. Ook wordt er geen specifieke configuratie van de apparatuur besproken. Dit document is eerder bedoeld om het technische management van de klant de belangrijkste ontwerpelementen uit te leggen.<\/p>\n<p><b>LLD<\/b> \u2013 Low Level Design, een laag-niveau ontwerp op basis van het hoog-niveau ontwerp (HLD). <br \/>\nHet moet alle details bevatten die nodig zijn voor de uitvoering van het project, zoals informatie over hoe apparatuur aan te sluiten en in te stellen. Dit is een volledige gids voor de implementatie van het ontwerp. Dit document moet voldoende informatie bieden voor de uitvoering, zelfs door minder gekwalificeerd personeel. <\/p>\n<p>Dingen zoals IP-adressen, AS-nummers, en de fysieke bekabelingsschema's kunnen \"uitgebreid\" worden naar aparte documenten, zoals <b>NIP<\/b> (Network Implementation Plan).<\/p>\n<p>De bouw van het netwerk begint na het cre\u00ebren van deze documenten en verloopt strikt in overeenstemming met hen, en wordt vervolgens door de klant gecontroleerd (tests) op overeenstemming met het ontwerp.<\/p><\/blockquote>\n<p>\nNatuurlijk kunnen de vereisten voor projectdocumentatie verschillen per integrator, per klant, en per land. Maar we willen formaliteiten vermijden en het onderwerp inhoudelijk benaderen. Deze fase gaat niet om ontwerpen, maar om het organiseren van zaken, en we hebben een voldoende aantal documenten nodig om onze taken uit te voeren (schema's, tabellen, beschrijvingen, ...). <\/p>\n<p>En naar mijn mening bestaat er een absoluut minimum dat nodig is om het netwerk effectief te kunnen controleren.<\/p>\n<p>Dit zijn de volgende documenten:<\/p>\n<ul>\n<li>schema (logboek) van de fysieke bekabeling<\/li>\n<li>schema of schema's van het netwerk met wezenlijke L2\/L3-informatie<\/li>\n<\/ul>\n<p><\/p>\n<h2>Fysieke schakelschema<\/h2>\n<p>\nIn sommige kleine bedrijven vallen de taken met betrekking tot het installeren van apparatuur en fysieke bekabeling onder de verantwoordelijkheid van netwerkingenieurs. <\/p>\n<p>In dit geval wordt het probleem gedeeltelijk opgelost met de volgende benadering. <\/p>\n<ul>\n<li>gebruik de beschrijving op de interface om te beschrijven wat eraan is verbonden<\/li>\n<li>schakel administratief alle ongebruikte poorten van netwerkapparatuur uit (shutdown)<\/li>\n<\/ul>\n<p>\nDit stelt je in staat om, zelfs in het geval van een probleem met de verbinding (wanneer cdp of lldp niet werkt op deze interface), snel te bepalen wat er op deze poort is aangesloten.<br \/>\nDaarnaast kun je eenvoudig zien welke poorten bezet zijn en welke vrij, wat nodig is voor het plannen van de aansluitingen van nieuwe netwerkapparatuur, servers of werkstations. <\/p>\n<p>Maar het is duidelijk dat als je de toegang tot de apparatuur verliest, je ook de toegang tot deze informatie verliest. Bovendien kun je op deze manier geen belangrijke informatie vastleggen, zoals welk soort apparatuur, het stroomverbruik, het aantal poorten, in welke rack het zich bevindt, welke patchpanelen daar zijn, en naar welke rack\/patchpaneel ze zijn geslacht. Daarom is aanvullende documentatie (niet alleen beschrijvingen op de apparatuur) erg nuttig.<\/p>\n<p>De ideale optie is het gebruik van applicaties die zijn ontworpen voor het werken met dit soort informatie. Maar je kunt ook volstaan met eenvoudige tabellen (bijvoorbeeld in Excel) of de informatie die je nodig vindt, weergeven in L1\/L2-schema's.<\/p>\n<blockquote><p>Belangrijk!<\/p>\n<p>Een netwerkingenieur kan natuurlijk voldoende goed op de hoogte zijn van de nuances en normen van Systeem- en Kabelinfrastructuren, soorten racks, soorten ononderbroken stroomvoorzieningen, wat een koude en warme gang is, correct aarden,\u2026 evenals in principe de fysica van elementaire deeltjes of C++. Maar ze moeten toch begrijpen dat dit allemaal niet hun kennisgebied is. <\/p>\n<p>Daarom is het een goede praktijk om voor de taken met betrekking tot de installatie, aansluiting, ondersteuning van apparatuur, en ook de fysieke schakeling ofwel gespecialiseerde afdelingen ofwel toegewezen mensen te hebben. Meestal zijn dit datacenter ingenieurs voor datacenters en help-desk voor kantoren. <\/p>\n<p>Als dergelijke afdelingen in jouw bedrijf zijn voorzien, dan is het bijhouden van een logboek van fysieke verbindingen niet jouw taak, en kun je je beperken tot alleen de beschrijving op de interface en het administratief uitschakelen van ongebruikte poorten.<\/p><\/blockquote>\n<h2>Netwerkschema's<\/h2>\n<p>\nEr is geen universele aanpak voor het tekenen van schema's.<\/p>\n<p>Het belangrijkste is dat de schema's een begrip moeten geven van hoe het verkeer zal stromen, door welke logische en fysieke elementen van jouw netwerk.<\/p>\n<p>Met fysieke elementen bedoelen we<\/p>\n<ul>\n<li>actieve apparatuur<\/li>\n<li>interfaces\/poorten van actieve apparatuur<\/li>\n<\/ul>\n<p>\nOnder logische \u2014 <\/p>\n<ul>\n<li>logische apparaten (N7K VDC, Palo Alto VSYS, \u2026)<\/li>\n<li>VRF <\/li>\n<li>VLANs<\/li>\n<li>subinterfaces<\/li>\n<li>tunnels<\/li>\n<li>zones<\/li>\n<li>\u2026<\/li>\n<\/ul>\n<p>\nAls uw netwerk niet helemaal eenvoudig is, zal het uit verschillende segmenten bestaan. <br \/>\nBijvoorbeeld<\/p>\n<ul>\n<li>datacenter<\/li>\n<li>internet<\/li>\n<li>WAN<\/li>\n<li>externe toegang<\/li>\n<li>kantoor LAN<\/li>\n<li>DMZ<\/li>\n<li>\u2026<\/li>\n<\/ul>\n<p>\nHet is verstandig om verschillende schema's te hebben die zowel een algemeen overzicht geven (hoe het verkeer tussen al deze segmenten beweegt) als een gedetailleerde uitleg van elk afzonderlijk segment.<\/p>\n<p>Aangezien moderne netwerken veel logische niveaus kunnen hebben, kan het een goed (maar niet verplicht) idee zijn om verschillende schema's voor verschillende niveaus te maken; bijvoorbeeld in het geval van een overlay-aanpak kunnen de volgende schema's gelden:<\/p>\n<ul>\n<li>overlay<\/li>\n<li>L1\/L2 onderlaag<\/li>\n<li>L3 onderlaag<\/li>\n<\/ul>\n<p>\nNatuurlijk is het belangrijkste schema, zonder hetwelk je het idee van je ontwerp niet kunt begrijpen, het routeringsschema.<\/p>\n<h4>Routeringsschema<\/h4>\n<p>\nMinimaal moet dit schema weergeven<\/p>\n<ul>\n<li>welke routeringsprotocollen waar worden gebruikt<\/li>\n<li>basisinformatie over de configuratie van het routeringsprotocol (gebied\/AS-nummer\/router-id\/\u2026)<\/li>\n<li>op welke apparaten herdistributie plaatsvindt<\/li>\n<li>waar filtering en aggregatie van routes plaatsvindt<\/li>\n<li>informatie over de standaard route <\/li>\n<\/ul>\n<p>\nEen L2-schema (OSI) is ook vaak nuttig.<\/p>\n<h4>L2-schema (OSI)<\/h4>\n<p>\nDit schema kan de volgende informatie bevatten:<\/p>\n<ul>\n<li>welke VLAN's<\/li>\n<li>welke poorten trunkpoorten zijn<\/li>\n<li>welke poorten zijn samengevoegd in ether-channel (port channel), virtual port channel<\/li>\n<li>welke STP-protocollen op welke apparaten worden gebruikt<\/li>\n<li>basisinstellingen van STP: root\/root backup, STP-kosten, poortprioriteit<\/li>\n<li>aanvullende STP-instellingen: BPDU guard\/filter, root guard ...<\/li>\n<\/ul>\n<p><\/p>\n<h2>Typische ontwerpfouten<\/h2>\n<p><\/p>\n<blockquote><p>Voorbeeld van een slechte benadering bij het bouwen van een netwerk.<\/p>\n<p>Laten we een eenvoudig voorbeeld nemen van het opzetten van een eenvoudige kantoor-lokale netwerk.<\/p>\n<p>Met ervaring in het onderwijzen van telecom aan studenten kan ik zeggen dat feitelijk elke student halverwege het tweede semester over de nodige kennis beschikt (binnen de cursus die ik gaf) om een eenvoudige kantoor-LAN te configureren.<\/p>\n<p>Wat is er moeilijk aan het met elkaar verbinden van switches, instellen van VLAN, SVI-interfaces (in het geval van L3-switches) en het invoeren van statische routing?<\/p>\n<p>Alles zal werken.<\/p>\n<p>Maar daarmee blijven vragen over <\/p>\n<ul>\n<li>veiligheid<\/li>\n<li>redundantie<\/li>\n<li>netwerk schaalbaarheid<\/li>\n<li>prestaties<\/li>\n<li>doorvoersnelheid<\/li>\n<li>betrouwbaarheid<\/li>\n<li>\u2026<\/li>\n<\/ul>\n<p>\nSoms hoor ik de bewering dat een kantoorlokale netwerken (LAN) iets heel eenvoudigs is, en ik hoor dit meestal van ingenieurs (en managers) die met van alles bezig zijn, behalve netwerken. Ze zeggen dit zo vol vertrouwen dat je je niet zult verbazen als een LAN wordt opgezet door mensen met onvoldoende ervaring en kennis, met vele van de fouten die ik hieronder zal beschrijven.<\/p><\/blockquote>\n<p><\/p>\n<h4>Kenmerkende ontwerpfouten op L1-niveau (OSI)<\/h4>\n<p><\/p>\n<ul>\n<li>Als je ook verantwoordelijk bent voor het bekabelingsnetwerk, dan is een van de meest onaangename nalatenschappen die je kunt krijgen, slordige en niet doordachte schakelingen.<\/li>\n<\/ul>\n<p>\nOok zou ik fouten, gerelateerd aan de middelen van de gebruikte apparatuur, tot het L1-type rekenen, bijvoorbeeld,<\/p>\n<ul>\n<li>onvoldoende bandbreedte<\/li>\n<li>onvoldoende TCAM op de apparatuur (of ineffici\u00ebnt gebruik daarvan)<\/li>\n<li>onvoldoende prestaties (vaak gerelateerd aan firewalls)<\/li>\n<\/ul>\n<p><\/p>\n<h4>Kenmerkende ontwerpfouten op L2-niveau (OSI)<\/h4>\n<p>\nVaak, als er geen goed begrip is van hoe STP werkt, welke potenti\u00eble problemen het met zich meebrengt, worden switches chaotisch aangesloten, met standaardinstellingen, zonder extra tuning van STP. <\/p>\n<p>Als gevolg hiervan hebben we vaak het volgende<\/p>\n<ul>\n<li>een grote STP-diameter van het netwerk, wat kan leiden tot broadcaststorms <\/li>\n<li>STP-root wordt willekeurig bepaald (op basis van mac-adres) en de traffiekroute zal suboptimaal zijn<\/li>\n<li>poorten die zijn aangesloten op hosts, zullen niet zijn ingesteld als edge (portfast), wat zal leiden tot herberekening van STP bij het in- of uitschakelen van eindstations<\/li>\n<li>het netwerk zal niet zijn gesegmenteerd op L1\/L2-niveau, waardoor problemen met een switch (bijvoorbeeld overbelasting van voeding) zullen leiden tot herberekening van de STP-topologie en stopzetting van het verkeer in alle VLAN's op alle switches (inclusief in segmenten die kritiek zijn voor continu\u00efteit van de service)<\/li>\n<\/ul>\n<p><\/p>\n<h4>Voorbeelden van ontwerpfouten op L3-niveau (OSI)<\/h4>\n<p>\nVerschillende kenmerkende fouten van beginnende netwerkbeheerders:<\/p>\n<ul>\n<li>frequent gebruik (of alleen gebruik) van statische routing<\/li>\n<li>gebruik van suboptimale routingprotocollen voor dit ontwerp<\/li>\n<li>suboptimale logische segmentatie van het netwerk<\/li>\n<li>suboptimaal gebruik van adresruimte, waardoor aggregatie van routes niet mogelijk is<\/li>\n<li>afwezigheid van back-uproutes<\/li>\n<li>afwezigheid van redundantie voor de default gateway<\/li>\n<li>asymmetrisch routeren bij herstructurering van routers (kan kritiek zijn in het geval van NAT\/PAT, stateful firewalls)<\/li>\n<li>problemen met MTU<\/li>\n<li>bij het herstructureren van routes gaat het verkeer via andere beveiligingszones of zelfs andere firewalls, wat ertoe leidt dat dit verkeer wordt gedropt<\/li>\n<li>slechte schaalbaarheid van de topologie<\/li>\n<\/ul>\n<p><\/p>\n<h2>Criteria voor de kwaliteitsbeoordeling van het ontwerp<\/h2>\n<p>\nWanneer we het hebben over optimaliteit\/onoptimaliteit, moeten we begrijpen vanuit welk criteria we dit kunnen beoordelen. Vanuit mijn perspectief zijn de meest significante (maar niet alle) criteria (en de uitleg met betrekking tot routingprotocollen):<\/p>\n<ul>\n<li>schaalbaarheid (scalability)<br \/>\n Bijvoorbeeld, als u besluit om een extra datacenter toe te voegen. Hoe gemakkelijk kunt u dit doen?<\/li>\n<li>gebruiksgemak (manageability)<br \/>\n Hoe gemakkelijk en veilig kunnen operationele wijzigingen worden doorgevoerd, zoals het aankondigen van een nieuw netwerk of het filteren van routes<\/li>\n<li>beschikbaarheid (availability)<br \/>\n Wat is het percentage tijd dat uw systeem het vereiste serviceniveau biedt<\/li>\n<li>beveiliging (security)<br \/>\n Hoe veilig zijn de verzonden gegevens<\/li>\n<li>price<\/li>\n<\/ul>\n<p><\/p>\n<h2>Wijzigingen<\/h2>\n<p>\nHet belangrijkste principe in deze fase kan worden samengevat met de formule 'do not harm'.<br \/>\nDaarom, zelfs als u het niet helemaal eens bent met het ontwerp en de gekozen implementatie (configuratie), is het niet altijd zinvol om wijzigingen aan te brengen. Een verstandige aanpak is om alle ge\u00efdentificeerde problemen te rangschikken op basis van twee parameters: <\/p>\n<ul>\n<li>hoe gemakkelijk deze probleem kan worden opgelost<\/li>\n<li>hoe groot het risico is dat het met zich meebrengt<\/li>\n<\/ul>\n<p>\nVoornamelijk moet u alles verhelpen wat op dit moment het niveau van de geboden service onder het toelaatbare niveau brengt, bijvoorbeeld problemen die leiden tot pakketverlies. Verhelp daarna datgene wat het gemakkelijkst en veiligst kan worden opgelost, in volgorde van afnemende ernst van het risico (van problemen in ontwerp of configuratie met grotere risico's naar kleinere).<\/p>\n<p>Perfectionisme kan in deze fase schadelijk zijn. Breng het ontwerp in een bevredigende staat en synchroniseer de netwerkconfiguratie daarmee.<br \/>\n<br \/>Bron: <a content=\"nofollow\" rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/post\/434750\/\">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 \u0432\u0442\u043e\u0440\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. \u041d\u0430\u0448\u0430 \u0446\u0435\u043b\u044c \u043d\u0430 \u0434\u0430\u043d\u043d\u043e\u043c \u044d\u0442\u0430\u043f\u0435 \u2014 \u043d\u0430\u0432\u0435\u0434\u0435\u043d\u0438\u0435 \u043f\u043e\u0440\u044f\u0434\u043a\u0430 \u0432 \u0434\u043e\u043a\u0443\u043c\u0435\u043d\u0442\u0430\u0446\u0438\u0438 \u0438 \u043a\u043e\u043d\u0444\u0438\u0433\u0443\u0440\u0430\u0446\u0438\u0438. \u041d\u0430 \u0432\u044b\u0445\u043e\u0434\u0435 \u044d\u0442\u043e\u0433\u043e \u043f\u0440\u043e\u0446\u0435\u0441\u0441\u0430 \u0443 \u0432\u0430\u0441 \u0434\u043e\u043b\u0436\u0435\u043d \u0431\u044b\u0442\u044c \u043d\u0435\u043e\u0431\u0445\u043e\u0434\u0438\u043c\u044b\u0439 \u043a\u043e\u043c\u043f\u043b\u0435\u043a\u0442 \u0434\u043e\u043a\u0443\u043c\u0435\u043d\u0442\u043e\u0432 \u0438 \u0441\u0435\u0442\u044c, \u0441\u043a\u043e\u043d\u0444\u0438\u0433\u0443\u0440\u0438\u0440\u043e\u0432\u0430\u043d\u043d\u0430\u044f \u0432 \u0441\u043e\u043e\u0442\u0432\u0435\u0442\u0441\u0442\u0432\u0438\u0438 \u0441 \u043d\u0438\u043c\u0438. \u0421\u0435\u0439\u0447\u0430\u0441 \u043c\u044b [&hellip;]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":23042,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-31067","post","type-post","status-publish","format-standard","has-post-thumbnail","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 \u0432\u0442\u043e\u0440\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-vtoraya-chistka-i-dokumentirovanie\" \/>\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 \u0432\u0442\u043e\u0440\u0430\u044f. \u0427\u0438\u0441\u0442\u043a\u0430 \u0438 \u0434\u043e\u043a\u0443\u043c\u0435\u043d\u0442\u0438\u0440\u043e\u0432\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 \u0432\u0442\u043e\u0440\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-vtoraya-chistka-i-dokumentirovanie\" \/>\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 de netwerkinfrastructuur onder controle te krijgen. Hoofdstuk twee. Schoonmaken en documenteren | ProHoster","description":"Dit artikel is de tweede in een reeks artikelen 'Hoe u de netwerkinfrastructuur onder controle krijgt'.","canonical_url":"https:\/\/prohoster.info\/nl\/blog\/administrirovanie\/kak-vzyat-setevuyu-infrastrukturu-pod-svoj-kontrol-glava-vtoraya-chistka-i-dokumentirovanie","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 \u0432\u0442\u043e\u0440\u0430\u044f. \u0427\u0438\u0441\u0442\u043a\u0430 \u0438 \u0434\u043e\u043a\u0443\u043c\u0435\u043d\u0442\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u0435 | ProHoster","og:description":"\u042d\u0442\u0430 \u0441\u0442\u0430\u0442\u044c\u044f \u044f\u0432\u043b\u044f\u0435\u0442\u0441\u044f \u0432\u0442\u043e\u0440\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-vtoraya-chistka-i-dokumentirovanie","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":"31067","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:22: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:22: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\/31067","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=31067"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/posts\/31067\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/media\/23042"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/media?parent=31067"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/categories?post=31067"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/tags?post=31067"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}