hostapd y OpenVPN en un solo Pi: ¿de quién es la ruta predeterminada?

Los teléfonos se asocian al punto de acceso, reciben una dirección y luego no llegan a nada en absoluto en cuanto sube el túnel. hostapd suele estar sano en ese estado, y OpenVPN también; lo que se rompe es la ruta predeterminada, que o nunca existió en el puente o el túnel la reemplazó sin dejar un camino hacia el propio servidor VPN. Este manual devuelve esa ruta a su sitio y demuestra el resultado desde un cliente y no desde el Pi. Cada paso es reversible, y nada de aquí cambia la configuración del túnel hasta que sepa qué tráfico quiere dentro de él.

Inventaríe las interfaces antes de editar nada

El diseño habitual coloca la radio inalámbrica y el puerto cableado dentro de br0, arranca hostapd contra el puente y reparte concesiones desde dnsmasq, mientras un cliente OpenVPN crea tun0. Entonces tres requisitos separados parecen uno: los clientes del punto de acceso necesitan el Pi como su puerta de enlace, el Pi necesita una ruta a internet para alcanzar su servidor, y el puente necesita una dirección de puerta de enlace que esos clientes puedan usar.

Lea el estado actual antes de cambiarlo, porque estos cuatro comandos separan un problema de interfaz de un problema de enrutamiento.

ip -br addr
ip route show
ip link show master br0
bridge link show

Si br0 lleva una dirección pero ninguna ruta predeterminada, los clientes llegan al Pi y a nada más allá. Si la ruta predeterminada apunta a tun0 mientras el túnel está caído, el Pi no tiene ningún camino operativo, y el síntoma del cliente se ve exactamente igual. Ambos casos se ven idénticos desde un teléfono, por lo que la tabla de rutas debe leerse directamente.

Dé al puente una ruta predeterminada que le pertenezca

Raspberry Pi OS suele dejar el puente sin ruta predeterminada cuando el puente surgió después de escribir el archivo de interfaz. La estrofa pertenece a /etc/dhcpcd.conf, y debería nombrar el router ascendente en lugar del Pi.

interface br0
static ip_address=192.168.50.2/24
static routers=192.168.50.1
static domain_name_servers=192.168.50.1

En ese ejemplo 192.168.50.1 es el router existente y 192.168.50.2 es la dirección del puente del Pi en la misma subred, así que sustituya con su propio plan en lugar de copiar los números. Los miembros del puente tampoco deben pedir routers, o el Pi acabará con rutas predeterminadas competidoras cuya ganadora depende de la métrica y del momento y no de la intención.

Después de systemctl restart dhcpcd, ip route show default debería listar br0 una vez y ningún duplicado del puerto cableado. Confirme la consulta y no la tabla, porque una entrada obsoleta puede sentarse junto a una ganadora: ip -4 route get 203.0.113.10 tiene que nombrar br0. Esa dirección proviene del rango de documentación TEST-NET-3, así que no puede chocar con un servidor real mientras lee esto.

Impida que el túnel secuestre el camino hacia su propio servidor

Un cliente OpenVPN que acepta redirect-gateway toma la ruta predeterminada y la apunta hacia el túnel. Eso es correcto cuando cada cliente del punto de acceso debería usar la VPN, e incorrecto cuando solo deberían algunos destinos. En cualquier caso, la propia conexión del Pi con el servidor no debe viajar dentro del túnel que aún está construyendo. OpenVPN añade una ruta de host hacia el remoto a través de la puerta de enlace original cuando redirige la predeterminada, y ese es exactamente el comportamiento que mantiene vivo el transporte; si esa ruta falta, el túnel colapsa en cuanto se establece.

Una comparación rápida de esa ruta de transporte antes y después de conectar vale los diez segundos. ip -4 route get 203.0.113.10 debería nombrar el dispositivo subyacente en ambos estados, con solo la métrica cambiando. Si nombra tun0 después de que suba el túnel, la ruta de host nunca se instaló y la próxima reconexión fallará.

Cuando solo prefijos seleccionados deban cruzar el túnel, use route-nopull y añada las rutas que quiera a mano, o envíe un conjunto más estrecho desde el servidor. El puente conserva la ruta predeterminada en ese diseño, y el DNS se convierte en la siguiente decisión: el reenvío de dnsmasq a un resolutor doméstico solo tiene sentido para los nombres que realmente viven allí.

Decida la historia del reenvío y del NAT

El túnel completo necesita el reenvío activado en el Pi y una puerta de enlace del lado remoto dispuesta a enrutar la subred del punto de acceso. Compruebe el reenvío antes que nada, porque un cero hace irrelevante cualquier cambio de ruta.

sysctl net.ipv4.ip_forward
sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A POSTROUTING -s 192.168.50.0/24 -o tun0 -j MASQUERADE

La regla NAT es el atajo que funciona cuando el servidor no aceptará el prefijo del punto de acceso, a costa de que cada cliente aparezca como la dirección del túnel del Pi en los registros del lado remoto. Enrutar el prefijo sin NAT mantiene las direcciones visibles y depende de una ruta de retorno para 192.168.50.0/24 en el lado de casa.

Anote la elección junto a las reglas del cortafuegos, porque una regla NAT invisible en el diseño se vuelve inexplicable seis meses después. Mantenga IPv6 en la misma decisión; un camino IPv4 que funciona junto a un camino IPv6 roto todavía se lee como medio roto en un navegador.

Verifique desde un cliente y luego revierta limpiamente

Pruebe en este orden desde un teléfono o portátil en el punto de acceso: una concesión de dnsmasq, un ping a la dirección del puente, y luego un destino en el lado remoto del túnel. Cada paso aísla una capa en lugar de producir un único fallo inútil.

ip -4 route get 203.0.113.10
ping -c 3 -I br0 203.0.113.10

Luego confirme que el Pi sigue teniendo su propia salida: ip route get 203.0.113.10 debería nombrar el dispositivo subyacente, y ping -c 3 -I br0 203.0.113.10 debería responder si el servidor permite ICMP. Si los dos primeros pasos del cliente pasan y el tercero falla, el fallo está en el reenvío o el NAT. Si el segundo paso falla, el puente o el DHCP todavía están incompletos.

La reversión es una edición de archivo y dos comandos: quite la estrofa, reinicie dhcpcd y reemplace la ruta predeterminada explícitamente con ip route replace default via 192.168.50.1 dev br0. Hágalo antes de que se cierre la ventana de mantenimiento y no después, porque un Pi que ha perdido su ruta predeterminada es inalcanzable desde la red que usaría para repararlo.