La llamada

Para poder cambiar el módem Huawei HG8145V5 a modo puente, necesitaba las credenciales de administrador (root). El problema es que cambian todos los días. Y, ahí estuve, llamando a las 01:15 hrs y me contestaron de volada. Me tomó unas 5 llamadas para conseguir las claves del día, pero al final la paciencia rindió frutos. Me explicaron que para darme acceso de administrador y ponerme en modo puente, el procedimiento requería contratar una "IP pública dinámica".

A final de cuentas, me pareció una buena idea y decidí pagar los 100 varos extras al mes para salir del Carrier-Grade NAT (CGNAT). Al final sí se armó la cosa: me asignaron una IP pública real y con eso pudimos avanzar sin problemas.

El modem

Ya con acceso root al módem, configuré el equipo para que no se sobrescribiera la configuración con las actualizaciones automáticas remotas (TR-069) y asegurar la estabilidad de la red.

Para lograr esto, hice lo siguiente:

1. Entré a System Management -> TR-069.
2. Desmarqué Enable ACS Management y Enable Periodic Informing.
3. Fui a la configuración de WAN y borré por completo el perfil TR-069 de administración remota. Así les corté el cable de tajo.

Luego, modifiqué el perfil de internet principal (el cual suele llamarse algo como INTERNET_R_VID_XXX):

• Cambié el WAN Mode a Bridge WAN.
• Mantuve habilitado el VLAN ID con el tag correspondiente a mi zona.
• En las opciones de copiado de puertos (Binding Options), seleccioné LAN1, que es donde tengo conectado el cable hacia mi gateway.

Apliqué los cambios y ¡madres!, el módem se convirtió en un simple puente transparente. Mi gateway recibió la IP pública (198.51.100.50) de volada vía DHCP en la interfaz enp3s0.

El drama

En cuanto se activó la IP pública, me di cuenta de que el IPv6 ya no estaba disponible. Volví a hablar con soporte y de manera muy clara me explicaron la situación: en su plataforma, los perfiles del BNG están separados, de modo que el perfil de IP pública es estrictamente IPv4-only. O tienes IP pública o tienes IPv6 nativo, pero no ambos al mismo tiempo.

Como yo no me iba a quedar sin IPv6, decidí usar un túnel broker. Fui a tunnelbroker.net (de Hurricane Electric), me registré y configuré un túnel apuntando a mi nueva IP pública. El servidor de Dallas, TX (198.51.100.1) fue el que me dio menor latencia (unos 62 ms promedio).

El gateway

Aquí es donde viene lo chido. Para que todo funcione de manera permanente, configuré mi gateway con NetworkManager, firewalld y radvd.

Primero, creé el túnel SIT (Simple Internet Transition) en mi gateway ruteado sobre la interfaz física:

# Crear interfaz de túnel SIT en NetworkManager
nmcli connection add \
   type ip-tunnel \
   con-name he-ipv6 \
   ifname he-ipv6 \
   mode sit \
   remote 198.51.100.1 \
   ip-tunnel.parent enp3s0 \
   ipv4.method disabled \
   ipv6.method manual \
   ipv6.addresses "2001:db8:1::2/64" \
   ipv6.gateway "2001:db8:1::1" \
   ipv6.route-metric 100 \
   connection.zone external

Luego, configuré mi interfaz de red local (enp2s0) para manejar mi prefijo ULA (para cosas locales) y el bloque IPv6 global que me dio Hurricane Electric:

# Asignar ULA y GUA pública a la LAN
nmcli connection modify enp2s0 \
   ipv6.method manual \
   ipv6.addresses "fd41::1/64, 2001:db8:2::1/64"
nmcli connection up enp2s0

El Firewall

Para que el túnel levante, el firewall debe permitir el tráfico del protocolo 41 (SIT) desde el servidor de Hurricane Electric. También quería asegurarme de no hacer NAT66 (masquerading) en mi prefijo IPv6 público para tener ruteo nativo, pero sí mantenerlo en mi prefijo ULA (fd41::/64).

Bueno, ahí va el cotorreo para configurar firewalld:

