[WORKLOG] - Creare e gestire reti wireless con SSID multipli su Tp-Link TL-WA701ND, mantenendo le reti separate.
Ho recentemente avuto necessità di pensionare il mio vecchio router ADSL, riconvertito da tempo per operare solo come mero access point. Non ho particolari esigenze quindi ho optato per il prodotto più economico in assoluto che ho trovato in giro.
Avevo già avuto modo di provare questo dispositivo, il Tp-Link TL-WA701ND e mi sembrava adeguato: Costa circa 30€, viene venduto già dotato di adattatore PoE, supporto wireless “n” 150Mbps, etc...
Il dispositivo è anche supportato dalle più recenti versioni di OpenWRT, un firmware modificato e opensource per svincolare il dispositivo dai limiti imposto dall'interfaccia proprietaria: Il dispositivo si presta quindi anche a giocarci un pochino, con la tranquillità che in caso di disastro completo non si fa poi troppo danno.
Per la mia rete wireless di casa ho sempre usato come sistemi di sicurezza una cifratura WPA2 psk ed il MAC filtering, soluzione che unita alla mancata trasmissione del nome SSID garantisce una certa sicurezza ma che comporta alcune scomodità, nel momento in cui ci fosse la necessità di concedere l'accesso alla propria rete anche ad amici o ospiti di passaggio in quanto richiede di accedere al router, acquisire il MAC Address del dispositivo che si vuole autorizzare, etc...
Configurando il nuovo AP, mi sono accorto che prevede la possibilità di gestire SSID multipli (fino a 4) ed ho quindi deciso di provare ad implementare una rete “ospiti” parallela alla mia rete domestica. Unico fastidio, per ora, è che il dispositivo TP-Link non permette di scegliere se fare il broadcast del nome SSID (rendere la rete visibile a tutti) per rete ma solo su tutti gli SSID gestiti dal dispositivo: Quindi le reti sono o tutte visibili o tutte nascoste.
A questa limitazione, magari si potrà porre rimedio in futuro, implementando il firmware OpenWRT ma per ora mi accontento.
Scopo:
Realizzare due o più reti wireless distinte, una protetta da cifratura e MAC filtering e l'altra “open”, ad accesso libero o comunque con una password semplice. Le due reti dovranno essere completamente distinte e tra loro indipendenti:
- La rete “privata” dovrà poter far parte del resto della mia LAN, quindi dovrà interrogare il mio DHCP e DNS interno, accedere alle risorse condivise dagli altri pc ed accedere ad internet senza particolari problematiche o limitazioni, come se fosse un'estensione della rete cablata.
- La rete “open” invece dovrà essere completamente segregata e indipendente dalla mia rete interna: Dovrà utilizzare uno scope di DHCP completamente separato ed utilizzare DNS pubblici (ho scelto la versione “FamilyShield” di OpenDNS, dei server DNS già filtrati per impedire l'accesso ai contenuti inappropriati e che rispondono sugli IP 208.67.222.123 208.67.220.123). I client con accesso a questa rete non dovranno in alcun modo poter accedere alle risorse delle altre due reti ma potranno avere solo accesso ad internet.
Step:
- 3_ Configurazione del servizio DHCP e DynamicDNS.
1_ Configurazione del server per gestire sull'interfaccia “inside” le VLAN.
Per la configurazione di partenza del serverino che opera da gateway/router e firewall, faccio riferimento al mio serverino di casa: Si tratta di una installazione di Debian 6 64bit su cpu ATOM con una mobo dual-Lan configurata per operare come gateway/firewall.
Per aggiungere il supporto alle VLAN al server Linux e renderlo quindi in grado di discriminare il traffico dotato di un TAG, è sufficiente installare il pacchetto "vlan" con apt e aggiungere il modulo “8021q” all'elenco dei moduli contenuto nel file “/etc/modules” con i seguenti comandi:
codice:
sudo apt-get install vlan
sudo echo 8021q >> /etc/modules
In modo che il modulo sia ricaricato automaticamente al riavvio. Per attivare il supporto a questo protocollo senza riavviare, è sufficiente caricare a mano il modulo con il comando:
codice:
sudo modprobe 8021q
Riassumendo velocemente, quando si usano le VLAN i pacchetti che transitano sulla rete vengono marcati con un “id” denominato VID (Vlan ID) che identifica l' appartenenza alla specifica VLAN.
Il valore del “id” o “tag” può variare tra 0 e 4095 ma i due estremi sono riservati quindi il “tag” avrà un valore compreso tra 1 e 4094. Ho letto che solitamente il “VID” 1 viene riservato a scopi amministrativi ma mi risulta essere una consuetudine piuttosto che un obbligo. Inoltre, sempre per consuetudine, è frequente che venga l'utilizzato come “VID” un identificativo che richiami la configurazione di rete esistente: Nel mio caso, userò come “VID” un valore che richiami la classe di IP della rete associata alla VLAN.
Avviso che, mentre di fanno i primi test, è molto facile finire per tagliarsi fuori dal server, situazione non molto comoda se il server è “headless” (senza monitor ne tastiera) o in fisicamente in una posizione scomoda, quindi consiglio molta attenzione...
In questa guida si trovano alcune istruzioni su come configurare le vlan sul server usando il comando “vconfig“.
In alternativa è possibile procedere modificando manualmente il file "/etc/network/interfaces" per aggiungere delle nuove interfacce di rete virtuali associate alle VLAN ed io preferisco procedere in questo secondo modo. La mia configurazione originale per la sola interfaccia di rete eth1 (inside) prevede questo:
codice:
matteo@server:~$ sudo ifconfig
eth0 Link encap:Ethernet HWaddr 00:25:90:35:6b:7a
inet addr:192.168.50.2 Bcast:192.168.50.255 Mask:255.255.255.0
inet6 addr: fe80::225:90ff:fe35:6b7a/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:456227615 errors:0 dropped:0 overruns:0 frame:0
TX packets:507576434 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:266927082174 (248.5 GiB) TX bytes:143666480259 (133.7 GiB)
Interrupt:16 Memory:feae0000-feb00000
eth1 Link encap:Ethernet HWaddr 00:25:90:35:6b:7b
inet addr:192.168.200.1 Bcast:192.168.200.255 Mask:255.255.255.0
inet6 addr: fe80::225:90ff:fe35:6b7b/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:142454788 errors:0 dropped:63 overruns:0 frame:0
TX packets:295264552 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:21841295703 (20.3 GiB) TX bytes:413736636979 (385.3 GiB)
Interrupt:17 Memory:febe0000-fec00000
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:571659 errors:0 dropped:0 overruns:0 frame:0
TX packets:571659 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:84261853 (80.3 MiB) TX bytes:84261853 (80.3 MiB)
Per la scheda di rete "inside", la configurazione in "/etc/network/interfaces" prevede questo:
codice:
[...]
# Scheda di rete secondaria - Inside -
auto eth1
allow-hotplug eth1
iface eth1 inet static
address 192.168.200.1
netmask 255.255.255.0
dns-search fracassetti.lan
broadcast 192.168.200.255
A cui devo semplicemente aggiungere di seguito la configurazione che definisce le interfacce virtuali che cui fanno capo le VLAN:
codice:
# Scheda di rete secondaria - VLAN Wi-Fi -
auto eth1.150
allow-hotplug eth1.150
iface eth1.150 inet static
address 192.168.150.1
netmask 255.255.255.0
dns-search fracassetti.lan
broadcast 192.168.150.255
vlan_raw_device eth1
# Scheda di rete secondaria - VLAN Wi-Fi Ospiti -
auto eth1.100
allow-hotplug eth1.100
iface eth1.100 inet static
address 192.168.100.1
netmask 255.255.255.0
broadcast 192.168.100.255
Le nuove interfacce di rete, ad eccezione della denominazione che è nel formato “device.vlanid” (eth1.150 o eth1.100), sono configurate come se fossero schede fisiche normalissime con il loro IP ed i loro parametri di rete. Il valore che segue il "." nella denominazione è appunto il VID della rete.
Ho quindi configurato delle interfacce associate alle VLAN cui appartengono il vid “100” (eth1.100) e “150” (eth1.150): Nella configurazione della eth1.150 ho specificato anche il parametro “vlan_raw_device eth1” che indica al sistema che l'interfaccia virtuale con VID 150 si appoggia al device hardware “eth1”. Non è un parametro obbligatorio, la configurazione (a meno che non si usi un alias per definire le interfacce come nella guida linkata in precedenza) funziona perfettamente anche senza questa indicazione,
- L'interfaccia eth1 è la mia rete cablata o “wired” lato inside;
- L'interfaccia eth1.150 sarà la VLAN associata alla mia rete Wi-Fi ad accesso controllato. Dato che farà parte della mia rete privata “inside” ho specificato il parametro “dns-search fracassetti.lan”.
- L'interfaccia eth1.100 sarà la VLAN associata alla mia rete Wi-Fi ad accesso libero;
Per applicare la configurazione, si può riavviare il server oppure utilizzare i comandi:
codice:
matteo@server:~$ sudo ifup eth1.150 && sudo ifup eth1.100
Set name-type for VLAN subsystem. Should be visible in /proc/net/vlan/config
Added VLAN with VID == 150 to IF -:eth1:-
Set name-type for VLAN subsystem. Should be visible in /proc/net/vlan/config
Added VLAN with VID == 100 to IF -:eth1:-
per attivare le interfacce di rete, verificando il risultato con il comando:
codice:
matteo@server:~$ sudo cat /proc/net/vlan/config
VLAN Dev name | VLAN ID
Name-Type: VLAN_NAME_TYPE_RAW_PLUS_VID_NO_PAD
eth1.150 | 150 | eth1
eth1.100 | 100 | eth1
oppure semplicemente:
codice:
matteo@server:~$ sudo ifconfig
eth0 Link encap:Ethernet HWaddr 00:25:90:35:6b:7a
inet addr:192.168.50.2 Bcast:192.168.50.255 Mask:255.255.255.0
inet6 addr: fe80::225:90ff:fe35:6b7a/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:456230582 errors:0 dropped:0 overruns:0 frame:0
TX packets:507580719 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:266927462524 (248.5 GiB) TX bytes:143666875867 (133.8 GiB)
Interrupt:16 Memory:feae0000-feb00000
eth1 Link encap:Ethernet HWaddr 00:25:90:35:6b:7b
inet addr:192.168.200.1 Bcast:192.168.200.255 Mask:255.255.255.0
inet6 addr: fe80::225:90ff:fe35:6b7b/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:142454971 errors:0 dropped:63 overruns:0 frame:0
TX packets:295264690 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:21841326378 (20.3 GiB) TX bytes:413736671508 (385.3 GiB)
Interrupt:17 Memory:febe0000-fec00000
eth1.100 Link encap:Ethernet HWaddr 00:25:90:35:6b:7b
inet addr:192.168.100.1 Bcast:192.168.100.255 Mask:255.255.255.0
inet6 addr: fe80::225:90ff:fe35:6b7b/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:6 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:0 (0.0 B) TX bytes:468 (468.0 B)
eth1.150 Link encap:Ethernet HWaddr 00:25:90:35:6b:7b
inet addr:192.168.150.1 Bcast:192.168.150.255 Mask:255.255.255.0
inet6 addr: fe80::225:90ff:fe35:6b7b/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:6 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:0 (0.0 B) TX bytes:468 (468.0 B)
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:571716 errors:0 dropped:0 overruns:0 frame:0
TX packets:571716 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:84270000 (80.3 MiB) TX bytes:84270000 (80.3 MiB)
Questa configurazione prevede due reti VLAN ed un rete non taggata. L'interfaccia del server ha quindi una configurazione "ibrida" in quanto trasporta sia pacchetti taggati che pacchetti privi di tag.
Questa configurazione è stata adottata per evitare di dover riconfigurare i pc client connessi alla rete cablata per aggiungere alla configurazione il supporto alle VLAN, che come detto non è scontato siano dotati del supporto necessario.
Questa configurazione da sola sarebbe una porcheria inutile, in quanto un qualunque dispositivo con la corretta configurazione IP impostata staticamente e connesso alla rete open potrebbe accedere tranquillamente alla risorse sulla rete cablata e sulla rete wireless privata, vanificando tutto il lavoro: Il mezzo fisico di trasmissione e accesso alla rete è infatti lo stesso e non supporta le VLAN (mi riferisco allo switch netgear) quindi finisce per mischiare tutti i pacchetti in un'unica orgia TCP/IP che si propaga per tutta la rete.
A questa mancanza, è possibile ovviare con sufficiente efficacia lavorando sulla configurazione del firewall sul router.
2_ Configurazione dell'access point per gestire SSID multipli e VLAN.
E' ora necessario configurare l'access point sia per creare gli SSID che voglio utilizzare che per associarvi una VLAN.
Dal menù di configurazione dell'Access point Tp-Link, seleziono “Wireless → Wireless Settings”. Da questa schermata è possibile configurare il valore “Operation mode” dell'AP su “Multiple SSID” e spuntare “Enable VLAN”, impostando il nome dei soli SSID che si vuole trasmettere ed il VID che dovrà essere associato alla rete wireless, lasciando vuoti gli altri.
https://up.nexthardware.com/user_ima...0_SSID_164.png
Dal menù “Wireless → Wireless Security” è poi possibile configurare i criteri cifratura per ciascun SSID indipendentemente dagli altri, così come nel menù “Wireless → Wireless MAC Filtering” è possibile attivare e configurare questa feature per ognuno degli SSID creati. Non male, per un dispositivo da 30€...
https://up.nexthardware.com/user_ima.../00_SSID_2.png
https://up.nexthardware.com/user_ima.../00_SSID_3.png
Salvare e riavviare l'AP per applicare le modifiche.
3a_ Configurazione degli scope DHCP.
Le tre reti saranno servite da scope DHCP indipendenti (in modo da poter assegnare a ciascuna opzioni diverse) che saranno però tutti gestiti dal mio unico server.
Questo è possibile perchè ogni subnet associata alle interfacce VLAN del mio server ha un diverso broadcast a cui vengono inviate le richieste DHCP ed il server è quindi in grado di capire se la richiesta arriva da una client appartenente alla rete 192.168.200.0/24, 192.168.150.0/24 oppure 192.168.100.0/24, rispondendo di conseguenza con il corretto lease.
Senza le VLAN, non credo sarebbe possibile separare in questo modo le reti, non con un solo access point con un solo indirizzo IP.
Si tratta ora di creare gli scope che ci servono, similmente a quanto fatto in precedenza. Aggiungo quindi al file “/etc/default/isc-dhcp-server“ le due nuove interfacce separate da spazi, in questo modo:
codice:
INTERFACES="eth1 eth1.100 eth1.150"
E apporto poi le necessarie modifiche al file “/etc/dhcp/dhcpd.conf”, aggiungendo in fondo (dopo la sezione già esistente per la rete cablata) la definizione dei nuovi scope con le relative opzioni e indicando le zone DNS che dovranno essere poi aggiornate dinamicamente:
codice:
matteo@server:~$ sudo nano /etc/dhcp/dhcpd.conf
[...]
# Configurazione dello scope per la mia rete cablata:
subnet 192.168.200.0 netmask 255.255.255.0 {
authoritative;
# Secret-key per l'aggiornamento DDNS
key "DHCP-KEY" {
algorithm HMAC-MD5.SIG-ALG.REG.INT;
secret "veryverysecretkeyfordhcp==";
}
# Zona di forward di casa
zone fracassetti.lan. {
primary 127.0.0.1;
key DHCP-KEY;
}
# Zona di reverse di casa
zone 200.168.192.in-addr.arpa. {
primary 127.0.0.1;
key DHCP-KEY;
}
range 192.168.200.200 192.168.200.220;
option domain-name-servers 192.168.200.1;
option domain-name "fracassetti.lan";
option ntp-servers 192.168.200.1;
option routers 192.168.200.1;
option broadcast-address 192.168.200.255;
default-lease-time 86400;
max-lease-time 86400;
# pc salotto
host salotto {
hardware ethernet 00:18:f3:82:82:fd;
fixed-address 192.168.200.201;
}
}
# Wi-Fi - VLAN150
subnet 192.168.150.0 netmask 255.255.255.0 {
option ntp-servers 192.168.200.1;
authoritative;
# Secret-key per l'aggiornamento DDNS
key "DHCP-KEY" {
algorithm HMAC-MD5.SIG-ALG.REG.INT;
secret "veryverysecretkeyfordhcp==";
}
# Zona di forward di casa
zone fracassetti.lan. {
primary 127.0.0.1;
key DHCP-KEY;
}
# Zona di reverse WLAN Wi-Fi
zone 150.168.192.in-addr.arpa. {
primary 127.0.0.1;
key DHCP-KEY;
}
range 192.168.150.100 192.168.150.200;
option domain-name-servers 192.168.200.1;
option domain-name "fracassetti.lan";
option routers 192.168.150.1;
option broadcast-address 192.168.150.255;
default-lease-time 86400;
max-lease-time 86400;
}
# Wi-Fi Ospiti - VLAN100
subnet 192.168.100.0 netmask 255.255.255.0 {
authoritative;
# Secret-key per l'aggiornamento DDNS
key "DHCP-KEY" {
algorithm HMAC-MD5.SIG-ALG.REG.INT;
secret "veryverysecretkeyfordhcp==";
}
# Zona di reverse WLAN Wi-Fi Ospiti
zone 100.168.192.in-addr.arpa. {
primary 127.0.0.1;
key DHCP-KEY;
}
range 192.168.100.100 192.168.100.200;
option domain-name-servers 208.67.222.123, 208.67.220.123;
option domain-name "fracassetti.ospiti";
option routers 192.168.100.1;
option broadcast-address 192.168.100.255;
default-lease-time 86400;
max-lease-time 86400;
}
key DHCP-KEY {
secret veryverysecretkeyfordhcp==;
algorithm hmac-md5;
}
Si tratta sostanzialmente di replicare la configurazione della zona esistente anche per le altre due zone, con i minimi aggiustamenti necessari:
- La rete “wireless privata”, pur essendo dotata di una zona di reverse dedicata, aggiorna la zona di ricerca diretta “fracassetti.lan”, distribuisce come “nome di rete” lo stesso nome dello scope che serve la rete cablata e usa il server stesso (sull'IP associato all'interfaccia cablata) come DNS.
- La rete “pubblica”, pur avendo una propria zona di ricerca inversa, non è associata ad una zona di ricerca diretta sul mio server, distribuisce un nome di rete diverso dalla rete “privata” e usa dei DNS pubblici per la configurazione dei client.
Sul server DHCP, non c'è bisogno di fare altro: La stessa configurazione, eventualmente, si può effettuare utilizzando webmin.
3b_ Configurazione delle zone DNS e Dynamic DNS.
Devo ora creare sul server DNS le zone di ricerca inversa per gli scope DHCP che ho configurato, esattamente come fatto in precedenza qui. Ho deciso di non creare una zona di ricerca diretta per la rete ospiti ma nulla mi vieterebbe di farlo, se lo ritenessi necessario.
Creare le zone significa semplicemente aggiungerne la definizione nel file "/etc/bind/named.conf.local", specificando che le zone sono soggette ad aggiornamento dinamico e indicando il nome della key configurata nel servizio DHCP per l'aggiornamento delle stesse:
codice:
matteo@server:~$ sudo nano /etc/bind/named.conf.local
[...]
zone "150.168.192.in-addr.arpa" {
type master;
file "/var/lib/bind/192.168.150.rev";
allow-update {
key DHCP-KEY;
};
};
zone "100.168.192.in-addr.arpa" {
type master;
file "/var/lib/bind/192.168.100.rev";
allow-update {
key DHCP-KEY;
};
};
Non credo ci sia nulla da aggiungere o da spiegare.
In alternativa, queste zone possono con facilità essere create usando l'interfaccia di webmin. Per applicare le modifiche, riavviare entrambi i servizi DHCP e DNS con i comandi:
codice:
sudo /etc/init.d/bind9 restart
sudo /etc/init.d/isc-dhcp-server restart
3c_ Verifica di funzionamento.
Per verificare il funzionamento corretto dei servizii DHCP e DNS, è sufficiente associare un pc a ciascuna rete wireless e controllare che le relative zone di ricerca vengano aggiornate nel DNS: Se si vede comparire il client con un IP appartenete al range atteso, sia il DHCP che il DNS ed l'aggiornamento dinamico funzionano correttamente:
https://up.nexthardware.com/user_ima...ebmin_DDNS.png
Effettuando le prime verifiche, mi sono accorto di un comportamente inatteso da parte del server DHCP: Il log registrava frequenti attività da parte dei client provenienti dalle reti wireless, che riportavano richieste provenienti dalle interfacce di rete sbagliate.
https://up.nexthardware.com/user_ima...ebmin_DHCP.png
Dopo qualche serata passata a cercare di capire dopo avevo toppato o ad affinare il firewall per tentare di contenenere eventuali “flood” di pacchetti da un'interfaccia all'altra, mi sono deciso a fare la cosa più ovvia: RTFM.
A questi indirizzi, si possono trovare la documentazione del servizio DHCP ed alcune utili spiegazioni:
4.3.2 DHCPREQUEST message
DHCP: the Dynamic Host Configuration Protocol
Non è esattamente una lettura avvincente ma al capitolo “4.3.2 DHCPREQUEST message“ del primo link si trova credo la spiegazione dello strano comportamente registrato nel log che risulta, quindi, dovuto al normale funzionamento del servizio DHCP.
Per farla breve, nello scambio di informazioni tra il server DHCP ed i client, il server può ricevere dei messaggi dal client che sono denominati come “DHCPDISCOVER”, “DHCPREQUEST”, “DHCPDECLINE”, “DHCPRELEASE” o “DHCPINFORM”.
In risposta ad un “DHCPDISCOVER”, il server risponde con un “DHCPOFFER” che contiene una serie di informazioni di configurazione che il server "propone" al client per la configurazione delle sue interfacce di rete. Queste informazioni sono scelte sulla base di diversi criteri, tra i quali la network da cui arriva la richiesta DHCPDISCOVER del client: Avendo creato una VLAN sia sull'AP che sul server, le richieste client arrivano al server taggate da questa VLAN e risultano quindi provenienti dalla subnet associata a questa rete nonostante transitino sullo stesso rame e dalla stessa interfaccia fisica delle altre VLAN e della rete cablata.
All'offerta del server, il client può rispondere un messaggio “DHCPREQUEST”, generalmente contenente informazioni relativi a prcedenti lease ricevuti, per tentare di riconfermarli se si trovano ancora nella disponibilità del del server.
Qualora il client richieda al server con il messaggio “DHCPREQUEST” una configurazione IP che il server può fornire, il server risponde con un “DHCPACK” che conferma al client i parametri. Dal quel momento, il client può configurarsi con le informazioni ricevute e considerarsi assegnato il lease.
Qualora invece la configurazione IP richiesta dal client non fosse disponibile, il server deve rispondere con un messaggio “DHCPNAK” a cui fa seguito da parte del client un altro messaggio “DHCPREQUEST” e così via fino a quando il server non risponde con “DHCPACK”.
Ecco quindi il perchè del mio messaggio di errore: Sulla base di configurazioni IP ricevute in precedenza, dopo il DHCPDISCOVER il client risponde al server con una “DHCPREQUEST” riferita alle precedenti reti cui è stato connesso. In questo caso, passando da un'interfaccia di rete all'altra per fare i test, il client probabilmente ha dei riferimenti alla rete 192,168,200,0/24 oppure 192,168,100,0/24 a cui il server, giustamente, risponde con un “DHCPNAK” che informa il client che l'IP richiesto appartiene ad una rete diversa da quella associata all'interfaccia da cui è pervenuta la richiesta e che non può quindi essere assegnato.
Nessun errore, dunque.
4_ Configurazione del firewall.
Come accennato in precedenza, così come configurato il mio castello di carte non stà in piedi: Mancando il supporto VLAN allo switch e mischiando tutte le reti sullo stesso mezzo fisico, sarebbe estremamente semplice configurare un pc con un IP statico appartenente alla rete 192.168.200.0/24 e agganciarsi alla rete wireless OPEN, ottenendo così l'accesso alla rete "privata".
Per il corretto funzionamento delle reti così come le ho previste, ho dovuto quindi apportare qualche modifica al firewall del mio serverino.
Il server è configurato per operare come router quindi per smistare pacchetti da una rete all'altra: Non può sapere quali reti per me sono interne o esterne o quali voglio far comunicare e quali isolare quindi è necessario definire queste indicazioni nello script che gestisce il firewall.
Avendo aggiunto diverse interfacce di rete “inside” ho preferito apportare alcune modifiche alla sezione “Local Settings” iniziale dove vengono definite le reti che diventa da così:
codice:
# Internet Interface
INET_IFACE="eth0"
INET_ADDRESS="192.168.50.150"
# Local Interface Information
LOCAL_IFACE="eth1"
LOCAL_IP="192.168.100.150"
LOCAL_NET="192.168.100.0/24"
LOCAL_BCAST="192.168.100.255"
[...]
a così:
codice:
# Internet Interface
INET_IFACE="eth0"
INET_ADDRESS="192.168.50.2"
# Local Interface Information
LOCAL_IP="192.168.200.1"
WIRED_IFACE="eth1"
WLAN_IFACE="eth1.150"
WLAN_OSPITI_IFACE="eth1.100"
WIRED_NET="192.168.200.0/24"
WLAN_NET="192.168.150.0/24"
WLAN_OSPITI_NET="192.168.100.0/24"
WIRED_BCAST="192.168.200.255"
WLAN_BCAST="192.168.150.255"
WLAN_OSPITI_BCAST="192.168.100.255"
INSIDE_NET="$WIRED_NET $WLAN_NET $WLAN_OSPITI_NET"
INSIDE_IFACE="eth1 eth1.150 eth1.100"
INSIDE_BCAST="$WIRED_BCAST $WLAN_BCAST $WLAN_OSPITI_BCAST"
# Trusted Networks and source IP
TRUSTED_IFACE="$WIRED_IFACE $WLAN_IFACE"
TRUSTED_NET="$WIRED_NET $WLAN_NET"
TRUSTED_BCAST="$WIRED_BCAST $WLAN_BCAST"
# Untrusted Networks and source IP
DMZ_IFACE="$WLAN_OSPITI_IFACE"
DMZ_NET="$WLAN_OSPITI_NET"
DMZ_BCAST="$WLAN_OSPITI_BCAST"
[…]
In pratica non ho fatto altro che sostituire la sezione “Local Interface Information” con tre sezioni, ognuna dedicata alla propria interfaccia (WIRED, WLAN e WLAN_OSPITI). Non ho specificato l'IP della singola rete perchè non ne ho bisogno e ho lasciato come unica variabile “local” proprio l'IP della dell'interfaccia di rete cablata.
Ho poi definito delle variabili composite, che comprendano diverse reti: Questo mi permette con un'unica riga nel firewall di impostare la stessa regola per più valori. Dato che tutto lo script è ormai di poco meno di 900 righe compresi commenti, stringerlo un pò non è male.
Nelle reti “INSIDE” ho messo tutto quello che non è l'interfaccia eth0 ed internet, nelle reti “trusted” ho messo solo la rete cablata e la wireless privata mentre come rete “Untrusted” ho riportato la rete wireless “Open”.
Come prima cosa, ho aggiunto una sezione che si occupa di isolare la rete wireless OPEN da tutte le altre: Permetto il traffico DHCP da e verso il server ed i client presenti in questa rete ma non permetto ai client altre comunicazioni con il server (INPUT).
Il router deve poter effettuare il forward del pacchetti dalla rete untrusted verso internet ($INET_IFACE) ma deve impedire il passaggio da e verso tutte le altre reti (DROP).
codice:
###############################################################################
# Set up DMZ isolation
# Permetto alle reti "UNTRUSTED" di accedere solo ad internet e non al server stesso od alle altre reti.
# La prima riga permette solo il funzionamento del servizio DHCP, gestito dal server:
for X in $DMZ_IFACE; do $IPT -A INPUT -p UDP -i $X --source-port 68 --destination-port 67 -j ACCEPT; done;
for X in $DMZ_IFACE; do $IPT -A INPUT -p ALL -i $X -j DROP; done;
for X in $DMZ_IFACE; do $IPT -A FORWARD -p ALL -i $X -o $INET_IFACE -j ACCEPT; done;
for X in $DMZ_IFACE; do $IPT -A FORWARD -p ALL -i $X -j DROP; done;
Ho utilizzato dei cicli di "for" per ripetere l'applicazione della regola per tutti i valori inseriti nella variabile "$DMZ_IFACE", definita nella parte iniziale dello script. Nel mio caso ho solo la rete WLAN_OSPITI ma la regola dovrebbe funzionare bene anche se la variabile contenesse più valori.
Apporto poi una importante modifica alla chain denominata “bad_packets”: Definisco come “bad” tutti i pacchetti che provengono da una rete diversa da quella che ho proposto in fase di configurazione. In questo modo, eventuali pc con IP statici assegnati alla reti “trusted” che dovessero collegarsi alla wireless OPEN non potrebbero comunque andare in giro per le altre reti perchè, avendo definito delle VLAN, i pacchetti arriverebbero da un'associazione rete/interfaccia non corrispondente a quelle che ho autorizzato. Questa da rendere con un ciclo è già molto più difficile, quindi ho preferito esplicitare le singole reti:
codice:
# bad_packets chain
#
# Drop packets received on the external interface
# claiming a source of the local network
$IPT -A bad_packets -p ALL -i $INET_IFACE -s $LOCAL_NET -j LOG --log-prefix "Illegal source: "
for X in $INSIDE_NET; do $IPT -A bad_packets -p ALL -i $INET_IFACE -s $X -j DROP; done;
# Questa e' una aggiunta alla precedente: Si accerta che i pacchetti che si
# con un determinato IP provengano solo dall'interfaccia cui ho assegnato quella configurazione.
$IPT -A bad_packets -p ALL -i $WIRED_IFACE ! -s $WIRED_NET -j DROP
$IPT -A bad_packets -p ALL -i $WLAN_IFACE ! -s $WLAN_NET -j DROP
$IPT -A bad_packets -p ALL -i $WLAN_OSPITI_IFACE ! -s $WLAN_OSPITI_NET -j DROP
Anche questa è molto più difficile da rendere con un ciclo, perchè finirebbe per incrociare i valori delle rete trusted tra loro, quindi preferisco esplicitarle. Sono due regole per ogni rete.
codice:
INPUT chain:
# Rules for the private network (accessing gateway system itself)
$IPT -A INPUT -p ALL -i $WIRED_IFACE -s $WIRED_NET -j ACCEPT
$IPT -A INPUT -p ALL -i $WIRED_IFACE -d $WIRED_BCAST -j ACCEPT
$IPT -A INPUT -p ALL -i $WLAN_IFACE -s $WLAN_NET -j ACCEPT
$IPT -A INPUT -p ALL -i $WLAN_IFACE -d $WLAN_BCAST -j ACCEPT
E questa è necessaria per permettere il funzionamento delle connessioni che richiedono una risposta da parte del client:
codice:
# Inbound Internet Packet Rules
# Accept Established Connections
$IPT -A INPUT -p ALL -i $INET_IFACE -m state --state ESTABLISHED,RELATED -j ACCEPT
for X in $DMZ_IFACE; do $IPT -A INPUT -p ALL -i $X -m state --state ESTABLISHED,RELATED -j ACCEPT; done;
codice:
###############################################################################
#
# FORWARD Chain
#
echo "Process FORWARD chain ..."
# Used if forwarding for a private network
# Drop bad packets
$IPT -A FORWARD -p ALL -j bad_packets
# Accept TCP packets we want to forward from internal sources
#$IPT -A FORWARD -p tcp -i $LOCAL_IFACE -j tcp_outbound
for X in $INSIDE_IFACE; do $IPT -A FORWARD -p tcp -i $X -j tcp_outbound; done;
# Accept UDP packets we want to forward from internal sources
#$IPT -A FORWARD -p udp -i $LOCAL_IFACE -j udp_outbound
for X in $INSIDE_IFACE; do $IPT -A FORWARD -p udp -i $X -j udp_outbound; done;
# If not blocked, accept any other packets from the internal interface
#$IPT -A FORWARD -p ALL -i $LOCAL_IFACE -j ACCEPT
for X in $INSIDE_IFACE; do $IPT -A FORWARD -p ALL -i $X -j ACCEPT; done;
# Deal with responses from the internet
$IPT -A FORWARD -i $INET_IFACE -m state --state ESTABLISHED,RELATED -j ACCEPT
for X in $DMZ_IFACE; do $IPT -A FORWARD -p ALL -i $X -m state --state ESTABLISHED,RELATED -j ACCEPT; done;
Queste sopra riportate sono le uniche modifiche strettamente necessarie. Volendo si possono applicare anche le seguenti:
codice:
# sshd
for X in $TRUSTED_NET; do $IPT -A tcp_inbound -p TCP -s $X --destination-port 22 -j ACCEPT; done;
# User specified allowed TCP protocol
# Webmin
for X in $TRUSTED_NET; do $IPT -A tcp_inbound -p TCP -s $X --destination-port 15000 -j ACCEPT; done;