Il modo migliore per segmentare traffico, VLAN o sottorete?


13

Disponiamo di una rete di medie dimensioni di circa 200 nodi e attualmente stiamo sostituendo i vecchi switch concatenati con switch in grado di impilare o in stile chassis.

Al momento, la nostra rete è suddivisa in sottoreti: produzione, gestione, proprietà intellettuale (IP), ecc., Ciascuna su una sottorete separata. La creazione di VLAN anziché di sottoreti sarebbe più vantaggiosa?

Il nostro obiettivo generale è prevenire colli di bottiglia, separare il traffico per motivi di sicurezza e gestire il traffico con maggiore facilità.


1
probabilmente i tuoi diversi Vlan verranno utilizzati per avere sottoreti separate.
pQd

1
Potresti trovare la risposta di Evan a questa domanda che ho fatto qualche tempo fa utile: serverfault.com/questions/25907/…
Kyle Brandt

Risposte:


16

VLAN e subnet risolvono diversi problemi. Le VLAN funzionano al livello 2 , alterando così i domini di trasmissione (ad esempio). Considerando che le sottoreti sono livello 3 nel contesto attuale

Un suggerimento sarebbe quello di implementare entrambi

Possiedi, ad esempio, VLAN 10-15 per i tuoi diversi tipi di dispositivi (Dev, Test, Produzione, Utenti, ecc.)

VLAN 10, potresti avere la sottorete 192.168.54.x / 24 VLAN 11, potresti avere la sottorete 192.168.55.x / 24

E così via

Ciò richiederebbe che tu abbia un router all'interno della tua rete

Dipende da te quale percorso segui (conosci la tua rete meglio di quanto io abbia mai fatto). Se ritieni che la dimensione del tuo dominio di trasmissione costituirà una sorta di problema, utilizza le VLAN. Se ritieni che la dimensione dei tuoi domini di gestione della rete (ad esempio, la tua rete di gestione), probabilmente utilizza una rete più vicina a un / 16 su un / 24

I tuoi 200 nodi si adatteranno in un / 24, ma questo ovviamente non ti dà molto spazio per la crescita

A quanto pare, stai già utilizzando diverse sottoreti per diversi tipi di dispositivi. Quindi, perché non restare con quello? Se lo si desidera, è possibile collegare ciascuna sottorete a una VLAN. La segmentazione di livello 2 comporterà il cambiamento del comportamento della tua rete rispetto a come si comporta attualmente

Dovresti indagare sul potenziale impatto di ciò


2
+1 - Ha detto quasi tutto quello che volevo. Se avessi intenzione di eliminare l'attuale progetto di subnet che hai, il mio unico suggerimento aggiuntivo sarebbe quello di esplorare la configurazione di uno spazio di indirizzi usando un / 22 o / 23. Forse "rimuovi" i bit se ritieni di aver bisogno di più sottoreti. Dopotutto, non siamo più limitati a / 16 o / 24. Quindi, inserire ciascuna subnet nella propria VLAN per ridurre il traffico di trasmissione.
Romandia,

13

(Sono stato in viaggio tutto il giorno e mi sono perso saltando su questo ... Eppure, in ritardo al gioco vedrò cosa posso fare.)

Generalmente si creano VLAN in Ethernet e si mappano le sottoreti IP da 1 a 1 su di esse. Ci sono modi per non farlo, ma restando fedeli a un mondo strettamente "semplice", si creerebbe una VLAN, si potrebbe pensare a una sottorete IP da utilizzare nella VLAN, assegnare a un router un indirizzo IP in quella VLAN, collegare quel router a la VLAN (con un'interfaccia fisica o un'interfaccia virtuale virtuale sul router), connette alcuni host alla VLAN e assegna loro gli indirizzi IP nella sottorete che hai definito, e instrada il loro traffico dentro e fuori dalla VLAN.

