<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">Il giorno 08 febbraio 2014 16:23, Vincenzo Pirrone <span dir="ltr">&lt;<a href="mailto:linuspax@gmail.com" target="_blank">linuspax@gmail.com</a>&gt;</span> ha scritto:<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

&gt; Pertanto niente default gateway per supernetting, per stabilire un<br>
&gt; collegamento layer2 con uno o più nodi e sfruttare la possibilità di<br>
&gt; usare un default gateway sarà doveroso impiegare dei tunnels.<br>
<br>
Aggiungo anche che è possibile annunciare un default gateway con gli<br>
Hna4 di olsr (la subnet da annunciare è <a href="http://0.0.0.0/0" target="_blank">0.0.0.0/0</a>), in questo caso il<br>
gateway è pubblico e non c&#39;è bisogno di usare tunnel.<br></blockquote><div><br></div><div>in questo caso ipotizziamo che VerdeBinario, Interninux, Cerisano e Capizzanux annuncino in hna4 0.0.0.0.<br></div><div><br></div>
<div>Ogni nodo routerebbe verso il gateway calcolato da olsr con la metrica migliore.</div><div>Mentre tramite tunnels un nodo può selezionarsi il gateway.</div><div><br></div><div>Ad un nodo può apparire lo splash di Interninux in un momento e in seguito quello di VerdeBinario.</div>
<div>Con il tunnel invece sai da dove routi, mettiamola così. </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Secondo me è meglio criptato, ricordiamoci che su ninux è facile<br>
sniffare il traffico, senza contare la presenza di eventuali nodi<br>
malevoli. Inoltre credo che l&#39;overhead sia trascurabile.<br>
<br>
&gt;<br>
&gt; Io penso che si possa dare la possibilità agli utenti di scegliere.<br>
<br>
Assolutamente si<br></blockquote><div><br></div><div>Ok, ma chi non usa tunnel non può scegliere da quale gateway uscire, tutti i nodi associati ad un AP in ClientIsolation sfrutteranno il gateway del tp-link del supernodo (AP) e tutti i router delle sottoreti avranno la metrica calcolata attraverso l&#39;AP. E&#39; tutto solo layer3 e l&#39;AP è il super router di tutti i nodi e le loro sottoreti.</div>
<div> </div><div>Possiamo dire che chi si collega plug-n-play esce dal primo gateway elaborato da OLSR, diciamo il migliore di 3. Ndo-cojo-cojo in pieno stile mesh.</div><div><br></div><div>Chi invece fà il tunnel può selezionare il proprio gateway di fiducia.</div>
<div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
&gt;     MA se l&#39;utente deve fare un tunnel o avviare una applicazione per<br>
&gt;     crearsene uno (tipo openVPN e soci), non basterebbe questo a<br>
&gt;     definire una forma di autenticazione ?<br>
<br>
Si, tra l&#39;altro uno può crearsi un tunnel dal proprio PC da qualunque<br>
punto della rete verso la sua lan.<br>
Però il captive portal è più user-friendly e incorpora anche contenuto<br>
informativo. Credo che l&#39;utilizzo del captive portal si sposi bene coi<br>
gateway pubblici sopracitati (dovrebbe funzionare giusto?)<br></blockquote><div><br></div><div>Solo per traffico non SSL, proxy trasparente su porta 80 verso 80 e altre in chiaro.</div><div>Ogni gateway fà REDIRECT sulla 3128 dove espone lo splash/captive portal.</div>
<div>L&#39;utente il primo che trova usa, non può scegliere, questo è molto mesh :)</div></div><br></div></div>