Tuneles EoIP + Servidor PPPoE + Servidor Radius remoto (en Debian)

Lo de hoy es un reto, al mismo momento que un gran hit para la optimización del hardware del cual disponemos. Somos un ISP pequeñito y no nos da para grandes y caros Cisco y tiramos con hardware bueno, bonito y barato, pero tiene sus cosillas, así que vamos a linux para que nos haga el trabajo duro :)

Nos interesa conectar el cliente con un tunel EoIP para dentro pasar el PPPoE, pero EoIP es un tipo de túnel exclusivo de Mikrotik, pero los chicos de linux-eoip se lo han currado y han desarrollado una aplicación para que nuestro sistema linux pueda comunicarse con routers mikrotik con éste tipo de túneles.

EoIP en Debian

Lo descargamos e instalamos

root@epsilon-ppp:~# apt-get install build-essential
root@epsilon-ppp:~# wget --no-check-certificate https://linux-eoip.googlecode.com/files/linux-eoip-0.5.tgz
root@epsilon-ppp:~# tar zxvf linux-eoip-0.5.tgz
root@epsilon-ppp:~/linux-eoip-0.5# cd linux-eoip-0.5
root@epsilon-ppp:~/linux-eoip-0.5# ./configure --build=x86_64
root@epsilon-ppp:~/linux-eoip-0.5# make
root@epsilon-ppp:~/linux-eoip-0.5# make install

Ahora creamos un directorio donde vamos a copiar los ficheros de configuración de cada uno de los túneles EoIP. Por defecto el fichero de configuración tiene 3 túneles EoIP definidos, pero cada vez que quieras añadir uno tienes que parar EoIP, añadir el nuevo túnel y volver a arrancar EoIP, pero en un sistema en producción no nos interesa, así que probando he visto que es posible levantar varias instancias de EoIP, así que vamos a optar para crear un fichero de configuración para cada túnel EoIP:

root@epsilon-ppp:~/linux-eoip-0.5# mkdir /etc/eoip
root@epsilon-ppp:~/linux-eoip-0.5# cp eoip.cfg /etc/eoip/eoip_1001.cfg
root@epsilon-ppp:~/linux-eoip-0.5# cat /etc/eoip/eoip_1001.cfg
[zeoip0]
id=1001
dst=10.228.192.219
dynamic=1

Para levantar el túnel EoIP es tan simple como

root@epsilon-ppp:~# eoip eoip_1001.cfg
root@epsilon-ppp:~# ps aux |grep eoip
root     12856  0.0  0.0   8380   340 ?        Ssl  Nov23   0:00 eoip eoip_1001.cfg

Si queremos añadimos una ip al túnel, aunque para el PPPoE no es imperativo, simplemente nos interesa el dominio broadcast.

root@epsilon-ppp:~# ifconfig zeoip0 192.168.201.1/30
root@epsilon-ppp:~# ifconfig zeoip0
zeoip0    Link encap:Ethernet  HWaddr 1a:47:4f:2a:88:e6  
          inet addr:192.168.201.1  Bcast:192.168.201.3  Mask:255.255.255.252
          inet6 addr: fe80::1847:4fff:fe2a:88e6/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:2692 errors:0 dropped:0 overruns:0 frame:0
          TX packets:2135 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:500 
          RX bytes:159325 (155.5 KiB)  TX bytes:100267 (97.9 KiB)

A partir de aquí ya podemos ir al router mikrotik y añadir el túnel EoIP, añadimos una IP y verificamos que funciona.

Ahora vamos a la segunda parte

PPPoE Server + Radius externo

En debian no hay un servidor PPPoE, así que vamos a tener que descargarlo de la página web del proyecto rp-pppoe-server, antes de empezar pero tenemos que instalar algunas dependencias y todos los paquetes para compilar programas.

