[Ninux-Calabria] NewSpig Client Isolation

Giuseppe De Marco demarcog83 a gmail.com
Lun 27 Gen 2014 20:36:26 UTC


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

il lavoro da fare per l'adeguamento dei nodi è il seguente:

ARI dovrebbe "entrare" meglio nel funzionamento di Ninux e ecocasa dovrebbe
giusto completare i lavori che stiamo rimandando da un mese.


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

LA via di mezzo per "affiancare" i nodi dumb potrebbe essere quella di
annunciare le rotte anche per loro. Ma suona quasi inutile visti gli
obiettivi.


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

Ottimo


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

Mi piace il 99 :)


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

Bello


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

Decisamente


> La complessità dell'AP è ovvio che aumenterebbe, a tutto vantaggio dei
> nodi foglia che possono rimanere beceramente ignoranti (DHCP! Roba da
> figli unici).
>

In questo caso la client isolation avrebbe lo stesso effetto senza vlan.
Sai, dal punto di vista della sicurezza non ha eguali e forza uno standard,
è un ragionamento impeccabile. Pare che come la giri giri si torna sempre
lì, e penso vada fatto.


> 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
>
>
>
Non lo sò cosa succederà, per questo penso ad una rete a 2 livelli.
Purtroppo, sul lungo periodo, risulterebbe più svantaggiosa per la
gestione, mentre un'unico standard dovrebbe andare.

In questo caso il costo di installazione sarebbe circa 130€ incluso router
da flashare.
Gigismi potrebbe compilare il firmware del Ninux start-kit e potremmo
creare una pagina dove spiegare come fare il primo nodo di ninux. In questo
caso eviteremmo totalmente i nodi dumb, perchè questi sin da principio
verrebbero istruiti all'ingresso.

In questo caso passeremmo alla CI anche in questa settimana, tutte le
antenne possono essere configurate da remoto e con un paio di telefonate
potremmo coinvolgere qualcuno in più :)
-------------- parte successiva --------------
Un allegato HTML è stato rimosso...
URL: <http://ml.ninux.org/pipermail/calabria/attachments/20140127/d721a7b2/attachment.htm>


Maggiori informazioni sulla lista Calabria