<div dir="ltr">Nuovo mese rinnovo di topic :)<div><br></div><div>Sulle esperienze di http proxy + splash screen:</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>C'è inoltre un'altro topic che influenza il nostro Captive, sulla lista <a href="mailto:Calabia@ninux.org">Calabia@ninux.org</a>, inerente alla Client Isolation che spiego di seguito:</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 la navigazione Internet, 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 possono essere 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 bisogna 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.</div>
<div><br></div><div>Mi chiedo e vi chiedo, la "sottoscrizione" al disclamier della pagina captive potrebbe essere sostituita da una pagina web, su webfaction, dove illustriamo il progetto e facciamo scaricare agli utenti i certificati o lo script/programma per usare l'internet sociale ?</div>
<div><br></div><div>Tipo la VPN di riseup + tunnel in chiaro alternativi.</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><br>
</div></div>