Come prendere il controllo dell'infrastruttura di rete. Capitolo due. Pulizia e documentazione

Articolo che è il secondo in un ciclo di articoli su "Come mettere sotto controllo l'infrastruttura di rete". Puoi trovare il contenuto di tutti gli articoli del ciclo e i relativi link. qui.

Il nostro obiettivo in questa fase è riordinare la documentazione e la configurazione.
Alla fine di questo processo, dovresti avere un insieme completo di documenti e una rete configurata di conseguenza.

In questo momento non parleremo dell'audit della sicurezza, a cui sarà dedicata la terza parte.

La difficoltà di eseguire il compito assegnato in questa fase varia di molto da azienda ad azienda.

La situazione ideale è quando

• la tua rete è stata creata secondo il progetto e hai un insieme completo di documenti
• nella tua azienda è stato implementato il processo di controllo e gestione delle modifiche per la rete
• secondo questo processo possiedi documenti (compresi tutti gli schemi necessari) che forniscono informazioni complete sulla situazione attuale

In questo caso, il tuo compito è relativamente semplice. Devi esaminare i documenti e rivedere tutte le modifiche apportate.

Nel peggiore dei casi, avrai

• una rete creata senza progetto, senza piano, senza approvazione, da ingegneri non sufficientemente qualificati,
• con modifiche caotiche, non documentate, con un gran numero di "rifiuti" e soluzioni non ottimali.

È chiaro che la tua situazione è da qualche parte in mezzo, ma purtroppo, su questa scala di meglio - peggio, è molto probabile che tu ti trovi più vicino alla parte peggiore.

In questo caso, sarà necessario anche saper leggere i pensieri, perché dovrai imparare a capire quale fosse l'intento dei "designer", ripristinare la loro logica, completare ciò che non era finito e rimuovere i "rifiuti".
E, naturalmente, dovrai anche correggere i loro errori, modificare (in questa fase il meno possibile) il design e modificare o ricreare gli schemi.

Questo articolo non pretende affatto di essere esaustivo. Qui descriverò solo i principi generali e mi fermerò su alcuni problemi comuni che spesso si presentano.

Insieme di documenti

Iniziamo con un esempio.

Di seguito sono riportati alcuni documenti che è consuetudine creare in Cisco Systems durante la progettazione.

CR – Requisiti del Cliente, requisiti del cliente (specifiche tecniche).
Creato congiuntamente al cliente, definisce i requisiti per la rete.

HLD – High Level Design, design di alto livello basato sui requisiti della rete (CR). Il documento spiega e giustifica le decisioni architettoniche adottate (topologia, protocolli, scelta dell'hardware,…). L'HLD non contiene dettagli di design, come interfacce utilizzate e indirizzi IP. Inoltre, non si discute la configurazione specifica dell'hardware. Questo documento è più mirato a spiegare al management tecnico del cliente i concetti chiave del design.

LLD – Low Level Design, design di basso livello basato sull'HLD.
Deve contenere tutti i dettagli necessari per l'implementazione del progetto, come le informazioni su come connettere e configurare l'hardware. È una guida completa per l'implementazione del design. Questo documento deve fornire informazioni sufficienti per la sua attuazione anche da parte di personale non altamente qualificato.

Qualcosa, come indirizzi IP, numeri AS, schema di cablaggio fisico, può essere "separato" in documenti distinti, come NIP (Network Implementation Plan).

La costruzione della rete inizia dopo la creazione di questi documenti e avviene in stretto accordo con essi, e poi viene verificata dal cliente (test) per conformità al design.

Certo, i requisiti per la documentazione progettuale possono variare tra diversi integratori, clienti e paesi. Ma si vorrebbe evitare formalità e affrontare la questione nel merito. Questa fase non riguarda la progettazione, ma l'ordinamento e abbiamo bisogno di un insieme sufficiente di documenti (schemi, tabelle, descrizioni …) per svolgere i nostri compiti.

E, a mio parere, esiste una sorta di minimo assoluto senza il quale non è possibile controllare la rete in modo efficace.

Questi sono i seguenti documenti:

• schema (registro) di cablaggio fisico
• schema o schemi di rete con informazioni sostanziali L2/L3

Schema di cablaggio fisico

In alcune piccole aziende, i lavori relativi all'installazione dell'hardware e al cablaggio fisico sono sotto la responsabilità degli ingegneri di rete.

In questo caso, il problema viene in parte risolto tramite il seguente approccio.

• usa la descrizione sull'interfaccia per descrivere a cosa è collegata
• disattivate amministrativamente (shutdown) tutte le porte non collegate dell'apparecchiatura di rete

Questo ti permetterà, anche in caso di problemi con il link (quando su questa interfaccia non funzionano cdp o lldp), di identificare rapidamente cosa è collegato a questa porta.
Inoltre, potrai facilmente vedere quali porte sono occupate e quali sono libere, il che è necessario per pianificare le connessioni di nuova apparecchiatura di rete, server o workstation.

Ma è chiaro che se perdi l'accesso all'attrezzatura, perderai anche l'accesso a queste informazioni. Inoltre, in questo modo non potrai registrare informazioni così importanti come che tipo di apparecchiatura, con quale potenza assorbita, quanti porti ha, in quale rack si trova, quali patch panel sono lì e a quale rack/panel sono cablati. Pertanto, è comunque molto utile documentare in modo aggiuntivo (non solo le descrizioni sull'attrezzatura).

