hostapd e OpenVPN nun só Pi: de quen é a ruta predeterminada?

Os teléfonos asócianse ao punto de acceso, reciben un enderezo e despois non chegan a nada en absoluto en canto sobe o túnel. hostapd adoita estar san nese estado, e OpenVPN tamén; o que rompe é a ruta predeterminada, que ou nunca existiu na ponte ou o túnel substituíuna sen deixar un camiño cara ao propio servidor VPN. Este manual devolve esa ruta ao seu sitio e demostra o resultado desde un cliente e non desde o Pi. Cada paso é reversible, e nada aquí cambia a configuración do túnel ata que saiba que tráfico quere dentro del.

Inventarie as interfaces antes de editar nada

A disposición habitual coloca a radio inalámbrica e o porto cableado dentro de br0, arrinca hostapd contra a ponte e reparte concesións desde dnsmasq, mentres un cliente OpenVPN crea tun0. Entón tres requisitos separados parecen un: os clientes do punto de acceso necesitan o Pi como a súa pasarela, o Pi necesita unha ruta a internet para chegar ao seu servidor, e a ponte necesita un enderezo de pasarela que eses clientes poidan usar.

Lea o estado actual antes de cambialo, porque estes catro comandos separan un problema de interface dun problema de encamiñamento.

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

Se br0 leva un enderezo pero ningunha ruta predeterminada, os clientes chegan ao Pi e a nada máis alá. Se a ruta predeterminada apunta a tun0 mentres o túnel está baixo, o Pi non ten ningún camiño operativo, e o síntoma do cliente parece exactamente o mesmo. Ambos os casos vense idénticos desde un teléfono, por iso hai que ler a táboa de rutas directamente.

Déalle á ponte unha ruta predeterminada que lle pertenza

Raspberry Pi OS adoita deixar a ponte sen ruta predeterminada cando a ponte apareceu despois de escribir o ficheiro de interface. A estrofa pertence a /etc/dhcpcd.conf, e debería nomear o router ascendente en lugar do 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

Nese exemplo 192.168.50.1 é o router existente e 192.168.50.2 é o enderezo da ponte do Pi na mesma subrede, así que substitúa polo seu propio plan en lugar de copiar os números. Os membros da ponte tampouco deben pedir routers, ou o Pi acaba con rutas predeterminadas competidoras cuxa gañadora depende da métrica e do momento e non da intención.

Despois de systemctl restart dhcpcd, ip route show default debería listar br0 unha vez e ningún duplicado do porto cableado. Confirme a busca e non a táboa, porque unha entrada vella pode sentar xunto a unha gañadora: ip -4 route get 203.0.113.10 ten que nomear br0. Ese enderezo vén do rango de documentación TEST-NET-3, así que non pode chocar cun servidor real mentres le isto.

Impedide que o túnel secuestre o camiño cara ao seu propio servidor

Un cliente OpenVPN que acepta redirect-gateway toma a ruta predeterminada e diríxea cara ao túnel. Iso é correcto cando cada cliente do punto de acceso debería usar a VPN, e incorrecto cando só deberían algúns destinos. En calquera caso, a propia conexión do Pi co servidor non debe viaxar dentro do túnel que aínda está a construír. OpenVPN engade unha ruta de host cara ao remoto a través da pasarela orixinal cando redirixe a predeterminada, e ese é exactamente o comportamento que mantén vivo o transporte; se esa ruta falta, o túnel colapsa en canto se estabelece.

Unha comparación rápida desa ruta de transporte antes e despois de conectar vale os dez segundos. ip -4 route get 203.0.113.10 debería nomear o dispositivo subxacente en ambos os estados, con só a métrica cambiando. Se nomea tun0 despois de que suba o túnel, a ruta de host nunca se instalou e a próxima reconexión fallará.

Cando só prefixos seleccionados deban cruzar o túnel, use route-nopull e engada as rutas que queira a man, ou envíe un conxunto máis estreito desde o servidor. A ponte conserva a ruta predeterminada nese deseño, e o DNS convértese na decisión seguinte: o reenvío de dnsmasq a un resolvedor doméstico só ten sentido para os nomes que realmente viven alí.

Decida a historia do reenvío e do NAT

O túnel completo necesita o reenvío activado no Pi e unha pasarela do lado remoto disposta a encamiñar a subrede do punto de acceso. Comprobe o reenvío antes que nada, porque un cero fai irrelevante calquera 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

A regra NAT é o atallo que funciona cando o servidor non aceptará o prefixo do punto de acceso, a costa de que cada cliente apareza como o enderezo do túnel do Pi nos rexistros do lado remoto. Encamiñar o prefixo sen NAT mantén os enderezos visibles e depende dunha ruta de retorno para 192.168.50.0/24 no lado da casa.

Anote a elección xunto ás regras do devasamento, porque unha regra NAT invisible no deseño vólvese inexplicable seis meses despois. Manteña IPv6 na mesma decisión; un camiño IPv4 que funciona xunto a un camiño IPv6 roto aínda se le como medio roto nun navegador.

Verifique desde un cliente e logo reverta limpiamente

Probe nesta orde desde un teléfono ou portátil no punto de acceso: unha concesión de dnsmasq, un ping ao enderezo da ponte, e logo un destino no lado remoto do túnel. Cada paso illa unha 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

Despois confirme que o Pi segue tendo a súa propia saída: ip route get 203.0.113.10 debería nomear o dispositivo subxacente, e ping -c 3 -I br0 203.0.113.10 debería responder se o servidor permite ICMP. Se os dous primeiros pasos do cliente pasan e o terceiro falla, o fallo está no reenvío ou no NAT. Se o segundo paso falla, a ponte ou o DHCP aínda están incompletos.

A reversión é unha edición de ficheiro e dous comandos: quite a estrofa, reinicie dhcpcd e substitúa a ruta predeterminada explicitamente con ip route replace default via 192.168.50.1 dev br0. Faga iso antes de que se peche a xanela de mantemento e non despois, porque un Pi que perdeu a súa ruta predeterminada é inalcanzable desde a rede que usaría para reparalo.