Routing tra VLAN

gandalf.co...@gmail.com

unread,

Apr 26, 2012, 4:08:39 PM4/26/12

to

Supponiamo di avere alcuni server con vlan dedicate:
vlan1, vlan2, vlan3, vlan4, etc etc

Supponiamo anche di avere un server che deve essere visto da tutti gli altri.
La soluzione più rapida sarebbe quella di mettere in trunk la porta verso il server 'comune' ed associare al server un IP per ciascuna VLAN di origine.

Non voglio farlo, diventerebbe una situazione ingestibile al crescere delle VLAN ed un inutile spreco di IP.

Pensavo quindi di attivare il routing sullo switch (ne posso rimediare uno L3) e ruotare tutto il traffico tra le VLAN.
Soluzione poco ottimale, in quanto le VLAN dei singoli server non devono dialogare tra loro, ma solo verso il server comune.

Devo agire obbligatoriamente di ACL, ovvero attivare il routing tra tutto e tutti e poi filtrare tramite qualche ACL oppure si può attivare solo il routing verso un dato server o meglio ancora una data vlan?

Il top del top, nel mio caso, sarebbe fare una cosa di sto tipo:

- attivare routing
- ruotare traffico da/verso la VLAN 101
- ruotare traffico da/verso la VLAN 102
- drop di tutto il resto

in questo modo, posso aggiungere vlan senza preoccuparmi di modificare il routing, in quanto automaticamente ruoterebbero il traffico verso la 101 e la 102 e verrebbero droppate tra di loro.

Si può fare? Avete un esempio supponendo un Cisco come switch (o addirittura un Extreme, ho un cliente che sembra ne dismetta uno recente)?

writethem

unread,

Apr 27, 2012, 2:41:38 AM4/27/12

to

> Supponiamo anche di avere un server che deve essere visto da tutti
gli altri.
> La soluzione più rapida sarebbe quella di mettere in trunk la porta
verso il server 'comune' ed associare al server un IP per ciascuna VLAN
di origine.
>
> Non voglio farlo, diventerebbe una situazione ingestibile al crescere
delle VLAN ed un inutile spreco di IP.

Però anche la soluzione più pulita. Fai arrivare al server i tag, dai un
ip per ogni vlan e DISABILITI il forwarding tra le reti (errore comune e
che espone la rete ad evidenti vulnerabilità). Non lo vedo affatto come
un "accrocchio", anzi..

>
> Devo agire obbligatoriamente di ACL, ovvero attivare il routing tra
tutto e tutti e poi filtrare tramite qualche ACL oppure si può attivare
solo il routing verso un dato server o meglio ancora una data vlan?

puoi anche fare così, ma sei sicuro che questa non sia la strada più
farraginosa? se hai un firewall potrebbe anche andar bene, centralizzi
il routing e le policy su di esso, ma far fare routing+ACL sullo switch
solo per abilitare un server potrebbe farti perdere di gestibilità.

Ovviamente è un parere del tutto personale, ci sono varie scuole di
pensiero, io preferisco spostare il L3 su di un firewall oppure, se non
ne possiedo uno, mando i tag delle vlan sul server. Lo trovo più pulito
e più "error-free".
Ovviamente ci sono situazioni in cui lo puoi fare ed altre in cui non
puoi farlo. In questo caso non ci vedo grandi controindicazioni.

gandalf.co...@gmail.com

unread,

Apr 27, 2012, 10:30:57 AM4/27/12

to

Il giorno venerdì 27 aprile 2012 08:41:38 UTC+2, writethem ha scritto:
> Però anche la soluzione più pulita. Fai arrivare al server i tag, dai un
> ip per ogni vlan e DISABILITI il forwarding tra le reti (errore comune e
> che espone la rete ad evidenti vulnerabilità). Non lo vedo affatto come
> un "accrocchio", anzi..

Supponiamo di avere 700 VLAN.
Il server dovrebbe avere in carico 700 VLAN e 700 IP.
Se queste VLAN sono semplici punto-punto o comunque sia mini-subnet allocate ai clienti, dovrei allargarle tutte per consentire il raggiungimento del server.

> puoi anche fare così, ma sei sicuro che questa non sia la strada più
> farraginosa? se hai un firewall potrebbe anche andar bene, centralizzi
> il routing e le policy su di esso, ma far fare routing+ACL sullo switch
> solo per abilitare un server potrebbe farti perdere di gestibilità.

Infatti pensavo di aggiungere un firewall dedicato. Mi da più sicurezza e maggiore espandibilità.

Però, la questione IP non cambierebbe, il firewall dovrebbe essere presente su ogni VLAN e conseguentemente presente con ogni IP in ciascuna di esse.