Non dovresti iniziare a subnetting di una LAN Ethernet a meno che tu non abbia buoni motivi per farlo. I due motivi migliori sono:

  • Mitigare i problemi di prestazioni. Le LAN Ethernet non possono ridimensionarsi indefinitamente. Trasmissioni eccessive o allagamenti di frame verso destinazioni sconosciute ne limitano la portata. Entrambe queste condizioni possono essere causate dal fatto di rendere un singolo dominio di trasmissione in una LAN Ethernet troppo grande. Il traffico di trasmissione è facile da capire, ma l'inondazione di frame verso destinazioni sconosciute è un po 'più oscuro. Se disponi di così tanti dispositivi che le tue tabelle MAC dello switch sono straripanti, gli switch saranno costretti a inondare i frame non broadcast fuori da tutte le porte se la destinazione del frame non corrisponde a nessuna voce della tabella MAC. Se disponi di un dominio di trasmissione singolo sufficientemente grande in una LAN Ethernet con un profilo di traffico che ospita gli host, parla di rado (ovvero

  • Il desiderio di limitare / controllare il traffico in movimento tra host a livello 3 o superiore. Puoi fare un po 'di pirateria informatica esaminando il traffico al livello 2 (ala Linux ebtables) ma questo è difficile da gestire (perché le regole sono legate agli indirizzi MAC e la modifica delle schede di rete richiede modifiche alle regole) può causare comportamenti che sembrano davvero strani il proxy trasparente di HTTP a livello 2, ad esempio, è strano e divertente, ma è assolutamente non naturale e può essere molto intuitivo per la risoluzione dei problemi), ed è generalmente difficile da eseguire a livelli inferiori (perché gli strumenti di livello 2 sono come stick e rocce nel gestire le preoccupazioni di livello 3+). Se si desidera controllare il traffico IP (o TCP, o UDP, ecc.) Tra host, anziché attaccare il problema al livello 2, è necessario eseguire la subnet e attaccare firewall / router con ACL tra le sottoreti.

I problemi di esaurimento della larghezza di banda (a meno che non siano causati da pacchetti di trasmissione o inondazioni di frame) non vengono risolti con VLAN e sottoreti in genere. Si verificano a causa della mancanza di connettività fisica (troppo poche schede di rete su un server, troppo poche porte in un gruppo di aggregazione, necessità di passare a una velocità di porta più veloce) e non possono essere risolte eseguendo la subnet o la distribuzione di VLAN dal momento che ha vinto aumenta la quantità di larghezza di banda disponibile.

Se non hai nemmeno qualcosa di semplice come MRTG che esegue la rappresentazione grafica delle statistiche del traffico per porta sui tuoi switch, questo è davvero il tuo primo ordine di attività prima di iniziare a introdurre potenziali colli di bottiglia con sottoreti intenzionali ma non informate. Il conteggio dei byte non elaborati è un buon inizio, ma dovresti seguirlo con uno sniffing mirato per ottenere maggiori dettagli sui profili di traffico.

Una volta che sai come si sposta il traffico sulla tua LAN, puoi iniziare a pensare alla sottorete per motivi di prestazioni.

Per quanto riguarda la "sicurezza", dovrai sapere molto sul tuo software applicativo e su come parla prima di poter procedere.

Ho fatto un progetto per una LAN / WAN di dimensioni ragionevoli per un cliente medico alcuni anni fa e mi è stato chiesto di mettere elenchi di accesso sull'entità di livello 3 (un modulo supervisore Cisco Catalyst 6509) per controllare il traffico che si sposta tra le sottoreti da un " ingegnere "che aveva poca conoscenza di quale tipo di legwork avrebbe effettivamente richiesto ma era molto interessato alla" sicurezza ". Quando sono tornato con una proposta di studio di ciascuna applicazione per determinare le porte TCP / UDP e gli host di destinazione necessari, ho ricevuto una risposta scioccata dall'ingegnere affermando che non dovrebbe essere così difficile. L'ultima volta che ho sentito che eseguono l'entità layer 3 senza elenchi di accesso perché non sono stati in grado di far funzionare in modo affidabile tutto il loro software.

La morale: se hai davvero intenzione di provare a abbattere pacchetti e accesso a livello di flusso tra VLAN, preparati a fare un sacco di legwork con il software applicativo e l'apprendimento / reverse engineering su come dialoga in rete. Limitare l'accesso degli host ai server può essere spesso realizzato con funzionalità di filtro sui server. Limitare l'accesso sul filo può fornire un falso senso di sicurezza e gli amministratori indolenti in un compiacimento in cui pensano "Beh, non ho bisogno di configurare l'app. In modo sicuro perché gli host che possono parlare con l'app sono limitati da" Rete'." Ti incoraggio a controllare la sicurezza della configurazione del tuo server prima di iniziare a limitare la comunicazione da host a host sulla rete.


2
sono contento di vedere qualche voce della ragione dopo le risposte che consigliano di andare / 16.
pQd

4
È possibile eseguire la sottorete in sottoreti arbitrariamente grandi o piccole. Il numero di host nel dominio subnet / broadcast è ciò che conta, non il numero di host possibili (purché si disponga di spazio sufficiente per gli indirizzi). Qual è l'espressione: non è la dimensione della tua sottorete che conta, ma piuttosto come la usi? > smile <
Evan Anderson

@Evan Anderson: lo so. ma devi ammettere che 64k è troppo, probabilmente non verrà mai utilizzato e può portare a problemi quando è necessario introdurre il routing [ad esempio per connettere DC / uffici / ecc. remoti].
pQd

1

Il 99% delle volte, una sottorete dovrebbe essere equivalente a una VLAN (ovvero ogni sottorete di accesso deve essere mappata su una e una sola VLAN).

Se si hanno host da più di una sottorete IP nella stessa VLAN, si vanifica lo scopo delle VLAN, poiché le due (o più) sottoreti saranno sullo stesso dominio di trasmissione.

In alternativa, se si inserisce una sottorete IP in più VLAN, gli host della sottorete IP non saranno in grado di comunicare con gli host nell'altra VLAN a meno che sul router non sia abilitato l' ARP proxy .


-1 - Le VLAN suddividono i domini broadcast. I domini di collisione sono suddivisi da bridge o bridge multiporta più comunemente noti come switch. Le sottoreti IP e i domini di trasmissione / collisione non hanno nulla a che fare l'uno con l'altro nel caso generale. Nel caso specifico dell'IP su Ethernet è comune che una sottorete IP sia mappata su un singolo dominio di trasmissione (poiché ARP, il protocollo utilizzato per risolvere gli indirizzi IP su indirizzi hardware Ethernet è basato sulla trasmissione), ma è possibile usare un trucco intelligente con il proxy ARP per avere una sottorete su più domini di trasmissione.
Evan Anderson,

@Evan: buon punto - questo mi insegnerà a scrivere le risposte nelle prime ore del mattino. :) Però resto con i punti rimanenti; avere più sottoreti nella stessa VLAN farà sì che il tuo traffico di trasmissione L2 si estenda su più sottoreti; avere più VLAN per la stessa sottorete funzionerà, ma l'ARP proxy non è davvero qualcosa che dovresti usare se puoi evitarlo.
Murali Suriar,

