Els clients del punt d'accés del Pi no arriben a la LAN de casa per una VPN TUN

Els clients Wi-Fi i Ethernet locals es connecten al punt d'accés del Pi, obtenen una adreça del seu àmbit DHCP i carreguen pàgines d'internet sense queixes. Aquests mateixos clients després es queden sense resposta quan obren un recurs compartit de fitxers o una interfície web a la LAN de casa, mentre que el Pi mateix arriba a aquesta LAN pel túnel. No hi ha res trencat a la capa sense fils. El que falta és un contracte enrutat: el prefix del punt d'accés s'ha de portar a la interfície TUN, i alguna cosa a la banda de casa ha de saber com enviar-hi les respostes. Les dues meitats han d'existir abans que un sol paquet pugui completar el viatge d'anada i tornada.

Tres connexions amb tres feines diferents

Un pont Ethernet de Linux reenvia trames per adreça MAC de destinació. OpenVPN en mode TUN transporta paquets IP i no té cap capa MAC, així que afegir un pont local mai inscriu el túnel com a port. La documentació del nucli TUN/TAP explica aquesta separació: un dispositiu TAP sembla una interfície Ethernet, un dispositiu TUN no. Un disseny que fa pont entre dos ports locals i després enruta és un encaminador, diguin el que diguin els noms de les interfícies.

Aquesta distinció decideix la propietat. La subxarxa dels clients, la seva porta d'enllaç per defecte i l'autoritat DHCP d'aquell àmbit pertanyen al pla local del Pi. Les emissions DHCP de casa no travessen un túnel enrutat, i cap ajust del pont ho canvia; apuntar els clients a un servidor DHCP de casa és un disseny de relé separat i deliberat, amb els seus propis modes de fallada.

Mantingueu el mòdem també fora del pont de clients. Una connexió PPP no és un dispositiu Ethernet amb una etiqueta diferent, i la lògica de ruta per defecte documentada de pppd s'executa després de la negociació IPCP i retira la seva ruta quan aquest enllaç cau. Copiar una plantilla DHCP i reanomenar cada usb0 a ppp0 no demostra res sobre porta d'enllaç, mètrica o cicle de vida.

Trieu els prefixos abans d'editar qualsevol configuració

Els prefixos superposats fan perdre més vespres que les regles del tallafoc, perquè una superposició envia la cerca de ruta a la interfície equivocada fins i tot quan el túnel és saludable. Comenceu llistant el que ja existeix al Pi i després llegiu el resultat com a quatre pools separats.

ip -4 addr show scope global
ip -4 route show table main
ip -4 route get 192.168.77.10

El primer pool és l'adreça underlay que l'operador va donar al mòdem; ha de quedar fora de tot pla orientat als clients. El segon és la subxarxa del túnel que va triar el servidor, sovint una /24 privada pròpia. El tercer és el pont del punt d'accés, i el quart és el prefix de casa que voleu assolir. En aquest recorregut el punt d'accés obté 172.28.90.0/24 amb el pont a 172.28.90.1, i la LAN de serveis de casa manté 192.168.77.0/24, cosa que evita les adreces per defecte 192.168.1.0/24 i 10.0.0.0/24 que porten els encaminadors de consum i el rang d'operador 100.64.0.0/10.

Anuncieu l'adreça del pont com a porta d'enllaç a l'àmbit DHCP del punt d'accés i res més. No doneu mai als clients del punt d'accés una adreça de casa com a porta d'enllaç; no tenen cap camí a nivell d'enllaç cap a aquell segment.

Encamineu cada direcció al costat que la posseeix

El Pi necessita una ruta per al prefix de casa a través del túnel. Els servidors en mode servidor normalment empenyen aquesta ruta, així que primer confirmeu que el reenviament està activat i que el nucli resol una adreça de casa des de tun0.

sysctl net.ipv4.ip_forward
ip route add 192.168.77.0/24 dev tun0
ip -4 route get 192.168.77.10

Si ip route get encara informa de la interfície underlay, atureu-vos aquí; res més endavant del camí no pot reparar una cerca equivocada.