> Ovviamente è un parere del tutto personale, ci sono varie scuole di
> pensiero, io preferisco spostare il L3 su di un firewall

Si, anche io.

Vorrei però evitare di dover configurare centinaia di IP (ho vagonate di VLAN, molte delle quali attivate anche solo per alcune ore) su una singola macchina.
Troppo brigoso in termini di lavoro, per questo chiedevo se fosse possibile bloccare di default il routing inter-vlan e lasciarlo solo verso una data destinazione.

No, le PVLAN non vanno bene, mi pare siano proprietarie cisco e la rete in questione non è interamente cisco.

Daniele Orlandi

unread,

Apr 27, 2012, 10:43:09 AM4/27/12

to

gandalf.co...@gmail.com wrote:
>
> Vorrei però evitare di dover configurare centinaia di IP (ho vagonate di
> VLAN, molte delle quali attivate anche solo per alcune ore) su una singola
> macchina.

Gli script sono fatti apposta, io ho server con centinaia di IP e non ci
sono problemi.

--
Daniele "Vihai" Orlandi
Bieco Illuminista #184213

gandalf.co...@gmail.com

unread,

Apr 27, 2012, 11:24:16 AM4/27/12

to

Il giorno venerdì 27 aprile 2012 16:43:09 UTC+2, Daniele Orlandi ha scritto:
> Gli script sono fatti apposta, io ho server con centinaia di IP e non ci
> sono problemi.

Avrei preferito evitare.
Non tanto per dover riconfigurare il server in automatico, ma per dover riconfigurare gli apparati di rete.

Comunque mi pare di capire che la soluzione migliore di quella di mettere il firewall in ascolto su ciascuna vlan, zero routing sullo switch e poi ruotare tutto direttamente dal firewall (i server che devono essere 'visti' dalle vlan sono molteplici, quindi un firewall è d'obbligo altrimenti dovrei usare un ip per ciascun server comune in ciascuna vlan)

writethem

unread,

Apr 27, 2012, 11:22:53 AM4/27/12

to

> Supponiamo di avere 700 VLAN.
> Il server dovrebbe avere in carico 700 VLAN e 700 IP.

Se faccio arrivare 700 VLAN su di un server io inizierei a domandarmi se
non ho sbagliato qualcosa nell'architettura della rete e/o nella
gestione delle risorse.

Concorderai con me che non è proprio un best practices :)

Ma toglimi una curiosutà, tu hai mai visto più di 40-50 vlan in una
stessa rete? Se si, erano davvero tutte giustificate o era frutto di un
attacco di vulannite acuta cronica?

Skull

unread,

Apr 27, 2012, 12:44:59 PM4/27/12

to

On 4/27/12 5:22 PM, writethem wrote:

> Ma toglimi una curiosutà, tu hai mai visto più di 40-50 vlan in una
> stessa rete? Se si, erano davvero tutte giustificate o era frutto di un
> attacco di vulannite acuta cronica?

Tutto dipende da cosa fai di mestiere. Se sei un fornitore di colocation
700 subnet non son poi un numero così spaziale.

Ciò detto, bisogna capire quale è il senso della necessità. Se si tratta
di una vlan dedicata al backup, di solito la soluzione è una nic
dedicata e una private vlan...

gandalf.co...@gmail.com

unread,

Apr 27, 2012, 6:09:23 PM4/27/12

to

Il giorno venerdì 27 aprile 2012 17:22:53 UTC+2, writethem ha scritto:
> Se faccio arrivare 700 VLAN su di un server io inizierei a domandarmi se
> non ho sbagliato qualcosa nell'architettura della rete e/o nella
> gestione delle risorse.
>
> Concorderai con me che non è proprio un best practices :)

A di, mica l'ho fatto io, devo solo prendere in mano una rete già esistente.

> Ma toglimi una curiosutà, tu hai mai visto più di 40-50 vlan in una
> stessa rete? Se si, erano davvero tutte giustificate o era frutto di un
> attacco di vulannite acuta cronica?

Si, io ne ho almeno il quadruplo, con le VPS avere trilioni di VLAN è semplice.
Ma nel mio caso è diverso, tutte le vlan terminano sul firewall e da li escono su internet, anche perchè non avrei altre possibilità.
Se vuoi far navigare 200 VLAN o fai così o non fai.

gandalf.co...@gmail.com

unread,

Apr 27, 2012, 6:06:01 PM4/27/12

to

Il giorno venerdì 27 aprile 2012 18:44:59 UTC+2, Skull ha scritto:
> Tutto dipende da cosa fai di mestiere. Se sei un fornitore di colocation
> 700 subnet non son poi un numero così spaziale.

La rete non è mia , ma di un cliente con dei laboratori, alcune sale corsi ed altre cose.