L'opzione ideale è utilizzare applicazioni create per gestire questo tipo di informazioni. Ma è possibile anche limitarsi a semplici tabelle (ad esempio, in Excel) o visualizzare le informazioni che ritieni necessarie negli schemi L1/L2.

Importante!

Un ingegnere di rete, ovviamente, può conoscere abbastanza bene le sottigliezze e gli standard della cablatura strutturata, i tipi di rack, i tipi di gruppi di continuità, cosa sono i corridoi freddi e caldi, fare una messa a terra corretta,… proprio come in linea di principio può conoscere la fisica delle particelle elementari o C++. Ma bisogna comunque comprendere che tutto ciò non rientra nelle sue competenze.

Pertanto, è una buona pratica avere o reparti dedicati o persone dedicate per risolvere le attività legate all'installazione, collegamento, supporto del funzionamento dell'attrezzatura e anche cablaggio fisico. Di solito, per i data center, questi sono ingegneri del centro dati, mentre per gli uffici — help-desk.

Se sono previsti tali reparti nella tua azienda, le questioni relative alla registrazione del cablaggio fisico non sono un tuo compito, e puoi limitarti solo alla descrizione sull'interfaccia e alla disattivazione amministrativa delle porte non utilizzate.

Schemi di rete

Non esiste un approccio universale per disegnare schemi.

La cosa più importante è che gli schemi devono fornire una comprensione di come si muoverà il traffico, attraverso quali elementi logici e fisici della vostra rete.

Per elementi fisici intendiamo

• apparecchiature attive
• interfacce/porte delle apparecchiature attive

Per logici intendiamo

• dispositivi logici (N7K VDC, Palo Alto VSYS, …)
• VRF
• VLAN
• sottoreti
• tunnel
• zone
• …

Inoltre, se la vostra rete non è del tutto elementare, sarà composta da vari segmenti.
Ad esempio

• data center
• internet
• WAN
• accesso remoto
• LAN dell'ufficio
• DMZ
• …

Sarebbe ragionevole avere diversi schemi, che diano sia una visione generale (di come si muove il traffico tra tutti questi segmenti), sia una spiegazione dettagliata di ogni singolo segmento.

Poiché nelle reti moderne possono esserci molti livelli logici, potrebbe essere un buon (ma non obbligatorio) approccio realizzare diversi schemi per i vari livelli, per esempio, nel caso dell'approccio overlay, potrebbero essere i seguenti schemi:

• overlay
• L1/L2 underlay
• L3 underlay

Naturalmente, lo schema più importante, senza il quale non è possibile comprendere l'idea del vostro design, è lo schema di instradamento.

Schema di instradamento

Al minimo, in questo schema devono essere riflessi

• quali protocolli di instradamento e dove vengono utilizzati
• informazioni fondamentali sulle impostazioni del protocollo di instradamento (area/numero AS/router-id/…)
• su quali dispositivi avviene la redistribuzione
• dove avviene la filtrazione e l'aggregazione delle rotte
• informazioni sulla rotta predefinita

Inoltre, spesso è utile avere uno schema L2 (OSI).

Schema L2 (OSI)

In questo schema possono essere riflessi le seguenti informazioni:

• quali VLAN
• quali porte sono porte trunk
• quali porte sono aggregate in ether-channel (port channel), virtual port channel
• quali protocolli STP e su quali dispositivi vengono utilizzati
• impostazioni principali di STP: root/root backup, costo STP, priorità della porta
• impostazioni aggiuntive di STP: BPDU guard/filter, root guard…

Errori caratteristici nella progettazione

Esempio di un cattivo approccio alla costruzione di una rete.

Prendiamo un semplice esempio di costruzione di una rete locale per uffici.

Avendo esperienza nell'insegnamento delle telecomunicazioni agli studenti, posso dire che praticamente ogni studente, a metà del secondo semestre, possiede le conoscenze necessarie (nel quadro del corso che ho tenuto) per configurare una semplice LAN per uffici.

