sabato, Aprile 20, 2024

Multi SSID e DHCP Scope

In questi giorni mi sono trovato ad affrontare e gestire presso un cliente un problema di configurazione  che vorrei condividere con voi.

Da richiesta del cliente, il sistema deve prevedere un accesso WiFi separato per SSID, ad ogni SSID deve essere associata una VLAN e ad ogni VLAN deve corrispondere una classe ip assegnata via DHCP.

Nella prima parte della configurazione vedremo come creare un sistema WiFi multi ssid in VLAN. Per prima cosa dobbiamo accertarci (dalle specifiche del prodotto) che il nostro AP sia in grado di lavorare in multi SSID. In questo esempio useremo degli AP Cisco 1242 AG.

Le configurazioni che seguono fanno riferimento a questo specifico apparato, ma con poche modifiche posso essere adattate a qualsiasi (o quasi) apparato.

[Creazione SSISD e VLAN – Access Point]

Per prima cosa abilitiamo il multi ssid in configuration mode :

dot11 mbssid

Creiamo gli SSID :

dot11 ssid Management
vlan 1
authentication open
authentication key-management wpa
wpa-psk ascii Management
!
dot11 ssid Terminalini
vlan 12
authentication open
authentication key-management wpa
wpa-psk ascii Terminalini
!
dot11 ssid SmartPhone
vlan 11
authentication open
authentication key-management wpa
mbssid guest-mode
wpa-psk ascii SmartPhone

In questo esempio ho creato 3 SSID associati alle vlan 1,11 e 12 con autenticazione WPA (che chiaramente puo’ essere sostituita a seconda delle esigenze).

Lo SSID Management sarà l’unico su cui abiliteremo il lIvello 3 in modo da poter ragguingere l’AP via http, ssh o telnet  per operazioni di management.

Ora possiamo procedere con la configurazione della interfaccia Radio 0 :

interface Dot11Radio0 
no ip address no ip route-cache 
!
encryption vlan 1 mode ciphers tkip 
encryption vlan 11 mode ciphers tkip 
encryption vlan 12 mode ciphers tkip 
!
ssid Terminalini 
ssid SmartPhone 
ssid Management 
! 
station-role root 
!

In questo modo abbiamo informato l’interfaccia Radio di quali SSID deve prendersi carico e sul tipo di encryption da utilizzare per le VLAN interessate.

Ora dobbiamo separare il traffico tra le diverse VLAN e dobbiamo fare in modo che la parte WiFi possa parlare con la parte Wired. Per fare questa operazione dobbiamo creare delle sotto- interfacce sia a livello radio sia a livello ethernet. L’anello di congiunzione tra le sotto-interfacce radio e quelle Ethernet sarà il Bridge-Group.

Creiamo i bridge group :

bridge 1 protocol ieee 
bridge 2 protocol ieee 
bridge 3 protocol ieee

A questo punto possiamo creare le sotto interfacce e le relative VLAN :

!
interface Dot11Radio0.1
description "Management - VLAN 1 - NO DHCP"
encapsulation dot1Q 1 native
no ip route-cache
bridge-group 1
!
interface Dot11Radio0.2
description "SmathPhone - vlan 11 - dhcp"
encapsulation dot1Q 11
no ip route-cache
bridge-group 2
!
interface Dot11Radio0.3
description "terminalini  - vlan 12 - dhcp"
encapsulation dot1Q 12
no ip route-cache
bridge-group 3
!

Le VLAN vengono associate alle sotto inferfacce con in comando encapsulation dot1Q <vlan id>

!
interface FastEthernet0.1
encapsulation dot1Q 1 native
no ip route-cache
bridge-group 1
no bridge-group 1 source-learning
bridge-group 1 spanning-disabled
!
interface FastEthernet0.2
description "SmartPhone  - vlan 11 - dhcp"
encapsulation dot1Q 11
no ip route-cache
bridge-group 2
no bridge-group 2 source-learning
bridge-group 2 spanning-disabled
!
interface FastEthernet0.3
description "Terminalini - vlan 12 - dhcp"
encapsulation dot1Q 12
no ip route-cache
bridge-group 3
no bridge-group 3 source-learning
bridge-group 3 spanning-disabled

 

Come si puo’ vedere dalla configurazione le sotto interfacce radio e Fastethernet sono legate tra loro attraverso i bridge Group.

Bridge Group

Non ci resta che abilitare il livello 3 sul Bridge 1 in modo da garantirci l’accesso IP al nostro AP.

!
interface BVI1
ip address 192.168.1.10 255.255.255.0
no ip route-cache
!

L’interfaccia BVI è legata al Bridge attraverso il numero. Quindi, in questo caso, la BVI 1 sarà legata al bridge-Group 1.

