[Ninux-Calabria] tunnel l2tp

Gio 3 Lug 2014 07:16:07 UTC

Il 03 luglio 2014 03:40, Stefano De Carlo <stefanauss a gmail.com> ha scritto:
> Ciao a tutti,
>
> Martedì mi sono dedicato, avvalendomi del brainstorming con spax, a
> trovare una configurazione di tunneling l2tp funzionante client/server
> tutto su OpenWRT. Riverso tutto qua come prima documentazione ma
> soprattutto braindump.
> Come col GRE, parto col tutorial vero e proprio, poi in basso punti
> critici e TODO.
>
> Prerequisiti: pacchetto xl2tpd, luci, olsr funzionante, bisogna riuscire
> a pingare il proprio endopoint scelto sulla 172.17/16.
> Nell'esempio: Client = 172.17.87.99 (TestGroundRouter), Server =
> 172.17.87.20 (SpaxGR), Subnet Tunnel = 100.66.0.0/24.
>
> == SERVER ==
>
> root a GR:~# cat /etc/xl2tpd/xl2tpd.conf
> [global]
> port = 1701
> auth file = /etc/xl2tpd/xl2tp-secrets
> access control = no
> listen-addr = 172.17.87.20
>
> [lns default]
> ip range = 100.66.0.2-100.66.0.254
> local ip = 100.66.0.1
> require chap = yes
> refuse pap = yes
> require authentication = yes
> length bit = yes
> name = NinuxTunnel
> ppp debug = yes
> pppoptfile = /etc/ppp/options.xl2tpd
>
> root a GR:~# cat /etc/xl2tpd/xl2tp-secrets
> # Secrets for authentication using CHAP
> # client    server    secret            IP addresses
> tunnel    *    test    100.66.0.2
> root a GR:~#
>
> root a GR:~# cat /etc/ppp/options.xl2tpd
> ipcp-accept-local
> ipcp-accept-remote
> auth
> idle 1800
> mtu 1410
> mru 1410
> defaultroute
> debug
> lock
> proxyarp
> connect-delay 5000
> ms-dns 10.11.12.13
> ms-dns 8.8.8.8
> require-mschap-v2
>
> root a GR:~# cat /etc/firewall.user
> # This file is interpreted as shell script.
> # Put your custom iptables rules here, they will
> # be executed with each firewall (re-)start.
>
> [... CUT ...]
>
> # Allow forwarding from/to Ninux Tunnels
> iptables -A forwarding_rule -i ppp+ -j ACCEPT
> iptables -A forwarding_rule -o ppp+ -j ACCEPT
>
> root a GR:~# cat /etc/init.d/xl2tpd enable
> root a GR:~# cat /etc/init.d/xl2tpd restart
>
> == CLIENT ==
>
> Da Luci, andiamo a Network > Interfaces > Wan > Edit e switchiamo al
> protocollo L2TP.
> L2TP Server: 172.17.87.20
> PAP/CHAP username: tunnel
> PAP/CHAP password: test
> Advanced: bring up on boot, use as default gateway spuntati.
>
> root a TestGroundRouter:~# cat /etc/ppp/options
>
> noccp
> crtscts
> idle 1800
> mtu 1410
> mru 1410
> defaultroute
> noipdefault
> debug
> lock
> connect-delay 5000
> ipcp-accept-local
> ipcp-accept-remote
>
> root a TestGroundRouter:~# /etc/init.d/xl2tpd enable
>
> root a TestGroundRouter:~# cat /etc/crontabs/root
> * * * * * /usr/sbin/ip route del `uci get network.wan.server` proto static
>
> root a TestGroundRouter:~# /etc/init.d/crond enable
> root a TestGroundRouter:~# /etc/init.d/xl2tpd start
> root a TestGroundRouter:~# /etc/init.d/crond start
>
> Al reboot dovrebbe funzionare tutto. Con le opzioni debug di pppd sopra
> abilitate, vedete tutto il processo comodamente in syslog.
>
> == NOTE ==
>
> Innanzitutto specifico che le opzioni ppp che vedete sopra sono
> semplicemente una cosa: funzionanti. Sono *di sicuro* migliorabili
> *abbestia*, ma ora con più calma e tranquillità perché queste sono in
> saccoccia.
> Ne ho individuate di critiche: sul client non volete assolutamente
> "auth" e non volete che manchi "noipdefault", credetemi. In generale: se
> le opzioni sono sbagliate non solo non funziona niente ma pppd andrà
> continuamente in segmentation fault e possibilmente in out of memory su
> *entrambi* i device.
>
> Altra cosa da notare: sul server, usiamo i file di configurazione propri
> del pacchetto xl2tpd. Sul client, anche se presente il pacchetto e
> quindi i file, non li usiamo mai. Fa tutto luci-proto-l2tp.
>
> Come spiegava Spax qui:
> http://ml.ninux.org/pipermail/calabria/2014-June/003356.html
> xl2tpd aggiunge una rotta che suppone che l'endpoint sia a noi
> direttamente collegato. Chiaramente non è così, quindi quella rotta
> "mangia" quella di OLSR e dunque diventa impossibile persino stabilire
> il tunnel.
> Sono stato a lungo in dubbio se questa rotta fosse frutto di qualche
> internal di OpenWRT ma ho fatto un test semplicissimo: rinominando il
> binario xl2tpd, per impedirgli di partire, quella rotta non compare al
> riavvio dell'interfaccia. È parte integrante di xl2tpd, non gli si può
> impedire di metterla (a meno di modificare il codice).
>
> Il fatto che fosse xl2tpd a inserirla significa che non è un evento
> legato all'avvio dell'interfaccia (ifup), di conseguenza usare hotplug.d
> come col tunnel GRE era fuori questione.
>
> La successiva best-idea era usare proprio gli script di pppd, in
> particolare /etc/ppp/ip-pre-up, quello che dovrebbe eseguirsi prima
> della chiamata pppd per agire sulle rotte. Per ragioni ignote però,
> questo script viene comunque eseguito DOPO la chiamata. Quindi
> totalmente inutile.
>
> L'unica cosa che ci è venuta in mente, inelegante ma che ha funzionato
> splendidamente, è un cronjob. Alla massima risoluzione (ogni minuto),
> con un comando universale che estrae l'indirizzo giusto da uci, rimuove
> la rotta statica senza rimuovere quella imparata grazie a OLSR:
>
> #: ip route del `uci get network.wan.server` proto static
>
> Probabilmente si può fare anche con "route del qualcosa" ma non era così
> immediato evitare che cancellasse anche la rotta OLSR e comunque al 99%
> ip ci sarà sui nostri firmware, quindi lo lasciamo come TODO a minima
> priorità.
>
> Sul server, nel file delle password /etc/xl2tpd/xl2tp-secrets non vi
> scordate di inserire un indirizzo IP (eventualmente wildcardato "*" per
> usare la stessa pass su tutti i client? TODO), altrimenti non funziona
> nisba.
>
> Non abbiamo ancora provato ad utilizzare gli indirizzi LAN interni
> invece dei 172, altro TODO a priorità bassa.
>
> Il tunnel nelle mie prove è rimasto stabile, ma è anche vero che non
> sono lì a provarlo. Dirò ad altri hacklabbers di collegarsi lì invece
> che all'AP principale per aiutare a testarlo, vediamo. Ora come ora ha
> un uptime di 2h contro le 36 di spax, ma è anche vero che quella è una
> M5 buttata alla meno peggio, a -80 di segnale e che olsrd su quel trunk
> è prone al crash. Potrebbe tranquillamente non essere dipeso nulla dal
> tunnel.
>
> TODO: test multi-client.
> TODO: consulto col guru l2tp, antofrage :P
>
> Non mi viene in mente niente altro per ora.
>
> Next: OpenVPN & dintorni.

Ripeto OpenVPN senza ssl funziona benissimo.
ES: Con la criptazione 350kilobyte/s senza criptazione 850kilobyte/s :)

l2tp è designato per layer2, a sto punto può andarsi a fare benedire,
ritorno decisamente su GRE.