Cosa c'è di difficile nel collegare insieme gli switch, configurare VLAN, interfacce SVI (nel caso di switch L3) e scrivere un routing statico?

Tutto funziona.

Ma restano aperte domande legate a

• sicurezza.
• riservatezza
• scalabilità della rete
• prestazioni
• larghezza di banda
• affidabilità.
• …

A volte sento affermare che una LAN per ufficio sia qualcosa di molto semplice e sento questo solitamente da ingegneri (e manager) che si occupano di qualsiasi cosa tranne delle reti, e lo affermano con tale sicurezza che non sorprendetevi se la LAN sarà realizzata da persone con scarsa esperienza e conoscenze, commettendo approssimativamente gli stessi errori che descriverò tra poco.

Errori caratteristici nella progettazione di livello L1 (OSI)

• Se siete comunque responsabili anche per il cablaggio strutturato, uno dei lasciti più sgradevoli che potreste ricevere è una cablatura disordinata e non ben progettata.

Inoltre, attribuirei al tipo L1 errori legati alle risorse dell'hardware utilizzato, ad esempio,

• larghezza di banda insufficiente
• insufficiente TCAM sull'hardware (o un utilizzo inefficace)
• scarsa performance (spesso rispetto ai firewall)

Errori caratteristici nella progettazione di livello L2 (OSI)

Spesso, quando non c'è una buona comprensione di come funzioni STP, quali potenziali problemi possa comportare, gli switch sono collegati in modo caotico, con impostazioni di default, senza alcuna messa a punto di STP.

Di conseguenza, spesso abbiamo quanto segue

• un grande diametro STP della rete, il che può portare a tempeste di broadcast
• la radice STP verrà definita casualmente (sulla base dell'indirizzo MAC) e il percorso del traffico sarà subottimale
• le porte collegate agli host non saranno configurate come edge (portfast), il che porterà al ricalcolo di STP quando si accendono/spengono i dispositivi finali
• la rete non sarà segmentata a livello di L1/L2, con il risultato che problemi con qualsiasi switch (ad esempio, sovraccarico di alimentazione) porteranno al ricalcolo della topologia STP e all'interruzione del traffico in tutte le VLAN su tutti gli switch (incluso il segmento critico per la continuità del servizio)

Esempi di errori nella progettazione L3 (OSI)

Alcuni errori caratteristici dei neofiti delle reti:

• uso frequente (o uso esclusivo) di routing statico
• uso di protocolli di routing non ottimali per questo design
• segmentazione logica non ottimale della rete
• uso non ottimale dello spazio indirizzamento, che non consente l'aggregazione delle rotte
• assenza di rotte di backup
• assenza di riserva per il gateway predefinito
• routing asimmetrico durante la ristrutturazione delle rotte (può essere critico nel caso di NAT/PAT, firewall stateful)
• problemi con l'MTU
• durante la ristrutturazione delle rotte, il traffico passa attraverso altre aree di sicurezza o addirittura altri firewall, il che porta a un drop di quel traffico
• scarsa scalabilità della topologia

Criteri di valutazione della qualità del design

Quando parliamo di ottimalità/non ottimalità, dobbiamo comprendere secondo quali criteri possiamo valutare questo. Dal mio punto di vista, i criteri più significativi (ma non tutti) sono (e la loro spiegazione applicata ai protocolli di routing):

• scalabilità (scalabilità)
  Ad esempio, se decidete di aggiungere un altro data center. Quanto è facile farlo?
• facilità di gestione (gestibilità)
  Quanto è facile e sicuro effettuare cambiamenti operativi, come l'annuncio di un nuovo network o la filtrazione delle rotte
• disponibilità (disponibilità)
  Quale percentuale di tempo il vostro sistema fornisce il livello di servizio richiesto
• sicurezza (sicurezza)
  Quanto sono protetti i dati trasferiti
• il prezzo

Modifiche

Il principio fondamentale in questa fase può essere riassunto nella formula "non nuocere".
Pertanto, anche se non siete completamente d'accordo con il design e l'implementazione scelta (configurazione), non sempre è opportuno apportare modifiche. Un approccio razionale è quello di classificare tutti i problemi identificati in base a due parametri:

• quanto sia facile risolvere questo problema
• quanto sia elevato il rischio che comporta

In primo luogo, è necessario risolvere ciò che attualmente abbassa il livello di servizio al di sotto del limite consentito, ad esempio problemi che portano a perdite di pacchetti. Successivamente, affrontate ciò che è più facile e più sicuro risolvere in ordine decrescente di gravità del rischio (da problemi di design o configurazione che comportano rischi maggiori verso rischi minori).

Il perfezionismo in questa fase può essere dannoso. Portate il design a uno stato soddisfacente e sincronizzate la configurazione della rete di conseguenza.

Fonte: habr.com