Els dispositius de casa no tenen ruta cap a 172.28.90.0/24, així que les seves respostes segueixen la porta d'enllaç per defecte i moren a l'encaminador. Hi ha dues reparacions suportades. O afegiu una ruta estàtica a l'encaminador de casa que apunti el prefix del punt d'accés a l'adreça LAN del servidor VPN, o, quan el servidor és ell mateix la porta d'enllaç, registreu el prefix del client a la taula d'encaminament del servidor. En el mode multiclient d'OpenVPN el directori específic del client porta aquesta associació: un fitxer amb el nom comú del certificat del client, que conté iroute 172.28.90.0 255.255.255.0 més la línia route corresponent que la instal·la al nucli del servidor. Una ruta de nucli suposada al servidor no és la mateixa declaració que dir al servidor quin client posseeix el prefix.

No moveu el servei DHCP de la xarxa de casa al servidor VPN per fer-ho funcionar. Substituir la porta d'enllaç per defecte de tota una casa és un canvi molt més gran que afegir una ruta de retorn privada, i arrossega DNS, reserves d'adreces i cada dispositiu que ignora el nou lloguer cap a la fallada.

Obriu el reenviament sense endevinar el tallafoc

Que el reenviament estigui activat no vol dir que el paquet pugui passar. El trànsit del pont cap al túnel encara topa amb les regles de filtratge, i una política de reenviament per defecte drop descarta el trànsit del punt d'accés mentre el trànsit propi del Pi continua funcionant, cosa que produeix exactament el símptoma dividit de dalt.

iptables -S FORWARD
iptables -t nat -S POSTROUTING
nft list ruleset

Busqueu una regla d'acceptació de br0 a tun0 i la direcció de resposta corresponent, i una regla postrouting que pugui reescriure l'origen. Si la política de la cadena és drop i cap regla coincideix, afegiu les acceptacions estretes i torneu a provar en lloc de girar la política a accept.

La traducció és una elecció de política, no un requisit. El NAT d'origen cap a la LAN de casa fa que cada client del punt d'accés sembli l'adreça del túnel del Pi, cosa que perd l'atribució per client als registres de casa i trenca serveis que esperen l'origen original. L'encaminament sense NAT manté visibles les adreces dels clients però depèn de la ruta de retorn de dalt. Trieu-ne un i tracteu DNS i IPv6 de la mateixa manera, perquè un camí IPv4 que funciona al costat d'un camí IPv6 trencat encara es llegeix com a mig trencat al navegador.

Verifiqueu el viatge d'anada i tornada i després trenqueu-lo a propòsit

Proveu des d'un client del punt d'accés, mai des del Pi, perquè el trànsit propi del Pi evita tant el camí d'anada com el de retorn. Observeu les dues interfícies mentre un client intenta arribar a un servei de casa.

tcpdump -ni br0 host 192.168.77.10
tcpdump -ni tun0 host 192.168.77.10
ping -c 3 192.168.77.10

Llegiu les dues captures juntes. Les peticions a br0 que mai apareixen a tun0 volen dir que el Pi no reenvia o que la ruta apunta a un altre lloc. Les peticions a tun0 sense respostes volen dir que la banda de casa no té ruta de retorn o que el servidor ha filtrat el paquet. Les respostes a tun0 que no reapareixen mai a br0 volen dir que falta la regla de filtratge inversa, on el túnel sembla perfecte i el client encara no veu res.

Després trenqueu el camí deliberadament. Baixeu la connexió del mòdem i torneu-la a pujar i torneu a executar les comprovacions de ruta i de captura; una ruta que sobreviu al túnel però desapareix en reconnectar pertany al perfil de connexió, no a una ordre puntual. Confirmeu que el transport del túnel encara surt per l'underlay i no per si mateix, el bucle clàssic quan s'accepta una ruta per defecte empenyuda sense una ruta d'amfitrió cap al parell.

Accepteu el disseny només quan un client del punt d'accés pugui resoldre un nom de casa, obrir un servei TCP i mantenir una sessió viva durant una reconnexió del mòdem. Si una aplicació requereix de debò descobriment a nivell Ethernet al segment de casa, trieu un disseny Layer 2 suportat en lloc de descriure el pont local com a pontat i esperar que aparegui la difusió.