root@epsilon-ppp:/etc/eoip# apt-get install ppp ppp-dev gcc binutils build-essential
root@epsilon-ppp:~# wget http://www.roaringpenguin.com/files/download/rp-pppoe-3.11.tar.gz
root@epsilon-ppp:~# tar xvzf rp-pppoe-3.11.tar.gz
root@epsilon-ppp:~# cd rp-pppoe-3.11/src/
root@epsilon-ppp:~/rp-pppoe-3.11/src# ./configure --enable-plugin
root@epsilon-ppp:~/rp-pppoe-3.11/src# make && make install

Como queremos conectar el servidor pppoe con un radius externo (sería similar a si es interno, simplemente es apuntar a localhost), vamos a tener que instalar un cliente radius

root@epsilon-ppp:~# apt-get install radiusclient1

Ahora tenemos que configurar algunos ficheros.

root@epsilon-ppp:~# vi /etc/ppp/pppoe-server-options
# PPP options for the PPPoE server
# LIC: GPL
logfile /var/log/pppoe.log
require-pap
require-chap
mru 1492
mtu 1492
ms-dns 10.139.39.66
ms-dns 8.8.8.8
lcp-max-configure 60
lcp-restart 2
lcp-echo-interval 30
lcp-echo-failure 4
idle 0
noipx
proxyarp
lcp-echo-interval 10
lcp-echo-failure 5
plugin radius.so
plugin radattr.so
debug
kdebug 1
plugin radius.so
plugin radattr.so
plugin rp-pppoe.so
name epsilon-ppp
radius-config-file /etc/radiusclient/radiusclient.conf
root@epsilon-ppp:~# vi /etc/radiusclient/radiusclient.conf
# General settings
auth_order	radius
login_tries	4
login_timeout	60
nologin /etc/nologin
issue	/etc/radiusclient/issue

# RADIUS settings
authserver 	10.228.201.51
acctserver 	10.228.201.51
servers		/etc/radiusclient/servers
dictionary 	/etc/radiusclient/dictionary
login_radius	/usr/sbin/login.radius
seqfile		/var/run/radius.seq
mapfile		/etc/radiusclient/port-id-map
default_realm
radius_timeout	10
radius_retries	3

# LOCAL settings
login_local	/bin/login
nas_identifier polaris-ppp
root@epsilon-ppp:~# cat /etc/radiusclient/servers
# Make sure that this file is mode 600 (readable only to owner)!
#
#Server Name or Client/Server pair		Key		
#----------------				---------------
#portmaster.elemental.net			hardlyasecret
#portmaster2.elemental.net	    		donttellanyone
10.228.201.51					**********

A partir de aquí ya podríamos arrancar el servidor y empezar a funcionar… pero aquí es donde me he quedado atascada y me encontraba con éste error:

rc_avpair_new: unknown attribute 32

El problema estaba en que el diccionario cargado no sabía cuál era el atributo 32 y daba error de autenticación y cerraba la conexión, así que en la lista de rp-pppoe-server he hallado la respuesta.
Así que buscando en internet he encontrado en la wiki de freeradius otros diccionarios con mas atributos.

El fichero radiusclient sólo nos permite cargar un sólo diccionario, así que vamos a añadir al final del /etc/radiusclient/dictionary éste contenido:

#
#       Experimental extensions, configuration only (for check-items)
#       Names/numbers as per the MERIT extensions (if possible).
#
ATTRIBUTE       NAS-Identifier          32      string
ATTRIBUTE       Proxy-State             33      string
ATTRIBUTE       Login-LAT-Service       34      string
ATTRIBUTE       Login-LAT-Node          35      string
ATTRIBUTE       Login-LAT-Group         36      string
ATTRIBUTE       Framed-AppleTalk-Link   37      integer
ATTRIBUTE       Framed-AppleTalk-Network 38     integer
ATTRIBUTE       Framed-AppleTalk-Zone   39      string
ATTRIBUTE       Acct-Input-Packets      47      integer
ATTRIBUTE       Acct-Output-Packets     48      integer
# 8 is a MERIT extension.
VALUE           Service-Type            Authenticate-Only       8

