hostapd i OpenVPN en un sol Pi: qui és l'amo de la ruta per defecte?

Els telèfons s'associen al punt d'accés, reben una adreça i després no arriben enlloc tan bon punt s'aixeca el túnel. hostapd sol estar sa en aquest estat, i OpenVPN també; el que es trenca és la ruta per defecte, que o bé no va existir mai al pont o bé el túnel la va substituir sense deixar cap camí cap al mateix servidor VPN. Aquest manual torna aquella ruta al seu lloc i demostra el resultat des d'un client, no des del Pi. Cada pas és reversible, i res d'aquí no canvia la configuració del túnel fins que sapigueu quin trànsit voleu dins seu.

Inventorieu les interfícies abans de modificar res

La disposició habitual posa la ràdio sense fils i el port cablejat dins de br0, engega hostapd contra el pont i reparteix concessions des de dnsmasq, mentre que un client OpenVPN crea tun0. Llavors tres requisits separats semblen un de sol: els clients del punt d'accés necessiten el Pi com a passarel·la, el Pi necessita una ruta a internet per arribar al seu servidor, i el pont necessita una adreça de passarel·la que aquests clients puguin fer servir.

Llegiu l'estat actual abans de canviar-lo, perquè aquestes quatre ordres separen un problema d'interfície d'un problema d'encaminament.

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

Si br0 porta una adreça però cap ruta per defecte, els clients arriben al Pi i a res més enllà. Si la ruta per defecte apunta a tun0 mentre el túnel està aturat, el Pi no té cap camí operatiu i el símptoma del client sembla exactament el mateix. Tots dos casos es veuen idèntics des d'un telèfon, i per això cal llegir la taula d'encaminament directament.

Doneu al pont una ruta per defecte que li sigui pròpia

Raspberry Pi OS sovint deixa el pont sense ruta per defecte quan el pont va aparèixer després d'escriure el fitxer d'interfície. L'estrofa pertany a /etc/dhcpcd.conf, i ha de nomenar el router superior en lloc 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 aquest exemple 192.168.50.1 és el router existent i 192.168.50.2 és l'adreça del pont del Pi dins la mateixa subxarxa, així que substituïu-ho pel vostre propi pla en lloc de copiar els números. Els membres del pont tampoc no han de demanar routers, o el Pi acabarà amb rutes per defecte competidores el guanyador de les quals depèn de la mètrica i del moment, no de la intenció.

Després de systemctl restart dhcpcd, ip route show default ha de llistar br0 una vegada i cap duplicat del port cablejat. Confirmeu la consulta i no la taula, perquè una entrada vella pot seure al costat d'una de guanyadora: ip -4 route get 203.0.113.10 ha de nomenar br0. Aquesta adreça prové del rang de documentació TEST-NET-3, així que no pot xocar amb un servidor real mentre llegiu això.

Atureu el túnel perquè no segresti el camí cap al seu propi servidor

Un client OpenVPN que accepta redirect-gateway pren la ruta per defecte i la dirigeix cap al túnel. Això és correcte quan tots els clients del punt d'accés haurien de fer servir la VPN, i incorrecte quan només ho haurien de fer algunes destinacions. De qualsevol manera, la connexió pròpia del Pi al servidor no ha de viatjar dins del túnel que encara està construint. OpenVPN afegeix una ruta d'amfitrió cap al remot a través de la passarel·la original quan redirigeix la ruta per defecte, i aquest és exactament el comportament que manté viu el transport; si aquesta ruta falta, el túnel s'enfonsa tan bon punt s'estableix.

Una comparació ràpida d'aquest camí de transport abans i després de connectar val la pena els deu segons. ip -4 route get 203.0.113.10 ha de nomenar el dispositiu de sota en tots dos estats, amb només la mètrica canviant. Si nomena tun0 després que pugi el túnel, la ruta d'amfitrió no es va instal·lar mai i la propera reconnexió fallarà.

Quan només alguns prefixos han de creuar el túnel, feu servir route-nopull i afegiu les rutes que vulgueu a mà, o envieu un conjunt més estret des del servidor. El pont conserva la ruta per defecte en aquest disseny, i el DNS es converteix en la decisió següent: el reenviament de dnsmasq a un resolutor de casa només té sentit per als noms que realment hi viuen.

Decidiu la història del reenviament i del NAT

El túnel complet necessita el reenviament activat al Pi i una passarel·la de l'altre costat disposada a encaminar la subxarxa del punt d'accés. Comproveu el reenviament abans de res, perquè un zero fa irrelevant qualsevol canvi 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 és la drecera que funciona quan el servidor no acceptarà el prefix del punt d'accés, a canvi que tots els clients apareguin com l'adreça del túnel del Pi als registres de l'altre costat. Encaminar el prefix sense NAT manté les adreces visibles i depèn d'una ruta de retorn per a 192.168.50.0/24 al costat de casa.

Anoteu l'elecció al costat de les regles del tallafocs, perquè una regla NAT invisible en el disseny esdevé inexplicable sis mesos després. Manteniu IPv6 a la mateixa decisió; un camí IPv4 que funciona al costat d'un camí IPv6 trencat encara es llegeix com a mig trencat en un navegador.

Verifiqueu des d'un client i després revertiu net

Proveu en aquest ordre des d'un telèfon o portàtil al punt d'accés: una concessió de dnsmasq, un ping a l'adreça del pont, i després una destinació a l'altre costat del túnel. Cada pas aïlla una capa en lloc de produir un sol fracàs inútil.

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

Després confirmeu que el Pi encara té la seva pròpia sortida: ip route get 203.0.113.10 ha de nomenar el dispositiu de sota, i ping -c 3 -I br0 203.0.113.10 ha de respondre si el servidor permet ICMP. Si els dos primers passos del client passen i el tercer falla, la fallada és al reenviament o al NAT. Si el segon pas falla, el pont o el DHCP encara són incomplets.

La reversió és una edició de fitxer i dues ordres: traieu l'estrofa, reinicieu dhcpcd i substituïu la ruta per defecte explícitament amb ip route replace default via 192.168.50.1 dev br0. Feu-ho abans que es tanqui la finestra de manteniment i no després, perquè un Pi que ha perdut la ruta per defecte és inabastable des de la xarxa que faríeu servir per reparar-lo.