L’utlimo passaggio per rendere il nostro AP operativo è legato al tipo di connessione con lo switch di accesso. Per abilitare il transito delle VLAN, sarà necessario configurare il trunk sulla porta dello switch su cui è connesso l’AP.

interface GigabitEthernet1/0/11
switchport trunk encapsulation dot1q
switchport trunk allowed vlan 1,11,12
switchport mode trunk

[DHCP SERVER – DHCP SCOPE – DHCP Agent Relay]

Una volta terminata la programmazione degli AP resta un altro nodo da sciogliere:  dobbiamo preoccuparci di assegnare il Livello 3 (ip, dns, gateway, …..) agli apparati connessi sugli AP, separando le classi IP a seconda della VLAN, utilizzando il nostro server DHCP posizionato sulla VLAN 1.

In questo scenario tutti i client su VLAN diverse da 1  non riceveranno mai alcuna offerta dal DHCP server perchè sono posizionati su domini di broadcast differenti.

Una soluzione possibile potrebbe essere quella di inserire dei server DHCP all’interno dei singoli domini di broadcast definiti dalle diverse VLAN, ma come potete immaginare la gestione diventerebbe complicata e, in alcuni scenari complessi, ingestibile.

Un’ altra soluzione (adottata in questo articolo) è quella di utilizzare dei server DHCP Lite, chiamati Agent Relay, posizionati all’interno di ogni dominio di broadcast e di definire sui nostri server DHCP degli scope dedicati ai singoli domini di brodcast.

