<div dir="ltr"><div>Sulle esperienze di http proxy + splash screen a Verde Binario: <br></div><div><br></div><div>Squid sulla rasp va bene.</div><div>L'unica costrizione è in merito alle connessioni SSL, come descritto quì:</div>
<div><a href="http://wiki.squid-cache.org/Features/HTTPS#Direct_SSL.2BAC8-TLS_connection_to_a_reverse_proxy">http://wiki.squid-cache.org/Features/HTTPS#Direct_SSL.2BAC8-TLS_connection_to_a_reverse_proxy</a><br></div><div>
<br></div><div>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.</div>
<div><br></div><div>Come rete mesh ci siamo resi conto che OLSR, a causa dello spanning tree [1] del layer2 (traffico ARP) produce troppe rotte. </div><div><br></div><div>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:</div>
<div><br></div><div>. La client isolation disattiva il calcolo dello SpanningTree e consente layer2 solo con l'AP</div><div>. Ogni tentativo di ARPSpoofing classico verrebbe naturalmente neutralizzato</div><div>. Risparmio di almeno il 2,5% della banda disponibile, derivato dall'assenza di ARP</div>
<div><br></div><div>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).</div><div><br></div><div>172.17.87.10 deve avere come gateway esclusivamente il proprio AP, 172.17.87.3 (newSPIG).</div>
<div>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.</div><div><br></div><div>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.</div>
<div><br></div><div>I Tunnels: classici, GRE o criptati (VPN).</div><div>L'uso di un Tunnel criptato introdurrebbe una soluzione al traffico in chiaro attuale di Ninux.</div><div>L'uso di un Tunnel in chiaro ridurrebbe l'over-head di rete.</div>
<div><br></div><div>Io penso che si possa dare la possibilità agli utenti di scegliere.</div><div>I tunnels possono essere "automatizzati" nell'OpenWRT dei routers o creati sulle Workstation mediante clients o configurazioni. I gradi di liberta non mancano.</div>
<div><br></div><div>Tipo la VPN di riseup + tunnel in chiaro alternativi, erogati come servizio Ninux.<br></div><div><br></div><div>LA cosa carina è quella di poter fare pagine web promozionali dove illustriamo il progetto locale - come Ninux Calabria - e brandizziamo :)</div>
<div><br></div><div>Inerninux: Hai pensato di produrre applicazioni client per tunneling con banners come piacciono a te ?</div><div><br></div><div>[1] <a href="http://it.wikipedia.org/wiki/Spanning_tree_(networking)">http://it.wikipedia.org/wiki/Spanning_tree_(networking)</a></div>
<div class="gmail_extra"><br><br><div class="gmail_quote">Il giorno 08 febbraio 2014 12:53, Giuseppe De Marco <span dir="ltr"><<a href="mailto:demarcog83@gmail.com" target="_blank">demarcog83@gmail.com</a>></span> ha scritto:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Ragazzi, <div>come discusso precedentemente in HL:</div><div><br></div><div>Con l'approssimarsi della CI dobbiamo abbandonare i gateway su 172, perchè non abbiamo più spanning tree layer2.</div>
<div><br>
</div><div>Di conseguenza l'unica maniera per "dialogare" con un host di un'altra rete, come se fosse in rete locale, è quello di creare tunnels.</div><div><br></div><div>Criptati o meno non ci interessa, dovremmo cmq consentire entrambi, sulla base delle esigenze singole.</div>
<div><br></div><div>A questo sarebbe il caso di armonizzare con i progetti di captive portal in corso.</div><div>Mi chiedo:</div><div><br></div><div>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 ?</div>
<div><br></div><div>PErchè chi ha il certificato, o i parametri, per creare il tunnel è un pò come se aderisse alle regole che determinano la rete tunnelata.</div><div><br></div><div>Sviluppiamo il discorso e cerchiamo una visione condivisa</div>
</div>
</blockquote></div><br></div></div>