[WORKLOG] - Creare e gestire reti wireless con SSID multipli su Tp-Link TL-WA701ND, mantenendo le reti separate.

[frakka]

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:

• 1_ Configurazione del server per gestire sulla interfaccia “inside” le nuove VLAN;

• 2_ Configurazione dell'AP per gestire i due SSID ed associarli ad una VLAN;

• 3_ Configurazione del servizio DHCP e DynamicDNS.
  
  3a_ Configurazione degli scope DHCP;
  3b_ Configurazione delle zone DNS e Dynamic DNS;
  3c_ Verifica di funzionamento.

• 4_ Configurazione del firewall del server/router per segregare le reti;

• 5_ Test e verifiche.

[frakka]

La complessità maggiore da affrontare per per realizzare questo impianto è ottenere la segregazione delle reti che mi sono prefisso: Ho un unico access point, dotato di una sola interfaccia 10/100 e tutte le reti fanno capo allo stesso switch (un Netgear da 40€ non gestibile) ed alla stessa presa ethernet eth1 del mio serverino domestico. La separazione che voglio ottenere, quindi, non può essere ottenuta a livello “fisico” (adottando cioè dei circuiti fisicamente separati) ma deve essere implementata a livello completamente logico.

Una caratteristica non comune per la fascia di prezzo del Tp-Link, è proprio il supporto alle VLAN un protocollo di rete che permette di realizzare una serie di reti LAN indipendenti tra loro ma che condividono lo stesso rame (o meglio, "mezzo fisico") per la trasmissione dei dati. Non tutti i dispositivi di fascia home supportano questo protocollo e per una implementazione piena è necessario che tutti i dispositivi che costituiscono la rete (router, switch, client) lo supportino ma sono fortunato e nel mio caso il circuito sembra funzionare bene lo stesso anche con un'implementazione limitata al solo server/gateway ed access point.

Una VLAN prevede un “ID” con cui i pacchetti che appartengono a questa rete vengono “taggati”. Come detto, perchè il circuito funzioni a dovere è necessario che tutti i componenti riconoscano correttamente il TAG della VLAN, cosa non del tutto scontata soprattutto in ambito domestico.
In un circuito completamente “VLAN Compliant” il tag è sufficiente a garantire la segregazione voluta perchè i pacchetti vengono instradati solo sulle interfacce e sulle porte "taggate" con un VID (VLAN ID) corrispondente al TAG della VLAN.
Nel caso la porta dello switch sia configurata per portare sia VLANs che normale traffico non taggato, è definita "idriba": In questo caso, se il supporto al protocollo VLAN dei dispositivi client/switch connessi alla porta è carente, si rende necessario adottare qualche artificio supplementare anche perchè in questo caso il funzionamento della rete non è scontato.



Nota:
Ho realizzato il circuito in fretta e furia, quindi è sicuramente perfettibile non esente da errori. Se qualcuno notasse imprecisioni o errori sarei grato lo facesse notare.

[frakka]

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:

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:

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:

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:

[...]
# 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:

# 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:

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:

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:

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.

[frakka]

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.



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€...





Salvare e riavviare l'AP per applicare le modifiche.

[frakka]

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:

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:

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.

[frakka]

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:

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:

sudo /etc/init.d/bind9 restart
sudo /etc/init.d/isc-dhcp-server restart

[goldenmaker]

ciao Frakka..io sto impazzendo che vorrei dividere la rete....ma nella schermata del mio TL-WR841N nella casella Wireless settings, non mi appare la casella dove selezionare il multi ssid...come mai? Sul sito riporta che lo posso fare con il mio tp link....devo usare una'altra versione di non so cosa o come posso fare? Grazie!!!

[frakka]

Ciao.
Ma sei sicuro che il tuo dispositivo supporti la modalità wireless "Multi-SSID Mode"? Qui non mi pare ci sia nulla in merito...

Probabilmente potresti risolvere sostituendo il firmware originale con openwrt. L'operazione, ovviamente, ne invalida l'eventuale garanzia. Il flash potrebbe inoltre non essere propriamente immediato soprattutto perchè di default non ha una interfaccia grafica di gestione. Ti consiglio di leggere tutta la guida prima di provare a fare qualunque cosa.

[dafrasaga]

...........
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.

Ciao, lavoro encomiabile
pure io verrei implementare qualcosa di simile, ma ho un dobbio..._:

ma se lo switch unmanaged che non gestisce le vlan è posto tra la rete privata e il firewall/server.... a cosa serve impostare le regole sul firewall del server?? Se io con un pc connesso alla wifi guest con ip valido, essendo già di per se sullo switch (che ripeto non gestische le vlan) posso sempre connettermi ad una macchina sulla rete privata dove non è impostato nessun firewall? Giusto ho nonho capito la tua rete??

Grazie

[frakka]

Grazie.
Il caso che hai indicato è un pò quello che ho indicato per l'AP, al punto 5 ed è il motivo per cui ho configurato subnet diverse per ogni interfaccia (cablata, wireless privata e wireless pubblica).

Testando la configurazione, i casi che mi sono venuti in mente sono i seguenti:
- Il client ottiene l'IP dal DHCP e quindi usa la configurazione di rete che ho previsto per la rete wireless pubblica: Dato che per accedere ad una subnet diversa (rete cablata o wireless privata) il pacchetto IP deve necessariamente transitare attraverso un gateway, le regole impostate sul gateway/firewall lasciano passare solo i pacchetti della rete wireless pubblica diretti verso internet, tutto il resto viene droppato.

- Il client si collega alla wireless pubblica e usa un IP statico, ad esempio, appartenente alla rete cablata o alla wireless privata: In questo caso, il suo pacchetto IP è taggato dall'AP come appartenente alla rete wireless pubblica. I client delle reti tagged non lo riconoscono come appartenente alla propria rete in quanto provvisto di un tag diverso. L'unico modo di accedere alla rete privata è quindi quella di accedere al gateway/firewall ma una delle regole impostate droppa tutti i pacchetti in ingresso/forward su una specifica interfaccia se la configurazione IP del pacchetto è diversa da quella che ho configurato.

In questa configurazione lo switch è effettivamente il punto debole: E' pertanto possibile che qualche client connesso alla rete cablata untagged risulti comunque raggiungibile e sia esposto ad un qualche tipo di attacco: Come detto, perchè le VLAN funzionino a puntino è necessario il completo supporto da parte di tutti i componenti collegati alla rete. Un ulteriore livello di sicurezza potrebbe essere semplicemente l'implementazione dei TAG sulla rete cablata e sulle schede di rete dei singoli client ad essa connessi.
Dai test che ho fatto, i miei pc di casa (Win7, win8 con firewall di Windows attivato e Linux) non risultano raggiungibili al normale PING e non ho mai avuto problemi con l'assegnazione degli indirizzi IP dal DHCP, segno che anche il traffico di broadcast è gestito sufficientemente bene.