[Ninux-Calabria] CI e supernetting

[Giuseppe De Marco]

Sulle esperienze di http proxy + splash screen a Verde Binario:

Squid sulla rasp va bene.
L'unica costrizione è in merito alle connessioni SSL, come descritto quì:
http://wiki.squid-cache.org/Features/HTTPS#Direct_SSL.2BAC8-TLS_connection_to_a_reverse_proxy

Il discorso sarebbe che il proxy trasparente non può trattare traffico
criptato senza fare man-in-the-middle sui certificati, questo annullerebbe
tutti i controlli di autorevolezza facendo emergere "Allontanarsi da questo
sito"... Altri trick comprendono l'uso di tunnels.

Come rete mesh ci siamo resi conto che OLSR, a causa dello spanning tree
[1] del layer2 (traffico ARP) produce troppe rotte.

L'incremento di calcolo computazionale ripartito per ogni router non è un
problema, secondo me, mentre ci sono alcuni aspetti interessanti derivanti
dall'uso di Client Isolarion che ci stanno convincendo ad adottarla:

. La client isolation disattiva il calcolo dello SpanningTree e consente
layer2 solo con l'AP
. Ogni tentativo di ARPSpoofing classico verrebbe naturalmente neutralizzato
. Risparmio di almeno il 2,5% della banda disponibile, derivato
dall'assenza di ARP

Questa configurazione però non consente a, ad esempio, 172.17.87.10 di
avere come gateway 172.17.87.13, i due non comunicano più in LAN (no
layer2).

172.17.87.10 deve avere come gateway esclusivamente il proprio AP,
172.17.87.3 (newSPIG).
l'AP fà da router verso altre reti, pertanto 172.17.87.10 avrà tutte le
rotte dei 10.87.x.0/24 e le altre reti annunciate.

Pertanto niente default gateway per supernetting, per stabilire un
collegamento layer2 con uno o più nodi e sfruttare la possibilità di usare
un default gateway sarà doveroso impiegare dei tunnels.

I Tunnels: classici, GRE o criptati (VPN).
L'uso di un Tunnel criptato introdurrebbe una soluzione al traffico in
chiaro attuale di Ninux.
L'uso di un Tunnel in chiaro ridurrebbe l'over-head di rete.

Io penso che si possa dare la possibilità agli utenti di scegliere.
I tunnels possono essere "automatizzati" nell'OpenWRT dei routers o creati
sulle Workstation mediante clients o configurazioni. I gradi di liberta non
mancano.

Tipo la VPN di riseup + tunnel in chiaro alternativi, erogati come servizio
Ninux.

LA cosa carina è quella di poter fare pagine web promozionali dove
illustriamo il progetto locale - come Ninux Calabria - e brandizziamo :)

Inerninux: Hai pensato di produrre applicazioni client per tunneling con
banners come piacciono a te ?

[1] http://it.wikipedia.org/wiki/Spanning_tree_(networking)


Il giorno 08 febbraio 2014 12:53, Giuseppe De Marco
<demarcog83 a gmail.com>ha scritto:

> Ragazzi,
> come discusso precedentemente in HL:
>
> Con l'approssimarsi della CI dobbiamo abbandonare i gateway su 172, perchè
> non abbiamo più spanning tree layer2.
>
> Di conseguenza l'unica maniera per "dialogare" con un host di un'altra
> rete, come se fosse in rete locale, è quello di creare tunnels.
>
> Criptati o meno non ci interessa, dovremmo cmq consentire entrambi, sulla
> base delle esigenze singole.
>
> A questo sarebbe il caso di armonizzare con i progetti di captive portal
> in corso.
> Mi chiedo:
>
> MA se l'utente deve fare un tunnel o avviare una applicazione per
> crearsene uno (tipo openVPN e soci), non basterebbe questo a definire una
> forma di autenticazione ?
>
> PErchè chi ha il certificato, o i parametri, per creare il tunnel è un pò
> come se aderisse alle regole che determinano la rete tunnelata.
>
> Sviluppiamo il discorso e cerchiamo una visione condivisa
>
-------------- parte successiva --------------
Un allegato HTML è stato rimosso...
URL: <http://ml.ninux.org/pipermail/calabria/attachments/20140208/f2363336/attachment.htm>