- Mensajes
- 14,160
Introducción
En este manual vamos a picotear con varios temas, y aplicar algunos de los conocimientos que ya tenemos. Basicamente, nos sobra conexión, y hemos decidido que una buena manera de ayudar a nuestra comunidad es darle internet a un par de vecinos que lo necesitan y no se pueden permitir pagarlo. El acceso que le daremos será básico y gestionado por nosotros, pero más que suficiente para un uso normal en una vivienda media (acceder a gestiones con el banco, usar whatsapp, incluso ver streaming). Inicialmente ya hemos montamos el cableado que llega desde su vivienda a la nuestra, y sendos cables conectan directos a nuestro router. Hemos montado un par de vlans para darle servicio, pero no nos acaba de gustar demasiado el setup, y queremos ir un poco más allá. Como todos los manuales, partimos de un router recién reseteado y con la configuración por defecto, donde nuestra red LAN es un bridge con la 192.168.88.1/24 sobre dicha interfaz. La conexión WAN dependerá del tipo de vuestra salida a internet (dhp sobre interfaz física, PPPPoE, VLAN, etc)Teoría
Para este setup vamos a usar varios elementos sobre los que ya hemos picoteado (colas de prioridad, dhcp con ARP, leases estáticas con rutas dinámicas, fasttrack condicional, marcado de paquetes), pero está basado en un concepto del cual aún no hemos hablado: VRF (Virtual routing & forarding)¿Qué es VRF? Pues, resumiéndolo mucho, es la manera de tener varios routers virtuales en un mismo router físico. Si partimos de que un router tiene una tabla de rutas por la cual encamina su tráfico, VRF expande ese concepto con nuesvas tablas de rutas virtuales, a las cuales se les asocian interfaces físicas de dicho equipo. De esa manera, si un puerto cualquiera está asociado a una VRF, se creará una nueva tabla de rutas virtual y dicho puerto sólo verá dicha tabla de rutas, no viendo nada más. Esto se utiliza mucho en setups con MPLS y BGP (cosas con las que ni de coña me voy a meter ahora), y nos permitiría incluso manejar dos segmentos de red idénticos sobre distintas interfaces de un mismo router, siempre y cuando cada uno de de ellos fuera asociado con una VRF distinta.
Y, ¿para qué nos puede valer esto a nosotros entonces? Pues en verdad para un montón de cosas, pero me voy a lo simple: para compartir mi conexión con los vecinos y asegurar independencia absoluta entre subredes, sin necesidad de usar VLANs ni trabajar en L2.
Si queréis más detalle de qué características del router tienen soporte para VRF, lo tenéis documentado en la ayuda.
Premisas y puesta en marcha
Como ya hemos dicho en la introducción, la parte del cableado ya está lista. Nuestros vecinos, inicialmente, van a montar su propio router neutro en casa, y nosotros simplemente les vamos a tener que hacer llegar internet por ese cable, con unas condiciones que ahora detallaremos. Como somos buenos, pero tampoco tontos, hemos tomado una serie de precauciones, para prevenir que puedan abusar de nuestra amabilidad. Vamos a cumplir con estas premisas:Premisas a cumplir
- Compartir mi conexión actual con un par de vecinos, que necesitan un acceso básico
- Que los vecinos tengan subredes independientes y no se vean entre ellos, ni vean mi red
- Que uno de ellos no tenga doble NAT.
- Que, como mucho, usen 50Mbps de mi conexión
- Como uno de ellos me cae mejor, le garantizo que siempre que los solicite y yo no los use, tendrá disponible 20 de esos 50Mbps totales.
- Que cada uno tenga una gestión completa de su subred, usando su propio router
- Que mi red siga yendo en fasttrack: es decir, si yo lo necesito, la red está entera para mi.
El setup inicial lo hicimos con VLANs, pero como no nos convence, vamos a dar un salto más y a usar VRF, creando tablas de rutas independientes para cada vecino, mientras que nosotros permanecemos en la tabla "main" (la tabla por defecto). Dichas tablas accederán a nuestra interfaz WAN como su gateway de salida.
Setup VRF
Lo primero que vamos a identificar es a los dos vecinos, y los puertos que usaremos para ello. En mi caso vamos a llamar a los vecinos "blue", conectado al puerto ether4, y "green" conectado al puerto ether5. Dichos puertos los hemos sacado del bridge y ahora mismo no están asociados a nada en nuetro router, ni lista, ni ninguna otro tipo de interfaz bridge. Lo primero que daremos de alta, es el VRF, asociando cada puerto a su tabla de rutas, como sigue a continuación:
Código:
/ip vrf
add interfaces=ether4 name=blue
add interfaces=ether5 name=greenUna vez dado de alta el VRF, veremos que se han creado automáticamente dos nuevas tablas de rutas dinámicas, las cuales podemos ir a ver en IP -> Routes
Aquí veremos que tenemos nuestra tabla "main", que siempre ha estado ahí y que simpelemente con el comando anterior ya se han creado dos tablas de rutas nuevas, de manera dinámica, las cuales tenemos disponibles con el dropdown que nos aparece a la derecha.
También en Routing -> Tables
Lo siguiente que vamos a hacer es direccionar dichas interfaces ether4/ether5, con direcciones /30 para montar una conexión punto a punto. Hemos elegido una subred /24 cualquiera que no tenemos actualmente en uso, y vamos a usar dos cachitos /30 en ella (luego entenderéis el porqué). Así, crearemos:
192.168.10.0/30 -> blue (ether4)
192.168.10.4/30 -> green (ether5)
Creamos por tanto las IP's correspondientes para cada interfaz, usando la primera IP de dicho segmento /30 (.1 y .5 respectivamente):
Código:
/ip address
add address=192.168.10.1/30 comment=blue interface=ether4
add address=192.168.10.5/30 comment=green interface=ether5Setup del DHCP Server
Para no complicarle la vida a los vecinos con direcciones estáticas, vamos a entregar la única dirección del pool de manera dinámica. Además de ello, como ya aprendimos cuando usamos VLANs para invitados, vamos a configurar los puertos para que no añadan entradas ARP de manera automática, y únicamente meter la entrada en la tabla ARP si ha sido el DHCP quien entregó la dirección. Además, como sólo vamos a manejar una IP y conocemos el equipo final del vecino, crearemos una lease estática a mano que represente su equipo. Con eso le quitamos la tentación al vecino de colocar cualquier IP a manija, tratando de evitar los controles que asociaremos posteriormente a dicha IP. Así que, procedemos
Primero, le quitamos el ARP automático a las interfaces ether4 y ether5
Código:
/interface ethernet
set [find default-name=ether4] arp=reply-only
set [find default-name=ether5] arp=reply-onlySegundo, crearemos los servidores DHCP, entregando el ARP que ya no aprenden automáticamente dichas interfaces. Para crear los leases, primero necesitaremos las direcciones MAC de la interfaz WAN de los equipos que usarán los vecinos como router reutros. Las que tengo ahí puestas son las mías, vosotros usad las vuestras.
Código:
/ip dhcp-server
add add-arp=yes interface=ether4 name=server-blue
add add-arp=yes interface=ether5 name=server-green
/ip dhcp-server network
add address=192.168.10.0/30 comment=blue dns-server=1.1.1.1,1.0.0.1 gateway=192.168.10.1 netmask=32
add address=192.168.10.4/30 comment=green dns-server=1.1.1.1,1.0.0.1 gateway=192.168.10.5 netmask=32
/ip dhcp-server lease
add address=192.168.10.2 comment=blue mac-address=58:EF:68:7D:AE:66 server=server-blue
add address=192.168.10.6 comment=green mac-address=2C:C8:1B:AA:57:0E server=server-greenEn este punto los equipos de los vecinos obtendrán una dirección IP en su parte WAN, aunque aún no navegarán. Para que lo hagan, necesitamos aún un par de cosas.
Añadiendo una ruta por defecto a cada VRF
Como todos vamos a compartir la misma interfaz WAN para salir a internet, tenemos que añadir una ruta estática a las dos VRF's para proveer dicha salida, ya que ahora mismo la única tabla de rutas que tiene una ruta por defecto será main. El tipo de conexión es PPPoE (si fuera DHCP, en lugar de la interfaz pondríais la IP concreta como gateway), así que añadiremos las siguientes rutas estáticas a las dos nuevas tablas (esto se podría hacer de manera dinámica con un script, pero no quiero complicar más el manual). Como la ruta por defecto está en nuestra tabla "main", y las entradas no van a esa tabla, tendremos que especificar dónde se encuentra dicho gateway, con un "@main" a la hora de meter el gateway.
Código:
/ip route
add gateway=pppoe-out1@main routing-table=green
add gateway=pppoe-out1@main routing-table=blueMarcado del tráfico
Ahora viene la parte más compleja del setup. Como todo va a salir por una WAN que está en la tabla "main", tenemos un problema con el tráfico de retorno, puesto que este va a volver por defecto a la tabla de donde salió (main, donde está el gateway). Para nuestra red acertará y todo funcionará del tirón sin más configuración. Pero, para el tráfico que genere el vecino "blue", y que venga de la tabla de rutas con el mismo nombre, de alguna manera tenemos que retornarlo a dicha tabla, al igual que para el otro vecino. Para ello marcaremos toda conexión nueva que se genere debajo de las interfaces físicas conectadas a cada vecino. Como el tráfico ya saldrá "marcado" con una etiqueta de conexión, lo siguiente será marcar el enrutado para cualquier cosa que entre por la interfaz compartida que hace de WAN (retorno) y saliese en su momento con la etiqueta dicha etiqueta de conexión. Daremos de alta las siguientes reglas de mangle:
Código:
/ip firewall mangle
// Marcamos el tráfico de salida
add action=mark-connection chain=prerouting connection-state=new in-interface=ether4 new-connection-mark=from-blue passthrough=no
add action=mark-connection chain=prerouting connection-state=new in-interface=ether5 new-connection-mark=from-green passthrough=no
// Marcamos el routing de retorno
add action=mark-routing chain=prerouting connection-mark=from-blue in-interface=pppoe-out-1 new-routing-mark=blue passthrough=yes
add action=mark-routing chain=prerouting connection-mark=from-green in-interface=pppoe-out-1 new-routing-mark=green passthrough=yesFasttrack condicional
Para que lo anterior funcione, necesitamos deshabilitar fasttrack, puesto que el marcado de paquetes no se aplicará correctamente si el tráfico se salta el mangle. No obstante, tenemos como premisa no joder el fasttrack de nuestra red pricipal, así que necesitamos evitar que dicho tráfico pase por la regla de fasttrack. Para ello, crearemos una lista "slowpath" y meteremos en ella las subredes que no queremos que hagan fasttrack. Así mismo, modificaremos la regla por defecto para que no aplique sobre dicha lista. Aquí aprovecharemos la sumarización de redes y, en lugar de meter las dos subredes /30, meteremos la subred /24 que las barre a las dos (y a un futuro tercer, cuarto, quito vecino... etc)
Código:
/ip firewall address-list
add address=192.168.10.0/24 list=slowpathAhora, modificaremos la regla de fasttrack por defecto, para que aplique a todo tráfico, menos al que tenga como origen o destino una ip de esta lista
Código:
/ip firewall filter
set [find comment=defconf: fasttrack] src-address-list=!slowpath dst-address-list=!slowpathColas para limitar el ancho de banda de los vecinos
Lo primero que tenemos que definir es qué cantidad de tráfico queremos que, como máximo, se zampen nuestros vecinos. En mi caso, he decidido que con 50Mbps van que chutan para el uso que le van a dar (total, se lo voy a dar gratis, así que mando yo). Además, de esos 50Mbps, vamos a garantizar 10Mbps a cada vecino, en caso de que uno de ellos esté abusando de la conexión, para que el otro no se quede tirado. Y, como me llevo mejor con el vecino "blue", a ese le voy a permitir que exceda de esos 10Mbps con mayor facilidad que al vecino "green".
Para esto, lo primero que creamos es la cola "padre", la cual llamaremos "vecinos". Como target tendrá las dos subredes de los vecinos sumarizadas (al igual que antes, 192.168.10.0/24), y con un límite de 50M, tanto subida como bajada.
Código:
/queue simple
add max-limit=50M/50M name=Vecinos target=192.168.10.0/24Hecho esto, creamos una cola para cada vecino, asociada a su IP. Su velocidad máxima serán casi los 50M totales de la padre (un pelín menos, para que la cola tenga la posibilidad de asignar trafico al otro vecino, en caso de estar a tope de demanda). De garantizado, como hemos dicho, 10Mbps para "green" y el doble para "blue", que me cae mejor. También le vamos a dar más prioridad a "blue", de tal manera que tenga más posibilidad de superar su mínimo garantizado frente a "green". Ambas colas tendrán a la cola "Vecinos" como padre.
Código:
/queue simple
add limit-at=20M/20M max-limit=49M/49M name=blue parent=Vecinos priority=6/6 target=192.168.10.2/32
add limit-at=10M/10M max-limit=49M/49M name=green parent=Vecinos priority=7/7 target=192.168.10.6/32Con esto tendremos que ambos vecinos tendrán la sensación de tener una conexión de 50Mbps, salvo en el momento en el que ambos empiecen a demandar tráfico como locos, donde la conexión se repartira. Y, aunque "blue" abuse, siempre se garantizarán 10Mbps de conexión mínima a "green", teniendo "blue" más probabilidad de obtener un tráfico superior a su límite garantizado, en el caso en el que la red ambos demanden velocidad al mismo tiempo.
Como teníamos de premisa, mi fasttrack manda: si en un momento dado yo me pongo a demandar el tope de la conexión, como mi tráfico no pasa por las colas, mando yo, y puede que esas garantías no se cumplan. No obstante, de lo que se trata es de prevenir que uno de los vecinos deje sin internet al otro, así que con este setup tan simple nos vale.
Rizando el rizo: "green" me pide que le quite el doble NAT
Con este setup, el vecino "green" nos pide un favorcete adicional: no tener doble NAT, y se ha cerciorado de que en su router puede deshabilitar esa función. Además, quiere que el tráfico de todos sus clientes esté repartido equitativamente. Nosotros le decimos que bien, pero que preferimos que se conecte con NAT, pero accedemos a hacerlo, con la condición de que dejaremos de garantizarle los 10Mbps. Para ello, nos dice que se ha comprado un Mikrotik (ha visto las maravillas que se pueden hacer con él) y ha creado su red LAN en la 192.168.188.1/24, y nos pide ese favor adicional. Le indicamos cómo tiene que quitar la NAT una vez hayamos completado el setup, y nos ponemos manos a la obra:Modificando el lease estático para inyectar una ruta dinámica, que apunte a la LAN de "green"
Para ello, informamos el campo "routes" del lease del DHCP. Esto meterá una ruta nueva en la tabla asociada a la VRF correspondiente. El formato es DST_ADDRESS_SUBNET + ESPACIO + GATEWAY. Modificamos la lease existente con dichos datos:
Código:
/ip dhcp-server lease
set [find comment=green] routes="192.168.188.0/24 192.168.10.6"Añadiendo dicha subred a la lista de slowpath, para que le apliquen las colas
Lo siguiente que tenemos que hacer antes de que "green" quite su NAT es hacer que se apliquen las mismas reglas de mangle para el tráfico que se genere desde esa subred. Y, para eso, simplemente tenemos que hacer que esa subred también evite pasar por fasttrack. Como ya creamos una lista antes, ahora simplemente meteremos la nueva subred en ella, y todo empezará a funcionar
Código:
/ip firewall address-list
add address=192.168.188.0/24 list=slowpathAñadiendo la nueva subred a las colas de prioridad
Para añadir la nueva subred a la jerarquía de colas que hemos definido, lo primero que tenemos que hacer es meter dicha subred en la cola padre "Vecinos", como un target más de la misma. Una vez hecho, creamos una nueva cola hija con las características que hemos acordado con él: sin prioriad (priodiad 8, si no especificamos ninguna), sin mínimo garantizado, pero repartiendo equitativamene el tráfico entre todos los clientes que vengan de la subred .188 (cola de tipo PCQ)
Código:
/queue simple
set [find name=Vecinos] target=192.168.10.0/24,192.168.188.0/24
add max-limit=49M/49M name=green-not-natted parent=Vecinos queue=pcq-upload-default/pcq-download-default target=192.168.188.0/24Sin más, espero que este manual os guste y os sirva de inspiración para muchos otros setups. Ha quedado un popurrí de conceptos bastante interesante. Que lo disfrutéis.
Saludos!
Última edición:
