Escogiendo routers VPN WireGuard: servidor y cliente

Finalizado, al final creo que me he salido.
Te paso un ejemplo del cliente de un Mac. Sospecho que en windows es muy similar.
Lo que te encuentras al crear el túnel sería algo así: él genera el par clave pública/privada del cliente. La pública de arriba te la llevarías al Peer del router.
1653726191072.png


Y, se rellena de la siguiente forma:
1653726428296.png


Y añado una pregunta: entiendo que en Barcelona al conectar el hEX, deberé abrir dos puertos en el router HGU: el 15320 UDP por el rw y el 15321 UDP para el site to site. Pero con esto de los puertos siempre tengo dudas, ¿estaría correcto en esta captura?:
La idea es que, como has puesto dos puertos contiguos, lo puedas hacer todo en una única regla. Sería algo así como
External Port Start = 15320
External Port End = 15321
Protocol = UDP
Internal Port Start = 15320
Internal Port End = 15321

Y así tendrías una única regla.
Pero faltaría saber la IP que toma el MikroTik hEX del HGU, ¿no?
Correcto. Tenemos dos opciones: fijar en el DHCP del HGU la IP que coge el Mikrotik, tal que siempre se le entregue la misma (lo mismo que te dije que vamos a hacer con el hAP-ac3 y tus clientes locales que requieran IP "estática") o ponerle directamente una IP estática. Soy más partidario de la primera, pero si el equipo no se va a mover de allí jamás y siempre vas a tener por encima el mismo equipo, podrías perfectamente hacerla estática. Ahora mismo, está dinámica, para que esto salga andando tal cual lo pinches a cualquier router, tenga el segmento de red que tenga (de otra manera tendrías que saberlo de antemano).

Por otro lado, la siguiente pregunta va en esta línea, si voy a casa de un amigo en UK, y pincho en su router el hEX para probarlo, ¿deberé abrir estos dos puertos en su router para probar que el hEX funciona?
Eso sólo lo necesitas si quieres una comunicación bidireccional. Ahora mismo, verás que hay una diferencia sutil entre los peers que has dado de alta en los routers para los clientes RW y el STS: este último, en ambos extremos, lleva la dirección DDNS del otro router. Eso quiere decir que cualquiera de los dos extremos va a intentar contactar con el otro, cualquiera de los dos routers serán origen de la conexión. En los clientes de tipo RW el router no llama a nadie, y simplemente espera que le llegue tráfico por la interfaz, con una IP y una clave pública concreta. Es decir, ahora mismo, si tu pinchas el hEX en casa de cualquier colega, debería "llamar a casa" y establecer comunicación con el hAP-ac3. No obstante, cuando lo tengas en su sitio definitivo, sí que haremos la apertura e puertos, para que esa comunicación pueda ser bidireccional.
Obviamente, te va a quedar por probar la parte RW en el hEX, a menos que le digas al colega que te abra ese par de puertos y se los mande a la IP del hEX. Pero descuida, que lo que más me interesa es ver si tienes acceso remoto al equipo y llegas a él vía el túnel STS. Todo lo demás, se puede configurar / pulir estando en remoto.

Es curioso porque ayer cuando probé el "wg-rw-uk" configurado en el hAP conectandome desde el telefono con 4G, usando la app de WireGuard y la conexión "Home UK", conectaba pero yo no he abierto ningún puerto en el hAP...
Sí que los has abierto, aunque no como sueles hacerlo. ¿Recuerdas lo que te comenté de los chains del firewall? Pues en input tienes una bonita regla que acepta el tráfico con destino los puertos de la VPN. No los has abierto como sueles abrirlos (en el NAT) porque el servicio no te lo ofrece un equipo que está debajo del router, sino que es el propio router quien lo ofrece. Por esa razón, se abren en input, y no en el NAT.
En el caso del hEX, él si que está por debajo de un router, por tanto en el HGU hay que hacer un mapeo de puertos a la vieja usanza. Y, si te das cuenta, el Mikrotik hEX no tiene ninguna regla de firewall: no las necesita, es un switch debajo de un router que ya lleva firewall.

PS: el export tiene buena pinta, pasamos a rematar el hAP-ac3. Dale el equipo a cualquier colega que probemos que llegamos a él en remoto.

Saludos!
 
Te paso un ejemplo del cliente de un Mac. Sospecho que en windows es muy similar.
Lo que te encuentras al crear el túnel sería algo así: él genera el par clave pública/privada del cliente. La pública de arriba te la llevarías al Peer del router.
Muchas gracias por la explicación, creo que los he configurado bien. Como me llevaré el portátil a Barcelona y es uno de los peers que he puesto para el wg-rw-es, cuando esté en Barcelona y conecte el hEX, conectaré el portátil a internet por otra red, y usaré tanto para los móviles como para el portátil que funcionan bien como wg peers.

La idea es que, como has puesto dos puertos contiguos, lo puedas hacer todo en una única regla. Sería algo así como
External Port Start = 15320
External Port End = 15321
Protocol = UDP
Internal Port Start = 15320
Internal Port End = 15321

Y así tendrías una única regla.