Si el servidor PPPoE no comunica con radius, mira primero de todo que tienes cargados todos los atributos necesarios.

A partir de aquí pues, vamos a arrancar el servidor PPPoE

root@epsilon-ppp:~# pppoe-server -L 192.168.69.1 -I zeoip0 -I zeoip1 -N 1200 -C epsilon-ppp -S epsilon-ppp -T 300 -k -m 1492

-I if_name – La interfaz (por defecto eth0)
-T timeout – Tiempo de inactividad en segundos
-C name – Nombre del concentrador
-L ip – IP local (la IP que va a salir en el default gateway si no lo definimos)
-S name – Advertise specified service-name.
-N num – Número máximo de sesiones permitidas
-k – Usa el modo PPPoE del kernel

Como os podéis imaginar, esto en un sistema en producción no puede ser muy cómodo, ya que que parar el servidor PPPoE para añadir una nueva interfaz puede ser un tanto problemático, así que otra opción es usar como interfaz un bridge y ahí vamos añadiendo o sacando las interfaces a nuestro antojo (aviso: esto lo estaba haciendo así en Mikrotik pero tengo que ver como se comporta en Linux).

La forma de hacerlo sería:

Añadir un nuevo bridge y luego iniciar el servidor PPPoE

root@epsilon-ppp:~# brctl addbr br0
root@epsilon-ppp:~# brctl stp br0 on
root@epsilon-ppp:~# pppoe-server -L 192.168.69.1 -I br0 -N 1200 -C epsilon-ppp -S epsilon-ppp -T 300 -k -m 1492

Tengo dudas si el stp es necesario en el caso de los PPPoE, ya que según he leído, cada tunnel PPPoE rompe el broadcast y no sé si STP genera mas problemas que soluciones en este caso.

Añadir interfaces en el bridge

root@epsilon-ppp:~# brctl addif br0 zeoip0
root@epsilon-ppp:~# brctl addif br0 zeoip1
root@epsilon-ppp:~# brctl show
bridge name bridge id         STP enabled interfaces
br0         8000.1a474f2a88e6 no          zeoip0
                                          zeoip1

¡Y hasta aquí es todo! :)

Ahora sólo falta ver porqué IPv6 no funciona correctamente, pero debe ser algo de los atributos o simplemente que en el servidor de pruebas aún no he añadido ninguna IPv6, en el router cliente aún no añade tampoco la ruta por defecto IPv6… espero que no sea nada demasiado complejo o difícil de identificar como lo de los diccionarios! :o

Ah! si! y el NAT! para que los usuarios del túnel puedan salir por la interfaz:

root@epsilon-ppp:~# echo 1 > /proc/sys/net/ipv4/ip_forward
root@epsilon-ppp:~# iptables -t nat -F POSTROUTING
root@epsilon-ppp:~# iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

Ahora sólo falta currarse unos scripts o un sistema para gestionar esto de forma sencilla :P Aquí ya no os lo doy tan masticadito que sinó me quedo sin trabajo y si llegáis a éste nivel no creo que tengáis demasiados problemas con esta parte :P

Fuentes:
EoIP tunnel on linux
Linux PPPoE server with radius support
Bridge Network Connections

3 Comments

    • El overhead de la MTU… en el mateix paquet pots passar més informació… com a VPN suposo que et refereixes a PPPtP, IPSec, OpenVPN, etc. EoIP són 4 bytes i PPPoE 4 més, que amb un MTU de 1492 ja pots connectar-te. El EoIP el necessitem perquè PPPoE necessita que el router destí o equip estigui en el mateix domini de broadcast que el server PPPoE.
      Per altra banda amb PPPoE+Radius pots automatitzar la configuració dels clients i afegir tots els paràmetres que vulguis de forma “senzilla”.

      Respon

Deixa un comentari

L'adreça electrònica no es publicarà. Els camps necessaris estan marcats amb *

Aquest lloc utilitza Akismet per reduir els comentaris brossa. Apreneu com es processen les dades dels comentaris.