[Ninux-Calabria] [Hacklab-Cosenza] CI e supernetting

[Vincenzo Pirrone]

Il 08/02/2014 13:55, Giuseppe De Marco ha scritto:
> 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.

Non avevo pensato a questo aspetto..non è un problema trascurabile,
dobbiamo pensare a un'altra soluzione

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

Aggiungo anche che è possibile annunciare un default gateway con gli
Hna4 di olsr (la subnet da annunciare è 0.0.0.0/0), in questo caso il
gateway è pubblico e non c'è bisogno di usare tunnel.

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

Secondo me è meglio criptato, ricordiamoci che su ninux è facile
sniffare il traffico, senza contare la presenza di eventuali nodi
malevoli. Inoltre credo che l'overhead sia trascurabile.

> 
> Io penso che si possa dare la possibilità agli utenti di scegliere.

Assolutamente si

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

Si, tra l'altro uno può crearsi un tunnel dal proprio PC da qualunque
punto della rete verso la sua lan.
Però il captive portal è più user-friendly e incorpora anche contenuto
informativo. Credo che l'utilizzo del captive portal si sposi bene coi
gateway pubblici sopracitati (dovrebbe funzionare giusto?)


> 
>     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
> 
> 
> 
> 
> _______________________________________________
> Hacklab-Cosenza mailing list
> Hacklab-Cosenza a autistici.org
> https://www.autistici.org/mailman/listinfo/hacklab-cosenza
> 


-- 
Vincenzo Pirrone
Twitter: @spax_arm
PGP Key ID: 5CF5047D

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