# Permitir protocolo 41 en la zona externa
firewall-cmd --permanent --zone=external --add-rich-rule='rule family="ipv4" source address="198.51.100.1" protocol value="41" accept'

# Quitar masquerading global de IPv6
firewall-cmd --permanent --zone=external --remove-rich-rule='rule family="ipv6" masquerade'

# Habilitar masquerading exclusivo para la ULA
firewall-cmd --permanent --zone=external --add-rich-rule='rule family="ipv6" source address="fd41::/64" masquerade'

# Aplicar cambios
firewall-cmd --reload

Repartiendo IPs con radvd

Para que todos los clientes de la red local obtengan sus IPs globales automáticamente mediante SLAAC, edité el archivo /etc/radvd.conf para anunciar ambos prefijos:

# /etc/radvd.conf
interface enp2s0 {
   AdvSendAdvert on;
   MinRtrAdvInterval 30;
   MaxRtrAdvInterval 100;
   prefix fd41::/64 {
      AdvOnLink on;
      AdvAutonomous on;
      AdvRouterAddr on;
   };
   prefix 2001:db8:2::/64 {
      AdvOnLink on;
      AdvAutonomous on;
      AdvRouterAddr on;
   };
};

Encendí el servicio:

systemctl enable radvd
systemctl restart radvd

La automatización (DDNS)

Como la IP pública de Megacable es dinámica, cada vez que cambie, el túnel de Hurricane Electric se va a romper si no le avisamos al endpoint del nuevo valor de la IP.

Para no tener que andar haciéndolo a mano, me armé un script despachador de NetworkManager en /etc/NetworkManager/dispatcher.d/50-he-tunnel-update.bash que reacciona de volada cuando cambia la IP en la interfaz WAN (enp3s0) y actualiza el túnel mediante la API de HE.

Por mera seguridad, las credenciales (usuario, Update Key de la pestaña Advanced del túnel, e ID del túnel) las guardé en un archivo separado en /usr/local/etc/tunnelbroker.bash con permisos 0600.

El script del dispatcher se ve más o menos así:

#!/usr/bin/bash
# Despachador de NetworkManager para actualizar la IP del túnel
set -euo pipefail
IFS=$'\n\t'

readonly Interface="enp3s0"
readonly ConfigFile="/usr/local/etc/tunnelbroker.bash"
readonly UpdateUrl="https://ipv4.tunnelbroker.net/nic/update"

main() {
    local -r interface="${1:-}"
    local -r action="${2:-}"

    if [[ "$interface" != "$Interface" ]] || [[ "$action" != "up" && "$action" != "dhcp4-change" ]]; then
        return 0
    fi

    # shellcheck source=/dev/null
    source "$ConfigFile"

    # Enviar actualización a HE
    local response
    response=$(curl -4 -sS -G \
        --data-urlencode "username=$username" \
        --data-urlencode "password=$password" \
        --data-urlencode "hostname=$hostname" \
        --data-urlencode "myip=AUTO" \
        "$UpdateUrl")

    if [[ "$response" =~ ^(good|nochg) ]]; then
        # Reiniciar conexión he-ipv6 para refrescar
        nmcli connection up he-ipv6 &>/dev/null || true
    fi
}

main "$@"

¡Madres! Con esto, la actualización de la IP queda automatizada y el túnel se levanta solito sin importar cuántas veces Megacable nos cambie la IP WAN.

La prueba de fuego

En cuanto encendí radvd, mi workstation obtuvo su dirección IPv6 global (2001:db8:2::100/64).

Para probar si de verdad todo jalaba, levanté mi servidor Caddy local y corrí un curl desde un VPS externo (vps.ejemplo.net) apuntando directo a mi IPv6:

ssh vps.ejemplo.net "curl -6 -I -m 5 http://[2001:db8:2::100]/"

Me devolvió un hermoso HTTP/1.1 200 OK de Caddy de volón pimpón. Cero NAT, cero complicaciones y ruteo nativo directo a mi máquina. ¡Una chulada!

¿Qué te parece? Si estás atorado con el doble NAT de tu ISP, mándalos a la chingada y ármate tu propio túnel. Vale totalmente la pena.

Referencias

• Hurricane Electric Tunnelbroker
• Documentación de NetworkManager ip-tunnel