Correcto. Tenemos dos opciones: fijar en el DHCP del HGU la IP que coge el Mikrotik, tal que siempre se le entregue la misma (lo mismo que te dije que vamos a hacer con el hAP-ac3 y tus clientes locales que requieran IP "estática") o ponerle directamente una IP estática. Soy más partidario de la primera, pero si el equipo no se va a mover de allí jamás y siempre vas a tener por encima el mismo equipo, podrías perfectamente hacerla estática. Ahora mismo, está dinámica, para que esto salga andando tal cual lo pinches a cualquier router, tenga el segmento de red que tenga (de otra manera tendrías que saberlo de antemano).

Perfecto, abriré los puertos con una única regla.

Sobre qué hacer con la IP del hEX... dudo. El segmento de trabajo del router Movistar de Barcelona, lo he consulta vía web, y es el siguiente:

Router Movistar (Mitrastar GPT-2541GNAC)

Red LAN
IP del router: 192.168.1.1
Máscara de red: 255.255.255.0
IP inicio DHCP; 192.168.1.33
IP fin DHCP: 192.168.1.199
Servidor DNS: 80.58.61.254

Tal y como está el hEX, tomando la ip que le de el HGU, es muy práctico porque es llegar enchufar y listo. El problema que le veo, y quizás me equivoque, es que cuando llegue a Barcelona, lo conecte, mire la ip que le ha dado, supongamos sea la 192.168.1.50, entonces abro los puertos para esa ip: 192.168.1.50. Pero ¿Qué sucederá si un día alguien en casa apaga de la corriente el hEX, lo vuelve a encender, y entonces el HGU le da la ip 192.168.1.60? entiendo que habría que ir a la web del HGU y modificar la regla de los puertos para que los abra para la 192.168.1.60, ¿correcto? Cosa que no veo mucha molestia, porque abrir y cerrar puertos del HGU lo puedo hacer en remoto desde UK.


Eso sólo lo necesitas si quieres una comunicación bidireccional. Ahora mismo, verás que hay una diferencia sutil entre los peers que has dado de alta en los routers para los clientes RW y el STS: este último, en ambos extremos, lleva la dirección DDNS del otro router. Eso quiere decir que cualquiera de los dos extremos va a intentar contactar con el otro, cualquiera de los dos routers serán origen de la conexión. En los clientes de tipo RW el router no llama a nadie, y simplemente espera que le llegue tráfico por la interfaz, con una IP y una clave pública concreta. Es decir, ahora mismo, si tu pinchas el hEX en casa de cualquier colega, debería "llamar a casa" y establecer comunicación con el hAP-ac3. No obstante, cuando lo tengas en su sitio definitivo, sí que haremos la apertura e puertos, para que esa comunicación pueda ser bidireccional.
Obviamente, te va a quedar por probar la parte RW en el hEX, a menos que le digas al colega que te abra ese par de puertos y se los mande a la IP del hEX. Pero descuida, que lo que más me interesa es ver si tienes acceso remoto al equipo y llegas a él vía el túnel STS. Todo lo demás, se puede configurar / pulir estando en remoto.

Perfecto, esta mañana y medio día, tengo un poco de lío, pero esta tarde intentaré ir a casa de un amigo y enchufarle el hEX a su router. Si no tengo que abrir los puertos mejor, porque sé que ya me va a mirar raro como si fuese a hackear su casa... así que si me pongo a abrir puertos igual llama a la policía ;-)
No probar ahora el wg-rw-es no me preocupa, porque eso entiendo lo que hace y más o menos su funcionamiento, por lo que cuando esté en Barcelona lo podré testear.

Sí que los has abierto, aunque no como sueles hacerlo. ¿Recuerdas lo que te comenté de los chains del firewall? Pues en input tienes una bonita regla que acepta el tráfico con destino los puertos de la VPN. No los has abierto como sueles abrirlos (en el NAT) porque el servicio no te lo ofrece un equipo que está debajo del router, sino que es el propio router quien lo ofrece. Por esa razón, se abren en input, y no en el NAT.
En el caso del hEX, él si que está por debajo de un router, por tanto en el HGU hay que hacer un mapeo de puertos a la vieja usanza. Y, si te das cuenta, el Mikrotik hEX no tiene ninguna regla de firewall: no las necesita, es un switch debajo de un router que ya lleva firewall.

PS: el export tiene buena pinta, pasamos a rematar el hAP-ac3. Dale el equipo a cualquier colega que probemos que llegamos a él en remoto.

Saludos!

De todo lo que hemos hecho, creo que he entendido un 80%, pero aún me quedan cosas por entender y sobre todo ver sus altas capacidades. Estoy guardando todas las explicaciones y capturas de pantalla de la configuración, por si lo tengo que volver a hacer, pero sobre todo para una vez montado repasarlo y acabar de entender ese 20%.

Te aviso cuando tenga pinchado el hEX en casa de mi amigo, para testearlo, y si me quieres poner deberes para avanzar en el hAP, yo encantado los hago.
 
