[Verdebinario] Ninux

[Giuseppe De Marco]

Nuovo mese rinnovo di topic :)

Sulle esperienze di http proxy + splash screen:

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.

C'è inoltre un'altro topic che influenza il nostro Captive, sulla lista
Calabia a ninux.org, inerente alla Client Isolation che spiego di seguito:

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

I Tunnels possono essere 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 bisogna dare la possibilità agli utenti di scegliere.
I tunnels possono essere "automatizzati" nell'OpenWRT dei routers o creati
sulle Workstation mediante clients o configurazioni.

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 ?

Tipo la VPN di riseup + tunnel in chiaro alternativi.

[1] http://it.wikipedia.org/wiki/Spanning_tree_(networking)
-------------- parte successiva --------------
Un allegato HTML è stato rimosso...
URL: <https://mailman-mail5.webfaction.com/pipermail/verdebinario/attachments/20140208/9203d91f/attachment.html>