[Ninux-Calabria] tunnel l2tp

[Stefano De Carlo]

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.

Stefanauss.

-------------- parte successiva --------------
Un allegato non testuale è stato rimosso....
Nome:        signature.asc
Tipo:        application/pgp-signature
Dimensione:  819 bytes
Descrizione: OpenPGP digital signature
URL:         <http://ml.ninux.org/pipermail/calabria/attachments/20140703/35d8d2b1/attachment-0001.sig>