<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">Il giorno 03 giugno 2014 16:06, Vincenzo Pirrone <span dir="ltr"><<a href="mailto:linuspax@gmail.com" target="_blank">linuspax@gmail.com</a>></span> ha scritto:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><div><div><div><div><div><div><div><div>Settimana scorsa abbiamo fatto un real-case test con Stefano, mettendo server su un 841 in HPCC (dietro una nanostation di test attaccata a spig) e usando il mio 741 come client. Il test in linea di massima ha avuto esito positivo, però ho dovuto ritoccare a mano la tabella di routing del client perchè xl2tpd la modifica.<br>
<br></div><div>Il test è stato eseguito abilitando la CI su spig (era sera e nessuno se n'è accorto, non scassate) perchè ci interessava questo use-case.<br></div><div><br></div>In pratica il mio router ha indirizzo backbone <a href="http://172.17.87.20/16" target="_blank">172.17.87.20/16</a>, in tabella di routing questo si traduce in:<br>
</div><div><br></div><div> host netmask gateway metric iface<br></div><div>(1) 172.17.0.0 255.255.0.0 0.0.0.0 0 eth0.3<br>
</div><div><br></div><div>Che vuol dire che la subnet <a href="http://172.17.0.0/16" target="_blank">172.17.0.0/16</a> è raggiungibile in l2<br></div><div><br>il server che abbiamo usato 172.17.87.99, per questo olsr ha inserito una entry nella mia tabella di routing:<br>
<br></div><div>(2) 172.17.87.99 255.255.255.255 172.17.87.4 2 eth0.3<br></div><div><br></div>Che vuol dire che il 172.17.87.99 è raggiungibile tramite il GR di spig, questa regola ha precedenza su quella di sopra perchè più specifica, per questo per il traffico diretto a 172.17.87.99 non viene mandato in LAN ma spedito a spig.<br>
<br></div>Una volta avviato il client l2tp questo imposta come default gateway l'altro lato del tunnel:<br><br></div>(3) 0.0.0.0 0.0.0.0 10.10.10.1 0 tun0<br>
<br></div>xl2tpd però da per scontato che l'endpoint del tunnel 172.17.87.99 stia in lan, e aggiunge una regola verso questo<br><br></div>(4) 172.17.87.99 255.255.255.255 0.0.0.0 0 eth0.3<br>
<br></div>Che per metrica ha precedenza sulla (2), ma 172.17.87.99 non sta in lan, pertanto per far funzionare il tunnel bisogna togliere a mano questa regola.<br><br></div>Quindi dobbiamo trovare il modo per impedire al demone di l2tp di modificare la tabella di routing e aggiungere la (3) a mano.<br>
</div></div></blockquote><div><br><br></div><div>Dovremmo poter creare il file /etc/hotplug.d/iface/90-wan come descritto da Stefano sul thread su GRE per rimuovere la (4).<br><br></div><div>@Stefano concordi?<br></div></div>
<br><br clear="all"><br>-- <br><div dir="ltr">Vincenzo Pirrone<br>Twitter: @spax_arm<br>PGP Key ID: 5CF5047D<br></div>
</div></div>