Attualmente ci sono circa 100 VLAN che non devono dialogare tra loro,
corrispondenti a ciascun computer dei vari laboratori. Non chiedetemi il
perchè, ma così è e così il cliente vuole.

> Ciò detto, bisogna capire quale è il senso della necessità. Se si tratta
> di una vlan dedicata al backup, di solito la soluzione è una nic
> dedicata e una private vlan...

Questi 'computer' devono dialogare con una manciata (per ora) di server, tra cui un backup, due resolver dns ed uno storage NFS

Pensavo quindi di mantenere le vlan sugli apparati senza farle dialogare (quindi L2 e basta), mettere il port-channel che guarda il firewall in trunk e veicolare li sopra tutte le VLAN.

Il firewall sarà accessibile da ciascuna VLAN e l'unica regola di forward
(sarà una macchina linux) è da/verso il port-channel che guarda lo switch dei server comuni:

|----LAN--------------|------DMZ---------|
lab --> sw --> po -> fw -> po -> sw -> srv

Spero si veda il disegnino.
(lab=laboratorio,sw=switch,po=portchannel,fw=firewall,srv=server)

Lato DMZ il problema non sussiste in quanto tutti i server sono dentro la stessa vlan
e comunque sia, sarebbero talmente pochi che anche una eventuale segregazione non comporterebbe
alcun problema.

Il problema è lato LAN, dove ho centinaia di VLAN da dover gestire in più punti e prevedo un
bagno di sangue.

(ovviamente non c'è un solo switch lato LAN ma ci son 3 switch 48 porte connessi ad un distributore ed è quest'ultimo che sarà connesso al firewall)

P.S: no, non ho alcuna intenzione di cambiare la rete fatta da altri. Io devo portare eventuale firewall e server da connettere a questo guazzabuglio di VLAN

avrei preferito attivare il routing sullo switch e bloccare, in qualche modo, il traffico da li sopra senza stare ad impazzire nel portare un firewall e doverlo configurare.

THe_ZiPMaN

unread,

May 2, 2012, 3:03:03 PM5/2/12

to

On 04/28/2012 12:06 AM, gandalf.co...@gmail.com wrote:
> La rete non è mia , ma di un cliente con dei laboratori, alcune sale corsi ed altre cose.
>
> Attualmente ci sono circa 100 VLAN che non devono dialogare tra loro,
> corrispondenti a ciascun computer dei vari laboratori. Non chiedetemi il
> perchè, ma così è e così il cliente vuole.

Il perché te lo dico io... perché la rete l'ha fatta un incompetente.

> Il firewall sarà accessibile da ciascuna VLAN e l'unica regola di forward
> (sarà una macchina linux) è da/verso il port-channel che guarda lo switch dei server comuni:

Sì, ci sta...

> Il problema è lato LAN, dove ho centinaia di VLAN da dover gestire in più punti e prevedo un
> bagno di sangue.

Script.