Nos queda el último paso, que consiste en rematar el hAP-ac3 para tener:
  • IPTV de España en el puerto 2 del router
  • Ciertos clientes de tu red saliendo por IP española (cuando el hEX esté en su sitio, si se lo das a un vecino, podrías comprobar que sales por su IP en lugar de por la tuya, consultando https://www.ipify.org)

IPTV

Empezamos por la IPTV. Necesitamos estas cosas: un nuevo bridge, un túnel EoIP, que corra dentro del túnel Wireguard, asociarlo todo y crear una regla de firewall que permita el tráfico GRE en input. Esta última regla no es estrictamente necesaria, pero hemos descubierto que, si no la ponemos, el túnel EoIP no levantará si quien origina la conexión de ese túnel es el hEX.

Primero: añadir un nuevo bridge con IGMP-Snooping activado: Bridge -> Bridge -> + (nombre que tú quieras y marcado IGMP Snooping)
1653727969796.png


Segundo: Creamos un túnel EoIP sobre las IPs internas del túnel Wireguard. Las IPs internas son las que tienes en IP -> Address sobre las interfaces Wireguard. En el hAP, la ip "local" será la 172.17.0.1 y la remota la 172.17.0.2. Si te fijas, en el hEX lo tienes justo igual, pero a la inversa. Para crearlo, vamos a Interfaces -> EoIP Tunnel (pestaña) -> + -> y rellenamos de la siguiente forma:
1653728437350.png

La dirección MAC no la pongas como la tengo yo, deja que él genere la que necesite. Rellena únicamente el nombre (llámalo como quieras, yo. lo llamé eoip-iptv), el MTU = 1500, La dirección local y la remota. El túnel ID no hace falta que lo toques, porque en el otro extremo está también puesto el 0. Este último dato es muy importante: dos túneles EoIP sólo se comunicarán entre sí si tienen el mismo Tunnel ID.

Y, por último, metemos los dos puertos que van a estar relacionados entre sí en el nuevo bridge: ether2 y el eoip-iptv. Esto hará que ambos estén en el mismo segmento de broadcast, y que el DHCP se transporte desde el HGU -> puesto 2 del hAP-ac3, como por arte de magia.

Bridge -> Ports -> + -> Bridge = bridge-iptv, puerto = ether2 (donde ves mi ether7) y repites la operación para el EoIP
1653728834672.png


Nos queda la regla de firewall para el GRE. Te la paso por comandos y te digo dónde debes ponerla. Cuando la crees, se creará como la última regla del firewall. Tienes luego que pinchar sobre ella y arrastrarla, soltándola en la posición que está justo detrás de la regla que reza con el comentario "defconf: accept ICMP". Ese es el mejor sitio para esa regla.
Código:
add action=accept chain=input comment="iptv: allow gre for eoip" \
    in-interface=wg-sts-es protocol=gre

Y, con la parte de IPTV, habríamos terminado. ¿cómo se prueba, antes de que te lo lleves a España? Muy sencillo. Cuando lo tengas pinchado en casa de tu colega y verifiquemos que ambos túneles levantan, tanto el Wireguard como el EoIP que va dentro, simplemente conecta un equipo por cable al puerto 2 del hAP-ac3. Si lo hemos hecho bien, ese equipo cogerá una IP del segmento de red de la casa de tu colega, pasando a ser un equipo más de su red. Si eso funciona, funcionará con el desco.

Enrutamiento dinámico

Para esto, lo primero que vamos a hacer es un agujero en el pool del DHCP. En verdad, vamos a hacer dos, dejando un hueco por delante, y otro por detrás. El hueco por delante lo usaremos para asignar direcciones reservadas en el DHCP para equipos de tu red que quieras que tengan "ip estática" (como por ejemplo el NAS). Este agujero estará al principio del DHCP, y ocupará, por ejemplo (esto ya a tu antojo), de la dirección .2 a la .21 (20 IPs). El segundo agujero se lo haremos por detrás, y ahora te explicaré la magia detrás del asunto. Ahora mismo el pool va hasta al dirección .254 y vamos a recortarla para que sólo llegue hasta la dirección 247. De esta manera, podremos crear una subred ficticia, la 192.168.88.248/29, que englobará los equipos desde la 192.168.88.249 (primer equipo) hasta el 192.168.88.254 (último equipo de esa subred), con un total de 6 direcciones usables (si ves que son pocas me dices, y lo ampliamos a un /2:cool:.

Sin más, vamos a IP -> Pool, y hacemos ese agujero en el pool que ya tienes por defecto ahí creado, dejando el pool desde la 192.168.88.22 - 192.168.88.247

1653729831128.png


Ahora, vamos a IP -> DHCP -> Leases y empezamos a colocar los equipos donde los queremos. En esa pestaña podrás ver todos los equipos de tu red que ahora mismo le han pedido prestada una IP al router por DHCP. Simplemente localizas los que te interesa poner como estáticos (primer hueco por delante del pool) y doble click a la entrada, y pulsas el botón "Make Static". Hecho esto cierras la ventana y verás que, para esa línea, ha desaparecido la "D" que tenía en la primera columna, que te indicaba que era un equipo asignado dinámicamente. Vuelves a hacer doble click en él, y ahora verás que hay un montón de campos editables, de los cuales sólo vas a tocar la IP. Si estás en el caso del NAS, le darías una IP que caiga en el hueco 192.168.88.2 - 192.168.88.21, la 192.168.88.2 para el NAS, por ejemplo. Si se trata de uno de los equipos que quieres sacar por IP española, le darías una IP que caiga dentro del las seis ultimas IP's del pool: 192.168.88.249, por ejemplo.

Hecho esto, que no es más que una triquiñuela para lo que viene a continuación, lo único que te queda por hacer es el enrutamiento dinámico. Para ello vamos a dar tres pasos:

Primero: creamos la nueva tabla de rutas
Código:
/routing table
add fib name=toSpain

Segundo: creamos la regla de routeo condicional: si perteneces al rango 192.168.88.248/29, te vas a consultar tu ruta a la nueva tabla de rutas. Aquí tenemos dos opciones: forzar que sólo pueda salir por esa tabla de rutas (action = lookup-only) ó intentar salir por esa tabla de rutas siempre que sea posible, sino, salir por la tabla por defecto, que sale por UK. Me decanto por la última, para no dejar a esos equipos tirados sin conexión el día que se te caiga el túnel. Pero, obviamente, esto a tu gusto y consideración.
Código:
/routing rule
add action=lookup src-address=192.168.88.248/29 table=toSpain

Tercero: creamos una ruta por defecto para la tabla "toSpain", que tenga como gateway la IP del otro lado del túnel Wireguard, de tal manera que lo que vaya por esa tabla, salga a internet por el otro lado del túnel. Si por lo que sea no es alcanzable, el tráfico tratará de salir por la ruta por defecto (tu conexión de UK), acorde con la acción que hemos hecho antes. Como de momento no tenemos túnel, esa será el comportamiento actual, hasta que levantes el túnel con casa de tu amigo o el definitivo en España. Es decir, todo funcionará tal y como lo tienes ahora mismo.
Código:
/ip route
add gateway=172.17.0.2 routing-table=toSpain

Et Volià! Ya tienes un routeo condicional funcionando, de la manera más simple que se me ha ocurrido montarlo (hay mil maneras).

Saludos, y cualquier duda, me dices!
 
Sobre qué hacer con la IP del hEX... dudo. El segmento de trabajo del router Movistar de Barcelona, lo he consulta vía web, y es el siguiente:

Router Movistar (Mitrastar GPT-2541GNAC)

Red LAN
IP del router: 192.168.1.1
Máscara de red: 255.255.255.0
IP inicio DHCP; 192.168.1.33
IP fin DHCP: 192.168.1.199
Servidor DNS: 80.58.61.254

Tal y como está el hEX, tomando la ip que le de el HGU, es muy práctico porque es llegar enchufar y listo. El problema que le veo, y quizás me equivoque, es que cuando llegue a Barcelona, lo conecte, mire la ip que le ha dado, supongamos sea la 192.168.1.50, entonces abro los puertos para esa ip: 192.168.1.50. Pero ¿Qué sucederá si un día alguien en casa apaga de la corriente el hEX, lo vuelve a encender, y entonces el HGU le da la ip 192.168.1.60? entiendo que habría que ir a la web del HGU y modificar la regla de los puertos para que los abra para la 192.168.1.60, ¿correcto? Cosa que no veo mucha molestia, porque abrir y cerrar puertos del HGU lo puedo hacer en remoto desde UK.
Así lo harás allí: en ese menú puedes asociar que un equipo al que se entrega IP por DHCP, se le entregue siempre la misma IP. Desconozco si lo mismo se puede hacer desde el menú básico del HGU, en el apartado de Mapa de Red (ahora mismo no tengo ninguno en modo router a mano).

1653731247664.png


Saludos!
 
@pokoyo ya he conectado el hEX en casa de un amigo, ¿cómo podemos chequear que la cosa está funcionando?

Me pongo con los deberes de arriba
 
Pues mira, muy fácil, abre un terminal dentro de winbox y haz ping a la 172.17.0.2, que es el otro extremo del túnel wireguard. Si responde, esos dos equipos ya están enlazados. Otra buena señal es que la interfaz EoIP aparezca con el flag "RS" en la lista de interfaces.

Saludos!
 
Nos queda el último paso, que consiste en rematar el hAP-ac3 para tener:
  • IPTV de España en el puerto 2 del router
  • Ciertos clientes de tu red saliendo por IP española (cuando el hEX esté en su sitio, si se lo das a un vecino, podrías comprobar que sales por su IP en lugar de por la tuya, consultando https://www.ipify.org)

IPTV

Empezamos por la IPTV. Necesitamos estas cosas: un nuevo bridge, un túnel EoIP, que corra dentro del túnel Wireguard, asociarlo todo y crear una regla de firewall que permita el tráfico GRE en input. Esta última regla no es estrictamente necesaria, pero hemos descubierto que, si no la ponemos, el túnel EoIP no levantará si quien origina la conexión de ese túnel es el hEX.

Primero: añadir un nuevo bridge con IGMP-Snooping activado: Bridge -> Bridge -> + (nombre que tú quieras y marcado IGMP Snooping)
Ver el adjunto 95577

Segundo: Creamos un túnel EoIP sobre las IPs internas del túnel Wireguard. Las IPs internas son las que tienes en IP -> Address sobre las interfaces Wireguard. En el hAP, la ip "local" será la 172.17.0.1 y la remota la 172.17.0.2. Si te fijas, en el hEX lo tienes justo igual, pero a la inversa. Para crearlo, vamos a Interfaces -> EoIP Tunnel (pestaña) -> + -> y rellenamos de la siguiente forma:
Ver el adjunto 95580
La dirección MAC no la pongas como la tengo yo, deja que él genere la que necesite. Rellena únicamente el nombre (llámalo como quieras, yo. lo llamé eoip-iptv), el MTU = 1500, La dirección local y la remota. El túnel ID no hace falta que lo toques, porque en el otro extremo está también puesto el 0. Este último dato es muy importante: dos túneles EoIP sólo se comunicarán entre sí si tienen el mismo Tunnel ID.

Y, por último, metemos los dos puertos que van a estar relacionados entre sí en el nuevo bridge: ether2 y el eoip-iptv. Esto hará que ambos estén en el mismo segmento de broadcast, y que el DHCP se transporte desde el HGU -> puesto 2 del hAP-ac3, como por arte de magia.

Bridge -> Ports -> + -> Bridge = bridge-iptv, puerto = ether2 (donde ves mi ether7) y repites la operación para el EoIP
Ver el adjunto 95583

Nos queda la regla de firewall para el GRE. Te la paso por comandos y te digo dónde debes ponerla. Cuando la crees, se creará como la última regla del firewall. Tienes luego que pinchar sobre ella y arrastrarla, soltándola en la posición que está justo detrás de la regla que reza con el comentario "defconf: accept ICMP". Ese es el mejor sitio para esa regla.
Código:
add action=accept chain=input comment="iptv: allow gre for eoip" \
    in-interface=wg-sts-es protocol=gre

Y, con la parte de IPTV, habríamos terminado. ¿cómo se prueba, antes de que te lo lleves a España? Muy sencillo. Cuando lo tengas pinchado en casa de tu colega y verifiquemos que ambos túneles levantan, tanto el Wireguard como el EoIP que va dentro, simplemente conecta un equipo por cable al puerto 2 del hAP-ac3. Si lo hemos hecho bien, ese equipo cogerá una IP del segmento de red de la casa de tu colega, pasando a ser un equipo más de su red. Si eso funciona, funcionará con el desco.

Enrutamiento dinámico

Para esto, lo primero que vamos a hacer es un agujero en el pool del DHCP. En verdad, vamos a hacer dos, dejando un hueco por delante, y otro por detrás. El hueco por delante lo usaremos para asignar direcciones reservadas en el DHCP para equipos de tu red que quieras que tengan "ip estática" (como por ejemplo el NAS). Este agujero estará al principio del DHCP, y ocupará, por ejemplo (esto ya a tu antojo), de la dirección .2 a la .21 (20 IPs). El segundo agujero se lo haremos por detrás, y ahora te explicaré la magia detrás del asunto. Ahora mismo el pool va hasta al dirección .254 y vamos a recortarla para que sólo llegue hasta la dirección 247. De esta manera, podremos crear una subred ficticia, la 192.168.88.248/29, que englobará los equipos desde la 192.168.88.249 (primer equipo) hasta el 192.168.88.254 (último equipo de esa subred), con un total de 6 direcciones usables (si ves que son pocas me dices, y lo ampliamos a un /2:cool:.

Sin más, vamos a IP -> Pool, y hacemos ese agujero en el pool que ya tienes por defecto ahí creado, dejando el pool desde la 192.168.88.22 - 192.168.88.247

Ver el adjunto 95586

Ahora, vamos a IP -> DHCP -> Leases y empezamos a colocar los equipos donde los queremos. En esa pestaña podrás ver todos los equipos de tu red que ahora mismo le han pedido prestada una IP al router por DHCP. Simplemente localizas los que te interesa poner como estáticos (primer hueco por delante del pool) y doble click a la entrada, y pulsas el botón "Make Static". Hecho esto cierras la ventana y verás que, para esa línea, ha desaparecido la "D" que tenía en la primera columna, que te indicaba que era un equipo asignado dinámicamente. Vuelves a hacer doble click en él, y ahora verás que hay un montón de campos editables, de los cuales sólo vas a tocar la IP. Si estás en el caso del NAS, le darías una IP que caiga en el hueco 192.168.88.2 - 192.168.88.21, la 192.168.88.2 para el NAS, por ejemplo. Si se trata de uno de los equipos que quieres sacar por IP española, le darías una IP que caiga dentro del las seis ultimas IP's del pool: 192.168.88.249, por ejemplo.

Hecho esto, que no es más que una triquiñuela para lo que viene a continuación, lo único que te queda por hacer es el enrutamiento dinámico. Para ello vamos a dar tres pasos:

Primero: creamos la nueva tabla de rutas
Código:
/routing table
add fib name=toSpain

Segundo: creamos la regla de routeo condicional: si perteneces al rango 192.168.88.248/29, te vas a consultar tu ruta a la nueva tabla de rutas. Aquí tenemos dos opciones: forzar que sólo pueda salir por esa tabla de rutas (action = lookup-only) ó intentar salir por esa tabla de rutas siempre que sea posible, sino, salir por la tabla por defecto, que sale por UK. Me decanto por la última, para no dejar a esos equipos tirados sin conexión el día que se te caiga el túnel. Pero, obviamente, esto a tu gusto y consideración.
Código:
/routing rule
add action=lookup src-address=192.168.88.248/29 table=toSpain

Tercero: creamos una ruta por defecto para la tabla "toSpain", que tenga como gateway la IP del otro lado del túnel Wireguard, de tal manera que lo que vaya por esa tabla, salga a internet por el otro lado del túnel. Si por lo que sea no es alcanzable, el tráfico tratará de salir por la ruta por defecto (tu conexión de UK), acorde con la acción que hemos hecho antes. Como de momento no tenemos túnel, esa será el comportamiento actual, hasta que levantes el túnel con casa de tu amigo o el definitivo en España. Es decir, todo funcionará tal y como lo tienes ahora mismo.
Código:
/ip route
add gateway=172.17.0.2 routing-table=toSpain

Et Volià! Ya tienes un routeo condicional funcionando, de la manera más simple que se me ha ocurrido montarlo (hay mil maneras).

Saludos, y cualquier duda, me dices!

Todo hecho, pero no sé si hay algo que he hecho mal porque:

Captura.JPG


Tengo dos teléfonos que son los dos marcados, que han cogido esas dos ip's, 248 y 253, y claro, se están yendo "a España" y por tanto ahora no tienen internet. ¿Algo he hecho mal?

Te subo la configuración:
 

Adjuntos

  • myconfig.cfg.txt
    9.2 KB · Visitas: 44
Pues mira, muy fácil, abre un terminal dentro de winbox y haz ping a la 172.17.0.2, que es el otro extremo del túnel wireguard. Si responde, esos dos equipos ya están enlazados. Otra buena señal es que la interfaz EoIP aparezca con el flag "RS" en la lista de interfaces.

Saludos!

Creo que no acaba de funcionar:

Captura2.JPG


El chequeo de la otra manera, "Otra buena señal es que la interfaz EoIP aparezca con el flag "RS" en la lista de interfaces." no he sabido verlo, no veo el flag "RS".
 
Todo hecho, pero no sé si hay algo que he hecho mal porque:

Ver el adjunto 95601

Tengo dos teléfonos que son los dos marcados, que han cogido esas dos ip's, 248 y 253, y claro, se están yendo "a España" y por tanto ahora no tienen internet. ¿Algo he hecho mal?

Te subo la configuración:
Después de modificar el Pool, reinicia el equipo. Es la manera más rápida de que se limpie esa tabla y los equipos que piden conexión dinámica caigan dentro del nuevo pool definido.

Para el resto, pásame un export del hAP-ac3, que lo reviso (del hEX tengo el último que me mandaste, y tiene buena pinta).

Intenta también hacer ping a la DDNS del hEX, para ver si la ha resgistrado o no. ¿llegaste aconectarte a ese equipo en casa de tu colega, o simplemente le dijiste "enchúfalo y listo" ?

Saludos!
 
Después de modificar el Pool, reinicia el equipo. Es la manera más rápida de que se limpie esa tabla y los equipos que piden conexión dinámica caigan dentro del nuevo pool definido.

Para el resto, pásame un export del hAP-ac3, que lo reviso (del hEX tengo el último que me mandaste, y tiene buena pinta).

Tras modificar el Pool he reiniciado el equipo y ahí ha aparecido el problema.

Te paso el fichero de configuración del hAP-ac3.


Intenta también hacer ping a la DDNS del hEX, para ver si la ha resgistrado o no. ¿llegaste aconectarte a ese equipo en casa de tu colega, o simplemente le dijiste "enchúfalo y listo" ?

Saludos!
Llegue, lo conecté al router y a la corriente y me fuí. No hice nada más. He hecho ping al DDNS del hEX y coñe parece que funciona....

Captura.JPG
 

Adjuntos

  • myconfig.cfg.txt
    9.2 KB · Visitas: 49
Tienes dos cosas mal:
- En lugar de modificar el pool, has creado uno nuevo. Borra el que se llama "pool1" y modifica el que se llama "dhcp" a secas, que es el que usa el servidor DHCP. Hecho esto, reinicia, ya verás como los equipos "encajan" ahora en su sitio
- Te falta el Peer que representa al hEX, así que es normal que este no contacte contigo.

Código:
/interface wireguard peers
add allowed-address=0.0.0.0/0 endpoint-address=XXXXXXXXXXXXX.sn.mynetname.net \
    endpoint-port=15321 interface=wg-sts-es persistent-keepalive=25s \
    public-key="LAQUESEA_DE_LA_INTERFAZ_WG_STS_UK_DEL_HEX"

Saludos!
 
Tienes dos cosas mal:
- En lugar de modificar el pool, has creado uno nuevo. Borra el que se llama "pool1" y modifica el que se llama "dhcp" a secas, que es el que usa el servidor DHCP. Hecho esto, reinicia, ya verás como los equipos "encajan" ahora en su sitio
Ahora sí, perfecto, de hecho ahora entiendo la lógica de lo que hemos hecho!

- Te falta el Peer que representa al hEX, así que es normal que este no contacte contigo.
Código:
/interface wireguard peers
add allowed-address=0.0.0.0/0 endpoint-address=XXXXXXXXXXXXX.sn.mynetname.net \
    endpoint-port=15321 interface=wg-sts-es persistent-keepalive=25s \
    public-key="LAQUESEA_DE_LA_INTERFAZ_WG_STS_UK_DEL_HEX"

Saludos!

Aquí tengo perdona una duda... estoy ya liado...

en endpoint-address=XXXXXXXXXXXXX.sn.mynetname.net qué número de serie he de meter el del hAP o el del hEX? el del hAP, no?
 
Ahora sí, perfecto, de hecho ahora entiendo la lógica de lo que hemos hecho!

- Te falta el Peer que representa al hEX, así que es normal que este no contacte contigo.


Aquí tengo perdona una duda... estoy ya liado...

en endpoint-address=XXXXXXXXXXXXX.sn.mynetname.net qué número de serie he de meter el del hAP o el del hEX? el del hAP, no?
No, lo que hay en "peers" representa siempre tu remoto. En endpoin-address va la dirección DDNS del hEX, a igual que en public-key va la clave pública que tiene la interfaz STS en el hEX.

Saludos!
 
No, lo que hay en "peers" representa siempre tu remoto. En endpoin-address va la dirección DDNS del hEX, a igual que en public-key va la clave pública que tiene la interfaz STS en el hEX.

Saludos!

hecho, pero hago el ping a 172.17.0.2 y se pierde...

Captura2.JPG


Te paso por privado el fichero de configuración, sin borrar nada.
 
Interconectados ya ambos equipos, me comentabas por privado que la parte del routing condicional no te funcionaba (los equipos de la parte alta del pool que van directos a tu wifi, no vía ether2). Revisando la config, veo que nos faltan un par de cosas. Pero es casi más interesante el por qué no funciona, que lo que falta, así que te lo explico en público:

El router al que nos estamos conectando no está operando en modo router, no tiene una parte WAN y otra LAN bien diferenciada, sino que se comporta como un switch y por tanto no hace NAT de la interfaz WAN por defecto, como sí lo hace tu hAP-ac3. Esto hace que, cuando tú le mandas tráfico desde la 192.168.88.0/24 (tu subred en el hAP-ac3), no sepa qué narices hacer con él, puesto que él no entiende más que de la 192.168.1.X. Dicho tráfico, al igual que el tráfico que genera la VPN de tipo rw, necesita subir un nivel para salir a internet, es decir, necesita cambiar esa IP del tipo 192.168.88.0/24 por una del segmento al que está conectado, 192.168.1.X, subred que sí entiende dicho router. Es decir, nos falta una regla de NAT.

Además de eso, tu configuración del servidor DHCP ahora mismo entrega como DNS la IP del propio router, cosa que no nos viene del todo bien cuando le estamos pidiendo salir por un gateway que no eres tú. Así que, para esa parte del pool, vamos a entregar directamente un DNS público, tipo los de google (o los que más te gusten, pero públicos).

Los cambios son los siguientes:

En el hAP-ac3: vamos a añadir una subred nueva al DHCP, diciendo que los equipos de esa subred van con DNS público:
Código:
/ip dhcp-server network
add address=192.168.88.248/29 dns-server=8.8.8.8,8.8.4.4 gateway=192.168.88.1 netmask=24

En el hEX: vamos a natear lo que venga de la subred 192.168.88.0/24 y salga por el bridge-iptv
Código:
/ip firewall nat
add action=masquerade chain=srcnat comment="masq. uk connections" out-interface=\
    bridge-iptv src-address=192.168.88.248/29

Con ese par de cambios, y reiniciando los equipos que están en esa parte del pool para que refresquen la configuración del DHCP, debería funcionar y poder salir por la IP de tu colega. Prueba, y me dices.

PS: puedes conectarte al hEX usando winbox, desde cualquier equipo de tu red del hAP-ac3, simplemente accediendo a la IP del extremo del túnel wireguard: 172.17.0.2

Saludos!
 
Interconectados ya ambos equipos, me comentabas por privado que la parte del routing condicional no te funcionaba (los equipos de la parte alta del pool que van directos a tu wifi, no vía ether2). Revisando la config, veo que nos faltan un par de cosas. Pero es casi más interesante el por qué no funciona, que lo que falta, así que te lo explico en público:

El router al que nos estamos conectando no está operando en modo router, no tiene una parte WAN y otra LAN bien diferenciada, sino que se comporta como un switch y por tanto no hace NAT de la interfaz WAN por defecto, como sí lo hace tu hAP-ac3. Esto hace que, cuando tú le mandas tráfico desde la 192.168.88.0/24 (tu subred en el hAP-ac3), no sepa qué narices hacer con él, puesto que él no entiende más que de la 192.168.1.X. Dicho tráfico, al igual que el tráfico que genera la VPN de tipo rw, necesita subir un nivel para salir a internet, es decir, necesita cambiar esa IP del tipo 192.168.88.0/24 por una del segmento al que está conectado, 192.168.1.X, subred que sí entiende dicho router. Es decir, nos falta una regla de NAT.

Además de eso, tu configuración del servidor DHCP ahora mismo entrega como DNS la IP del propio router, cosa que no nos viene del todo bien cuando le estamos pidiendo salir por un gateway que no eres tú. Así que, para esa parte del pool, vamos a entregar directamente un DNS público, tipo los de google (o los que más te gusten, pero públicos).

Los cambios son los siguientes:

En el hAP-ac3: vamos a añadir una subred nueva al DHCP, diciendo que los equipos de esa subred van con DNS público:
Código:
/ip dhcp-server network
add address=192.168.88.248/29 dns-server=8.8.8.8,8.8.4.4 gateway=192.168.88.1 netmask=24

En el hEX: vamos a natear lo que venga de la subred 192.168.88.0/24 y salga por el bridge-iptv
Código:
/ip firewall nat
add action=masquerade chain=srcnat comment="masq. uk connections" out-interface=\
    bridge-iptv src-address=192.168.88.248/29

Con ese par de cambios, y reiniciando los equipos que están en esa parte del pool para que refresquen la configuración del DHCP, debería funcionar y poder salir por la IP de tu colega. Prueba, y me dices.

PS: puedes conectarte al hEX usando winbox, desde cualquier equipo de tu red del hAP-ac3, simplemente accediendo a la IP del extremo del túnel wireguard: 172.17.0.2

Saludos!

Cambios hechos y ..... FUNCIONA!!! eres un mago.

Ahora las dos radios, se conectan al wifi, cogen las ip's que le fijamos la .249 y .250, y en la información de conexión de las radios sale la ip de casa de mi amigo!!

Por cierto el poder acceder al hEX desde la 172.17.0.2 es la releche!

voy a hacer un back up de ambos equipos y a guardarlos bajo llave.

PD: Si como creo ya hemos acabado de la configuración de ambos, escribo un nuevo mensaje en 5 minutos con un "mini bonus track".
 
Cambios hechos y ..... FUNCIONA!!! eres un mago.

Ahora las dos radios, se conectan al wifi, cogen las ip's que le fijamos la .249 y .250, y en la información de conexión de las radios sale la ip de casa de mi amigo!!

Por cierto el poder acceder al hEX desde la 172.17.0.2 es la releche!

voy a hacer un back up de ambos equipos y a guardarlos bajo llave.

PD: Si como creo ya hemos acabado de la configuración de ambos, escribo un nuevo mensaje en 5 minutos con un "mini bonus track".
Creo que lo tenemos medio preparado. Se pueden hacer mil cosas más, pero lo básico lo tienes ya funcionando como querías.

Saludos, y que lo disfrutes! ;)
 
Creo que lo tenemos medio preparado. Se pueden hacer mil cosas más, pero lo básico lo tienes ya funcionando como querías.

Saludos, y que lo disfrutes! ;)

Creo que vale la pena dejarlo como está, testearlo unas semanas, hasta marchar a Barcelona el 21 de Junio.

Sólo te "propongo" un bonus track, si te parece que no hay riesgo de fastidiar nada, aunque con tu mensaje anterior :

Además de eso, tu configuración del servidor DHCP ahora mismo entrega como DNS la IP del propio router, cosa que no nos viene del todo bien cuando le estamos pidiendo salir por un gateway que no eres tú. Así que, para esa parte del pool, vamos a entregar directamente un DNS público, tipo los de google (o los que más te gusten, pero públicos).

Bonus track: Pi-Hole

Como esta mañana me la habías dado libre, sin deberes, he estado navegando y he leído este artículo:

Y la verdad es que el tema de la publicidad es fatigoso... suelo leer los periódicos vía web cada mañana y es un horror la cantidad de anuncios que te salen por los lados. Total he pensado, parece sencillo instalar eso en el Synology DS218+ que tengo y que creo que esta bastante infrautilizado. Dado que tiene 6GB de RAM (2GB + 4GB de expansión) creo que ponerle un Docker con un Pi-hole no será cargarle las tintas.

Así que lo he instalado en el Synology y lo he configurado según el artículo, PERO, por prudencia no he tocado nada en el hAP, porque entiendo que en IP / DNS Settings:

DNS Settings.JPG


Habría que cambiar el Servers por la 192.168.88.2 (ip del NAS) y la siguiente línea 1.1.1.1:

DNS Settings2.jpg


¿estoy en lo correcto? ¿crees que vale la pena o pone en peligro algo de lo que hemos hecho?

Gracias por todo.
 
Creo que vale la pena dejarlo como está, testearlo unas semanas, hasta marchar a Barcelona el 21 de Junio.

Sólo te "propongo" un bonus track, si te parece que no hay riesgo de fastidiar nada, aunque con tu mensaje anterior :



Bonus track: Pi-Hole

Como esta mañana me la habías dado libre, sin deberes, he estado navegando y he leído este artículo:

Y la verdad es que el tema de la publicidad es fatigoso... suelo leer los periódicos vía web cada mañana y es un horror la cantidad de anuncios que te salen por los lados. Total he pensado, parece sencillo instalar eso en el Synology DS218+ que tengo y que creo que esta bastante infrautilizado. Dado que tiene 6GB de RAM (2GB + 4GB de expansión) creo que ponerle un Docker con un Pi-hole no será cargarle las tintas.

Así que lo he instalado en el Synology y lo he configurado según el artículo, PERO, por prudencia no he tocado nada en el hAP, porque entiendo que en IP / DNS Settings:

Ver el adjunto 95628

Habría que cambiar el Servers por la 192.168.88.2 (ip del NAS) y la siguiente línea 1.1.1.1:

Ver el adjunto 95631

¿estoy en lo correcto? ¿crees que vale la pena o pone en peligro algo de lo que hemos hecho?

Gracias por todo.
Ishhhh, casi! Esos dns son los del propio router, no los toques, porque no va a tener el efecto que deseas, ya que el router dispara peticiones dns a ambas direcciones por igual, así que solo vas a filtrar, con suerte, la mitad.

La manera correcta de entregar esas direcciones es el en servidor dhcp. Igual que antes hemos metido una entrada adicional para la subred /29, para entregarles un dns público concreto, puedes hacer lo mismo en la otra entrada que existe en ese mismo menú para la subred principal 192.168.88.0/24. Lo encontrarás en IP > DHCP Server > Networks.

Como IP principal entregarías la del pi-hole, y como secundaria (failover, aquí sí respeta el orden), la del propio router, que es la única que verás entregada ahí ahora mismo.

Prueba y me dices. Luego te mando cómo tunearlo aún un pelín más, a nivel de config del pi-hole.

Saludos!
 
Arriba