[Ninux-Calabria] NewSpig Client Isolation

[Stefano De Carlo]

Il 25/01/2014 20:58, Vincenzo Pirrone ha scritto:
> Per i nodi su cui è installato olsrd questo non crea alcun problema, la
> rete funzionerà meglio di prima. I drawback sono essenzialmente 2:
> * No OLSR no party
> * Non è possibile impostare manualmente un nodo come default gateway
>
> Visto che alcuni nodi usano Verde come default gateway per ora abbiamo
> deciso in accordo con Peppe e Stefano di non abilitare la CI e di
> discuterne a riguardo.

Bene, ho passato ieri pomeriggio a rendere incontrovertibile che se c'è
del lavoro da fare, preferisco vada in direzione dell'adeguamento di
tutti i nodi ad OLSR piuttosto che al supporto di soluzioni legacy che
non scalano.

Nell'ipotesi che si voglia effettivamente far convivere nodi OLSR e nodi
non-OLSR, forse c'è un modo in cui possiamo implementarli
- entrambi
- contemporaneamente
e progressivamente transizionare a comando verso la soluzione a nodi
tutti-OLSR.

Wireless VLAN Trunking/Passthrough?

Ipotesi: un nuovo supernodo, simil-SPIG, con routing a terra (non la
versione attuale, ma quella già pronta, riveduta e corretta, con le VLAN).
Come descritto il mese scorso [1] il routing a terra prevede una doppia
VLAN, una delle quali (eth0.3) di traffico OLSR che viene bridgiata
(bridge0) con la WLAN. L'altra è di management (eth0.7)
Noi potremmo aggiungere una sovrastruttura così composta:

1) Una ULTERIORE VLAN sulle interfacce dell'antenna (wlan0.99 e eth0.99)
e router a terra (eth0.99)
2) bridgiare (bridge1) wlan0.99 e eth0.99 sull'antenna.
3) Associare il bridge1 alla VLAN (per il momento tralasciamo come).
4) Sul router a terra assegnare a questa VLAN indirizzi 10.87.254.0/24
5) Si fanno collegare i nodi stupidi in DHCP al Virtual SSID associato a
10.87.254.0/24.
6) Annunciare 10.87.254.0/24 come HNA4 su OLSR.
 
Elucubrazioni:

La #1 e la #2 mirrorano quanto abbiamo fatto col routing a terra e le
antenne in bridge, ma per una ulteriore VLAN. La presenza del .99 sulla
WLAN è più che altro per identificare concettualmente la necessità di 2
bridge che coinvolgono il wireless.

La #3 è la parte decisiva. Se per il momento ipotizziamo che sia un
bridge tutto wired, il bridge tagga-untagga a seconda delle porte che ne
fanno parte e della direzione, come ben sappiamo.
Ma nel wireless, da standard 802.11, di tag VLAN non ne possono passare
(VLAN passthrough). A prescindere dal tag (vorremmo mantenere tutto
untagged lato CPE, comunque), abbiamo bisogno di far si che il traffico
in ingresso sul wifi dell'antenna venga inoltrato verso la corretta VLAN
impostata negli ultimi 3 punti. Per far questo, in sostanza, l'antenna
ha bisogno di un modo per agire da tipico bridge linux wired come sopra
descritto.
Credo si possa fare. Ci sono due modalità mooooolto diverse sul tavolo
della sperimentazione:

A) Se AP e STA sono impostati in WDS transparent bridging (WDS-AP, WDS),
in realtà iniettare tag vlan sul wireless è supportato, almeno da quasi
tutte le implementazioni WDS. Si tratta di bridge L2 liscio liscio. In
questa modalità, l'unica cosa da fare è impostare le VLAN desiderate su
ambedue le interfacce e i bridge appositi, e chi s'è visto s'è visto.

B) Senza il WDS, la cosa è per forza di cose più circonvoluta. Bisogna
creare dei VirtualAP/SSID, uno per ogni VLAN, e associarli ai bridge
descritti in #1 e #2 e di conseguenza alle VLAN. In pratica, le VLAN
desiderate vengono create/ricreate dinamicamente dall'antenna in base al
SSID di ricezione. Come se gli SSID virtuali corrispondessero ad una
native VLAN di quella "porta wireless".

La #4 #5 #6 realizzano quella che è, in sostanza, una HNA4 distribuita
sul territorio. E come sappiamo le HNA4 sono l'unico posto dove non
serve che si faccia parlare OLSR. Vi torna?
La complessità dell'AP è ovvio che aumenterebbe, a tutto vantaggio dei
nodi foglia che possono rimanere beceramente ignoranti (DHCP! Roba da
figli unici).
Ovviamente in questo scenario i nodi stupidi, pur essendo link wireless,
non verrebbero disegnati dal map server, sarebbero visti come una
risorsa locale dell'AP.

Ovviamente, dò per scontato che la Client Isolation sia singolarmente
attivabile sui vAP essendo praticamente una semplice regola di ebtables
(Spax, sembrerebbe proprio così [2]). Uniti questi pezzi, tutto dovrebbe
tornare.

Nell'ipotesi che si volesse sperimentare questa soluzione bisogna prima
di tutto dimostrare che funziona a livello concettuale. Per far questo
si potrebbe sfruttare un openwrt, e il suo essere un linux liscio
ultraflessibile, per simulare una CPE.
Se funziona, si tratterebbe, ammesso che sia possibile, tradurre la
configurazione in Ubiquitese. Molto difficile, specie considerando che
alcune i VirtualAP non sono supportati (sono una delle feature più
richieste per AirOS 6) e non è detto che la CI sia attivabile per-SSID.
Si può ovviare con config a mano e poi scriptate, ma con tutti i rischi
del caso.

Come vedete, per fare le cose per bene (scalabili, transizionabili), è
tantissimo lavoro, tutt'altro che KISS.
Lasciamo perdere * e abbracciamo OLSR ovunque,

Stefanauss.

[1] http://ml.ninux.org/pipermail/calabria/2013-December/002328.html
[1] http://ml.ninux.org/pipermail/calabria/2013-December/002332.html
[2]
https://security.stackexchange.com/questions/16751/wireless-client-isolation-how-does-it-work-and-can-it-be-bypassed

* Ma prima o poi VOGLIO provare.

-------------- parte successiva --------------
Un allegato non testuale è stato rimosso....
Nome:        signature.asc
Tipo:        application/pgp-signature
Dimensione:  836 bytes
Descrizione: OpenPGP digital signature
URL:         <http://ml.ninux.org/pipermail/calabria/attachments/20140127/2786da1c/attachment-0001.sig>