-1 rimosso - Tutto il resto che hai detto è sicuramente accurato. Concordo anche con re: proxy ARP-- Non lo userei nel "mondo reale" se non avessi qualche motivo convincente molto forte.
Evan Anderson,

"Le sottoreti IP e i domini di trasmissione / collisione non hanno nulla a che fare l'uno con l'altro nel caso generale." No, certamente lo fanno nel caso generale. Ogni sottorete ha un numero di rete e un indirizzo di trasmissione associato. Oltre a ARP, hai altri pacchetti di trasmissione. Sarebbe sbagliato fare questa affermazione non sapendo se hanno traffico multicast sulla loro rete. I client DHCP utilizzano la trasmissione IP per conoscere i server DHCP.
Kilo,

1
@Evan Anderson Cosa mi sono perso qui. Ritiri il tuo -1. I domini di collisione vengono riversati dalle porte degli switch. Dire 2 o sottoreti in un dominio di collisione non ha senso. Penso che significhi 2 o più sottoreti in un dominio di trasmissione .
JamesBarnett,

-5

Sono principalmente d'accordo con David Pashley :

  1. Uso un singolo / 16 per tutto.
    • ma è segmentato su diverse VLAN, unite da un bridge software su una macchina Linux.
    • su questo bridge, ho diverse regole iptables per filtrare l'accesso tra i gruppi.
    • non importa come segmentare, utilizzare gli intervalli IP per il raggruppamento, facilita la ristrutturazione e casi speciali.

2
Sembra un incubo da affrontare!
Evan Anderson,

2
-1 Non hai detto quanto sia grande la rete che gestisci, a meno che tu non stia parlando di un progetto di ricerca, non posso per tutta la vita pensare a un motivo per usare quel tipo di configurazione. Per definizione le sottoreti sono "intervalli IP" utilizzati per il raggruppamento. Sembra che tu stia reinventando il layer 3 usando una casella Linux per eseguire il routing al layer 2. È probabile che crei problemi nascosti dalla complessità non necessaria. Questo crea qualcosa che sarà difficile da risolvere per chiunque altro e tanto meno da risolvere.
Rik Schneider,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.