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

Dom 9 Feb 2014 09:01:36 CET

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Il giorno 08/feb/2014, alle ore 16.23, Vincenzo Pirrone ha scritto:

> 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.
+1 
> 
>> 
>> 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
> 
> _______________________________________________
> Calabria mailing list
> Calabria a ml.ninux.org
> http://ml.ninux.org/mailman/listinfo/calabria

-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.22 (Darwin)
Comment: GPGTools - https://gpgtools.org

iQEcBAEBCgAGBQJS9zXrAAoJED47xTEp3BoDSvwH/jMRNAD9cpVIBi55lLVwRQ3/
8w4P9xtbYX8/uJw65NxBrYGuy5hoj3ye9l/qX76lfOo242M+Zt/MVxuVCKULkr9e
Uypw/gmXBqG+XpcDbNzDc+apASrBV1PEenogngAnoT1LG/wYth9uRKaJXzl/lxoR
uE1BBfNzxt73wq01aKQ8hgDzUtyxGQY5xZAQbBIgW3VyJa4ozvcMe5ZVvuuPQj8r
lDvXT2uiOOUzw0ukj2mkOMWxcRzFM+mOafRcVkX/3gQWjTNB003lQoa3DTUuDFxr
bfZj3p/B+wHvh49JRW7I/BLB1ZbqgWA2tPMkYr/x4uhrde6hKfyKpbssgtqTMtY=
=uKZR
-----END PGP SIGNATURE-----