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

Pagina 1 di 3 1 2 3 ultimo
Visualizzazione dei risultati da 1 a 10 su 26
  1. #1
    Super Moderatore L'avatar di frakka
    Registrato
    May 2001
    Località
    Casalecchio di Reno (Bo)
    Età
    38
    Messaggi
    22,119
    configurazione

    Predefinito [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:








    Ultima modifica di frakka : 17-06-2012 a 16:12


    Questa è la storia di 4 persone chiamate Ognuno, Qualcuno, Ciascuno e Nessuno. C'era un lavoro importante da fare e Ognuno era sicuro che Qualcuno lo avrebbe fatto. Ciascuno poteva farlo, ma Nessuno lo fece, Qualcuno si arrabbiò perché era il lavoro di Ognuno. Ognuno pensò che Ciascuno potesse farlo, ma Ognuno capì che Nessuno l'avrebbe fatto. Finì che Ognuno incolpò Qualcuno perché Nessuno fece ciò che Ciascuno avrebbe potuto fare.

  2. #2
    Super Moderatore L'avatar di frakka
    Registrato
    May 2001
    Località
    Casalecchio di Reno (Bo)
    Età
    38
    Messaggi
    22,119
    configurazione

    Predefinito

    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.
    Ultima modifica di frakka : 16-06-2012 a 01:02


    Questa è la storia di 4 persone chiamate Ognuno, Qualcuno, Ciascuno e Nessuno. C'era un lavoro importante da fare e Ognuno era sicuro che Qualcuno lo avrebbe fatto. Ciascuno poteva farlo, ma Nessuno lo fece, Qualcuno si arrabbiò perché era il lavoro di Ognuno. Ognuno pensò che Ciascuno potesse farlo, ma Ognuno capì che Nessuno l'avrebbe fatto. Finì che Ognuno incolpò Qualcuno perché Nessuno fece ciò che Ciascuno avrebbe potuto fare.

  3. #3
    Super Moderatore L'avatar di frakka
    Registrato
    May 2001
    Località
    Casalecchio di Reno (Bo)
    Età
    38
    Messaggi
    22,119
    configurazione

    Predefinito 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.
    Ultima modifica di frakka : 16-06-2012 a 01:58


    Questa è la storia di 4 persone chiamate Ognuno, Qualcuno, Ciascuno e Nessuno. C'era un lavoro importante da fare e Ognuno era sicuro che Qualcuno lo avrebbe fatto. Ciascuno poteva farlo, ma Nessuno lo fece, Qualcuno si arrabbiò perché era il lavoro di Ognuno. Ognuno pensò che Ciascuno potesse farlo, ma Ognuno capì che Nessuno l'avrebbe fatto. Finì che Ognuno incolpò Qualcuno perché Nessuno fece ciò che Ciascuno avrebbe potuto fare.

  4. #4
    Super Moderatore L'avatar di frakka
    Registrato
    May 2001
    Località
    Casalecchio di Reno (Bo)
    Età
    38
    Messaggi
    22,119
    configurazione

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



    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.


    Questa è la storia di 4 persone chiamate Ognuno, Qualcuno, Ciascuno e Nessuno. C'era un lavoro importante da fare e Ognuno era sicuro che Qualcuno lo avrebbe fatto. Ciascuno poteva farlo, ma Nessuno lo fece, Qualcuno si arrabbiò perché era il lavoro di Ognuno. Ognuno pensò che Ciascuno potesse farlo, ma Ognuno capì che Nessuno l'avrebbe fatto. Finì che Ognuno incolpò Qualcuno perché Nessuno fece ciò che Ciascuno avrebbe potuto fare.

  5. #5
    Super Moderatore L'avatar di frakka
    Registrato
    May 2001
    Località
    Casalecchio di Reno (Bo)
    Età
    38
    Messaggi
    22,119
    configurazione

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


    Questa è la storia di 4 persone chiamate Ognuno, Qualcuno, Ciascuno e Nessuno. C'era un lavoro importante da fare e Ognuno era sicuro che Qualcuno lo avrebbe fatto. Ciascuno poteva farlo, ma Nessuno lo fece, Qualcuno si arrabbiò perché era il lavoro di Ognuno. Ognuno pensò che Ciascuno potesse farlo, ma Ognuno capì che Nessuno l'avrebbe fatto. Finì che Ognuno incolpò Qualcuno perché Nessuno fece ciò che Ciascuno avrebbe potuto fare.

  6. #6
    Super Moderatore L'avatar di frakka
    Registrato
    May 2001
    Località
    Casalecchio di Reno (Bo)
    Età
    38
    Messaggi
    22,119
    configurazione

    Predefinito 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


    Questa è la storia di 4 persone chiamate Ognuno, Qualcuno, Ciascuno e Nessuno. C'era un lavoro importante da fare e Ognuno era sicuro che Qualcuno lo avrebbe fatto. Ciascuno poteva farlo, ma Nessuno lo fece, Qualcuno si arrabbiò perché era il lavoro di Ognuno. Ognuno pensò che Ciascuno potesse farlo, ma Ognuno capì che Nessuno l'avrebbe fatto. Finì che Ognuno incolpò Qualcuno perché Nessuno fece ciò che Ciascuno avrebbe potuto fare.

  7. #7
    Super Moderatore L'avatar di frakka
    Registrato
    May 2001
    Località
    Casalecchio di Reno (Bo)
    Età
    38
    Messaggi
    22,119
    configurazione

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



    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.



    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.


    Questa è la storia di 4 persone chiamate Ognuno, Qualcuno, Ciascuno e Nessuno. C'era un lavoro importante da fare e Ognuno era sicuro che Qualcuno lo avrebbe fatto. Ciascuno poteva farlo, ma Nessuno lo fece, Qualcuno si arrabbiò perché era il lavoro di Ognuno. Ognuno pensò che Ciascuno potesse farlo, ma Ognuno capì che Nessuno l'avrebbe fatto. Finì che Ognuno incolpò Qualcuno perché Nessuno fece ciò che Ciascuno avrebbe potuto fare.

  8. #8
    Super Moderatore L'avatar di frakka
    Registrato
    May 2001
    Località
    Casalecchio di Reno (Bo)
    Età
    38
    Messaggi
    22,119
    configurazione

    Predefinito 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;
    Ultima modifica di frakka : 20-12-2012 a 01:02


    Questa è la storia di 4 persone chiamate Ognuno, Qualcuno, Ciascuno e Nessuno. C'era un lavoro importante da fare e Ognuno era sicuro che Qualcuno lo avrebbe fatto. Ciascuno poteva farlo, ma Nessuno lo fece, Qualcuno si arrabbiò perché era il lavoro di Ognuno. Ognuno pensò che Ciascuno potesse farlo, ma Ognuno capì che Nessuno l'avrebbe fatto. Finì che Ognuno incolpò Qualcuno perché Nessuno fece ciò che Ciascuno avrebbe potuto fare.

  9. #9
    Super Moderatore L'avatar di frakka
    Registrato
    May 2001
    Località
    Casalecchio di Reno (Bo)
    Età
    38
    Messaggi
    22,119
    configurazione

    Predefinito 5_ Test e verifiche.

    Le verifiche da fare sono relativamente semplici:

    E' sufficiente connettere un client prima in DHCP alla rete wireless "privata" e verificare il corretto funzionamento del client DHCP, l'aggiornamento del DNS e la possibilità di accedere al server, sia alle share di rete che agli altri eventuali servizi. E' poi necessario verificare il corretto funzionamento del forwarding verso internet e la risoluzione DNS, verificando sia che sia possibile ottenere la risoluzione degli host internet ma anche quella della rete locale. E' poi sufficiente cambiare manualmente l'indirizzo IP del client connesso alla rete wireless per verificare che la restrizione di provenienza impostata nella "bad_packets chain" funzioni come previsto.

    Gli stessi test devono poi essere ripetuti con il client connesso alla rete "ospiti" ma in questo caso gli deve essere negato tutto, tranne la normale navigazione internet e la risoluzione dei nomi dai DNS pubblici.
    In questo caso specifico, nel caso ci si connetta alla rete "open" con un IP statico della classe appartenente alla rete "WIRED" si riscontra il punto debole di questa configurazione: E' vero che non è comunque permesso l'accesso diretto ai client della rete locale per via della restrizione imposta con la "bad_packets chain" ma è comunque possibile accedere all'interfaccia di amministrazione dell'access point, se l'IP è noto.

    Una password debole per l'acceso a questa interfaccia permetterebbe a chiunque di accedere alla configurazione del AP e (ad esempio) scambiare i TAG delle due VLAN, oppure applicare lo stesso TAG anche alla VLAN open, configurazione che permetterebbe di ottenere l'accesso senza password alle reti "trusted". Questo effetto indesiderato non è in alcun modo evitabile purtroppo: L'unica difesa possibile (dato che non è possibile disabilitare l'accesso alla configurazione del dispositivo via wireless) è adottare una password "sicura" per la configurazione del dispositivo TP-Link. E' un peccato che non abbiamo implementato questa funzionalità perchè con pochissimo sforzo avrebbe reso il dispositivo quasi perfetto.
    Forse l'aggiornamento al firmware OpenWRT permette di porre rimedio a questa limitazione ed all'impossibilità di scegliere di trasmettere solo specifici SSID ma non ho ancora avuto modo di testarlo.

    Per il resto, ho riscontrato in tutto il funzionamento atteso.
    Ultima modifica di frakka : 01-11-2012 a 13:11


    Questa è la storia di 4 persone chiamate Ognuno, Qualcuno, Ciascuno e Nessuno. C'era un lavoro importante da fare e Ognuno era sicuro che Qualcuno lo avrebbe fatto. Ciascuno poteva farlo, ma Nessuno lo fece, Qualcuno si arrabbiò perché era il lavoro di Ognuno. Ognuno pensò che Ciascuno potesse farlo, ma Ognuno capì che Nessuno l'avrebbe fatto. Finì che Ognuno incolpò Qualcuno perché Nessuno fece ciò che Ciascuno avrebbe potuto fare.

  10. #10
    Moderatore L'avatar di betaxp86
    Registrato
    May 2003
    Località
    Genova, Italy
    Età
    32
    Messaggi
    10,196

    Predefinito

    Complimenti per la guida, in molte occasioni ci si ritrova a dover configurare cose simili in ambito aziendale e alcuni admin non si sanno neanche da dove partire
    betaxp86


Pagina 1 di 3 1 2 3 ultimo

Informazioni Thread

Users Browsing this Thread

Ci sono attualmente 1 utenti che stanno visualizzando questa discussione. (0 utenti e 1 ospiti)

Tags

Regole d'invio

  • Non puoi inserire discussioni
  • Non puoi inserire repliche
  • Non puoi inserire allegati
  • Non puoi modificare i tuoi messaggi
  •  
nexthardware.com - © 2002-2018

Search Engine Optimization by vBSEO 3.6.1