> (ovviamente non c'è un solo switch lato LAN ma ci son 3 switch 48 porte connessi ad un
> distributore ed è quest'ultimo che sarà connesso al firewall)

Ma questi 4 switch sono tutti cisco? Se sì allora vai di PVLAN.

> P.S: no, non ho alcuna intenzione di cambiare la rete fatta da altri. Io devo portare
> eventuale firewall e server da connettere a questo guazzabuglio di VLAN

Lavorare nella merda è un buon modo per sporcarsi.

> avrei preferito attivare il routing sullo switch e bloccare, in qualche modo, il
> traffico da li sopra senza stare ad impazzire nel portare un firewall e doverlo configurare.

E' fattibile semplicemente anche questo, ma è certamente più palloso
configurare uno switch con 200 ip che non scriptare un server Linux.
Anyway se si tratta di un Cisco tipo 3560 o 3750 non è poi difficile
gestire la cosa. Fai una singola ip acl scritta bene e la applichi a
tutte le *porte* cui sono connessi i PC. L'acl sulla porta funziona a
prescindere dalla VLAN, quindi non devi sbatterti a fare 200 acl dedicate.

Se p.es. la DMZ ha classe IP 192.168.0.0/24 e le altre vlan sono
sottoreti /30 della 10.10.0.0/16 una cosa di questo tipo:

ip access-list extended FILTRAPORTA
permit icmp 10.10.0.0 0.0.255.255 192.168.0.0 0.0.0.255
permit tcp 10.10.0.0 0.0.255.255 host 192.168.0.1 eq 53
permit udp 10.10.0.0 0.0.255.255 host 192.168.0.1 eq 53
permit tcp 10.10.0.0 0.0.255.255 host 192.168.0.2 eq 1234
permit udp 10.10.0.0 0.0.255.255 host 192.168.0.2 eq 2079
deny ip 10.10.0.0 0.0.255.255 10.0.0.0 0.255.255.255
deny ip 10.10.0.0 0.0.255.255 172.16.0.0 0.240.255.255
deny ip 10.10.0.0 0.0.255.255 192.168.0.0.0 0.0.255.255
permit ip any any

interface range G1/0/1 - 46
ip access-group FILTRAPORTA in

--
Flavio Visentin

Scientists discovered what's wrong with the female brain: on the left
side, there's nothing right, and on the right side, there's nothing left

gandalf.co...@gmail.com

unread,

May 2, 2012, 3:12:11 PM5/2/12

to

Il giorno mercoledì 2 maggio 2012 21:03:03 UTC+2, THe_ZiPMaN ha scritto:
> Il perché te lo dico io... perché la rete l'ha fatta un incompetente.

Già.

> Ma questi 4 switch sono tutti cisco? Se sì allora vai di PVLAN.

Quelli di accesso si, il centrostella mi pare sia un Extreme X450a
(mi pare si chiami così) che però sarà dismesso. (perchè? Perchè serve a me :D )

Preferirei evitare di vincolarmi ad un vendor.

> Lavorare nella merda è un buon modo per sporcarsi.

Lo so, ma non faccio beneficenza, io non ho la minima voglia di riconfigurare
tutto aggratis e sopratutto il cliente vuole tenere tutto così.

> E' fattibile semplicemente anche questo, ma è certamente più palloso
> configurare uno switch con 200 ip che non scriptare un server Linux.

Appunto.
Se proprio devo lavorare singolarmente su tutte le vlan, metto un firewall
linux e lavoro li sopra.

> Anyway se si tratta di un Cisco tipo 3560 o 3750 non è poi difficile
> gestire la cosa. Fai una singola ip acl scritta bene e la applichi a
> tutte le *porte* cui sono connessi i PC. L'acl sulla porta funziona a
> prescindere dalla VLAN, quindi non devi sbatterti a fare 200 acl dedicate.

Interessante. Quindi una ACL sulla porta viene applicata parallelamente ad
una eventuale ACL su VLAN, non sono mutualmente esclusive.

> Se p.es. la DMZ ha classe IP 192.168.0.0/24 e le altre vlan sono
> sottoreti /30 della 10.10.0.0/16 una cosa di questo tipo:
>
> ip access-list extended FILTRAPORTA
> permit icmp 10.10.0.0 0.0.255.255 192.168.0.0 0.0.0.255
> permit tcp 10.10.0.0 0.0.255.255 host 192.168.0.1 eq 53
> permit udp 10.10.0.0 0.0.255.255 host 192.168.0.1 eq 53
> permit tcp 10.10.0.0 0.0.255.255 host 192.168.0.2 eq 1234
> permit udp 10.10.0.0 0.0.255.255 host 192.168.0.2 eq 2079
> deny ip 10.10.0.0 0.0.255.255 10.0.0.0 0.255.255.255
> deny ip 10.10.0.0 0.0.255.255 172.16.0.0 0.240.255.255
> deny ip 10.10.0.0 0.0.255.255 192.168.0.0.0 0.0.255.255
> permit ip any any
>
> interface range G1/0/1 - 46
> ip access-group FILTRAPORTA in

Ottimo, questo dovrebbe fare al caso mio.
Ti ringrazio.

THe_ZiPMaN

unread,

May 2, 2012, 4:19:09 PM5/2/12

to

On 05/02/2012 09:12 PM, gandalf.co...@gmail.com wrote:
> Interessante. Quindi una ACL sulla porta viene applicata parallelamente ad
> una eventuale ACL su VLAN, non sono mutualmente esclusive.

E' il bello delle acl sulle porte. L'ultima volta che l'ho usata è stato
sui 3750X per configurare un ponte radio di backup. Data la limitatezza
della banda disponibile sul ponte (200mbit contro 10gbit), sulla porta
cui è connesso ho messo un'ACL extra che sega il traffico non necessario
(come quello di replica di storage, accessi diretti al file server,
ecc.). Così il link viene gestito normalmente dallo spanning tree e sono
onorate le acl per vlan, ma se si passa sul ponte radio vengono
applicate *anche* le limitazioni extra.

gandalf.co...@gmail.com

unread,

May 3, 2012, 3:52:30 AM5/3/12

to

Il giorno mercoledì 2 maggio 2012 22:19:09 UTC+2, THe_ZiPMaN ha scritto:
> Così il link viene gestito normalmente dallo spanning tree e sono
> onorate le acl per vlan, ma se si passa sul ponte radio vengono
> applicate *anche* le limitazioni extra.

Non si finisce mai di imparare.