Un Agent Relay (http://en.wikipedia.org/wiki/Dynamic_Host_Configuration_Protocol#DHCP_Relaying) è a tutti gli effetti un server DHCP, ma non è in grado di assegnare direttamente un Livello 3 ai client. Il suo compito è quello di intercettare le richieste DHCP (0.0.0.0 – 255.255.255.255) prenderle in carico e di rigirarle (proxy) al sever DHCP. Prima di rigirare la richiesta, l’agent relay opera alcune modifiche sostituendo 0.0.0.0 con il suo indirizzo IP e il 255.255.255.255 con l’indirizzo IP del server DHCP (ho semplificato molto per rendere il processo comprensibile anche senza particolari conoscenze di networking) e trasforma la richiesta in unicast (http://en.wikipedia.org/wiki/Unicast ) così da poterla inviare direttamente al server DHCP. Il server DHCP recupera la Network ID dall’indirizzo del relay agent, consulta se esiste uno scope dedicato a quella network ed invia le info al Relay Agent il quale risponde al client che ne ha fatto richiesta chiudendo il cerchio.

Bene, a questo punto vediamo nel dettaglio come costruire questa seconda parte.

Per prima cosa definiamo gli scope sul nostro server DHCP. Nel mio caso ho utilizzato un server Windows 2012, ma è possibile utilizzare qualsiasi apparato attivo che supporti il DHCP Server. All’interno dello scope andremo a definire tutti i parametri di livello 3 da inviare ai client che ne faranno richiesta. Questa operazione va fatta per ogni VLAN a cui desideriamo assegnare una Classe Ip specifica. Nel nostro caso avremo due scope: uno per la VLAN 11 e uno per la VLAN 12.

Definiti gli scope, creiamo gli Agent Relay. Usero’ per questa operazione uno switch di accesso Cisco 3750. Prima di entrare nel merito della programmazione, dobbiamo ancora rispondere ad una domanda: dove posizioniamo l’ Agent Relay ?

L’unica certezza che posso darvi è che l’ Agent Relay e i client devono trovarsi sullo stesso dominio di broadcast. Il suo posizionamento è legato a fattori specifici tecnici e politici della rete in cui si lavora. Quindi, ad esempio, volendo utilizzare gli switch come agent relay, potremmo posizionalo su uno switch di accesso o di distribuzione o di core.

In uno scenario standard, forse e ripeto forse (è una mia personale considerazione),  il posizionamento su uno switch di core sarebbe preferibile.

Bene, riprendiamo il nostro cacciavite in mano e proseguiamo con le configurazioni :

in configurazione generale definiamo le due vlan :

vlan 11

name SmartPhone

!

vlan 12

name Terminalini

!

Definiamo addesso il Livello 3 per le VLAN ed abilitiamo due agent relay (uno per ogni vlan) :

interface Vlan11
description "ReLay Agent - VLAN 11 - DHCP 192.168.11.x"
ip address 192.168.11.251 255.255.255.0
ip helper-address 10.168.1.45
!
interface Vlan12
description "ReLay Agent - VLAN 12 - DHCP 192.168.12.x"
ip address 192.168.12.251 255.255.255.0
ip helper-address 10.168.1.45
!

Vediamo nel dettaglio analizzando solo la VLAN 12 :

Creiamo un interfaccia virtuale per la VLAN 12.

interface Vlan12

 

Alziamo il livello 3 sulla interfaccia virtuale :

ip address 192.168.12.251 255.255.255.0

Questo sarà l’indirizzo che verrà inviato al server DHCP come source da parte dell’agent relay, dal quale verrà ricavato il networkID (192.168.12.0) usato dal DHCP server per identificare lo scope relativo.

Abilitiamo l’Agent Relay :

 ip helper-address 10.168.1.45

L’indirizzo IP inserito qui è l’indirizzo IP del server DHCP, in questo modo l’agent relay potrà operare una richiesta unicast contattando direttamente il server DHCP.

A questo punto, tutti i client WiFi autenticati sulla VLAN 12 e/o sulla VLAN 11 riceveranno i dati per lo scope dedicato.

[SICUREZZA – VERTICALIZZAZIONE]

L’ultimo aspetto che affronteremo in questo articolo è legato alla sicurezza e alla verticalizzazione nella assegnazione degli indirizzi IP. Come abbiamo visto finora, l’agent relay si preoccupa solo di modificare Source e Destination e il server DHCP ha solo il source IP come elemento per poter decidere quale scope utilizzare e quali paramentri assegnare.

Lo standard che definisce il DHCP Agent Relay (https://www.ietf.org/rfc/rfc3046.txt) prevede anche la possibilità di aggiungere altre informazioni alla richiesta inviata al server DHCP. Questa feature si chiamata Relay Agent Information Option, meglio conosciuta come Option 82 (82 è il codice della Option, vedi RFC per i dettagli).

Una trattazione esaustiva di questa feature richiederebbe un sessione dedicata, diciamo solo che grazie alla Option 82 possiamo creare delle policy all’interno degli scope per suddividere gli IP e le impostazioni da assegnare ai singoli client.

In questo articolo mi limiterò a descrivervi come abilitarla e come utilizzarla per uno scopo ben preciso: riconoscere il mio l’agent relay.

Per prima cosa abilitiamo la feature sull’agent relay :

A livello di interfaccia inseriamo questo comando per abilitare la Option 82

 ip dhcp relay information option-insert;

Sempre a livello di interfaccia inseriamo la option desiderata :

ip dhcp relay information option subscriber-id Terminalini

N.B.: la subscription-id è successiva alla definizione dell’RFC, le specifiche le trovate qui http://tools.ietf.org/html/draft-ietf-dhc-subscriber-id-03

Il risultato finale sarà :

interface Vlan11
description "ReLay Agent - VLAN 11 - DHCP 192.168.11.x"
ip dhcp relay information option subscriber-id SmartPhone
ip dhcp relay information option-insert
ip address 192.168.11.101 255.255.255.0
ip helper-address 10.168.1.45
!
interface Vlan12
description "ReLay Agent - VLAN 12 - DHCP 192.168.12.x"
ip dhcp relay information option subscriber-id Terminalini
ip dhcp relay information option-insert
ip address 192.168.12.251 255.255.255.0
ip helper-address 10.168.1.45
!

Bene a questo punto non ci resta che definire una policy sul nostro server DHCP.

La policy che ho creato serve solo ad essere sicuro che la richiesta provenga da uno specifico Agent-relay, ma nulla ci vieta di creare più policy all’interno dello stesso scope per assegnare parametri diversi a host differenti all’interno dello stesso dominio di broadcast.

N.B.: la subscriber-id prevede come parametro un valore stringa a nostra libera scelta. Nella definzione degli agent- relay abbiamo usato :

ip dhcp relay information option subscriber-id SmartPhone
....
ip dhcp relay information option subscriber-id Terminalini

In windows il valore va inserito in esadecimale e non in formato testo. Quindi bisogna prima convertire la stringa in HEX e poi incollarla nel campo relativo della policy. Se non fate questa operazione, la policy non verrà metchata e quindi i client non riceveranno il livello 3.

Ad esempio la parola SmartPhone in Hex diventa: 536d61727450686f6e65

Con questa ultima parte ho terminato. Spero che la lettura sia stata di vostro gradimento.

G.

 

Articoli correlati

Non perdere il lancio online della Community GDPR Day: 26 marzo 2024

La sicurezza dei dati e delle informazioni non è più un'opzione, ma una necessità imprescindibile. Lo dimostrano i tanti attacchi informatici che, con frequenza...

Digital Transformation


 

Noleggia una Tesla per il tuo evento ICT!

Categorie