<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">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">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>
<br><br></div>Abbiamo anche provato a stabilire il tunnel impostando come server l'indirizzo lan dell'841, ma non ha funzionato per motivi che non abbiamo ancora identificato<br><div><div><div><div><div><div><div>
<div><div><div><br><br></div></div></div></div></div></div></div></div></div></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">Il giorno 18 maggio 2014 17:57, 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">Il 18 maggio 2014 13:38, Vincenzo Pirrone <<a href="mailto:linuspax@gmail.com">linuspax@gmail.com</a>> ha scritto:<br>
<div><div class="h5">> Apro un nuovo thread<br>
> Ho installato xl2tpd sul mio PC, posto la configurazione<br>
><br>
> spax@arch ~ $ cat /etc/xl2tpd/xl2tpd.conf<br>
> [lns default]<br>
> ip range = 10.10.10.2-10.10.10.254<br>
> local ip = 10.10.10.1<br>
> require chap = yes<br>
> refuse pap = yes<br>
> require authentication = yes<br>
> name = LinuxVPNserver<br>
> ppp debug = yes<br>
> pppoptfile = /etc/ppp/options.xl2tpd<br>
> length bit = yes<br>
><br>
> spax@arch ~ $ cat /etc/ppp/options.xl2tpd<br>
> ipcp-accept-local<br>
> ipcp-accept-remote<br>
> mtu 1410<br>
> mru 1410<br>
> defaultroute<br>
> debug<br>
> lock<br>
> proxyarp<br>
> connect-delay 5000<br>
><br>
> spax@arch ~ $ sudo cat /etc/ppp/chap-secrets<br>
> [sudo] password for spax:<br>
> # Secrets for authentication using CHAP<br>
> # client server secret IP addresses<br>
> "username" "*" "password" "10.10.10.2"<br>
><br>
> Ho avviato il server con xl2tpd -D<br>
><br>
><br>
> Sul mio router ho configurato la wan con protocollo l2tp, indicando come<br>
> server il mio PC e come credenziali quelle definite qui sopra, and it works<br>
><br>
> l2tp rispetto a GRE ha autenticazione (seppur chap sia abbondantemente<br>
> bucato è sempre meglio di niente), supporto in Luci e soprattutto<br>
> autoconfigurazione degli IP<br>
><br>
> xl2tpd in 4MB ci sta, quindi direi che abbiamo risolto il problema dei<br>
> tunnel<br>
<br>
</div></div>che è quello che dicevo io:<br>
<br>
se luci come interfacce di rete ci consente pppoe, pptp e pppol2pt<br>
tantovale sfruttarle.<br>
Tu l'hai fatto, pertanto nzicchiamo sul firmware anche l2tp così il<br>
tunnel lo configuriamo e lo gestiamo tramite luci con tanto di<br>
firewall zone e quant'altro.<br>
<br>
attendo vostre conferme, intanto io il firmware con pptp e l2pt ce<br>
l'ho e non chiedetemi perchè ho lasciato anche pptp perchè poi ve lo<br>
spiego a 4 occhi :)<br>
_______________________________________________<br>
Calabria mailing list<br>
<a href="mailto:Calabria@ml.ninux.org">Calabria@ml.ninux.org</a><br>
<a href="http://ml.ninux.org/mailman/listinfo/calabria" target="_blank">http://ml.ninux.org/mailman/listinfo/calabria</a><br>
</blockquote></div><br><br clear="all"><br>-- <br><div dir="ltr">Vincenzo Pirrone<br>Twitter: @spax_arm<br>PGP Key ID: 5CF5047D<br></div>
</div>