Punto de acceso VPN puenteado: ¿qué ruta predeterminada usa el teléfono?

El teléfono de su punto de acceso puenteado obtiene su dirección y su puerta de enlace de algún sitio, y esa no es la ruta predeterminada del Pi. Cambiar la ruta predeterminada del Pi cambia adónde envía el Pi su propio tráfico. El teléfono sigue usando la puerta de enlace que le indicaron, y cuando esa puerta está en la LAN remota, sus tramas simplemente cruzan el puente. Dos consumidores, dos decisiones. Separarlas explica la mayoría de los informes de un punto de acceso sin internet mientras el Pi está bien.

Dos dispositivos, dos decisiones de puerta de enlace distintas

El Pi tiene su propia pila IP y su propia ruta predeterminada. El teléfono tiene su propia pila IP y su propia ruta predeterminada.

Esa tabla es todo el modelo. La puerta de enlace del teléfono es una dirección en la LAN remota, y sus tramas se reenvían en la capa 2 hacia ese enrutador. La ruta predeterminada del Pi concierne a su propio transporte exterior, que debe alcanzar al par VPN por el enlace ascendente de viaje.

Un puente reenvía tramas, no enruta paquetes

Un puente de Linux reenvía tramas Ethernet por MAC de destino, y eso es todo lo que hace entre sus puertos. La trama del teléfono dirigida a la MAC del enrutador remoto se conmuta al puerto TAP y cruza el túnel sin tocar la tabla de enrutamiento del Pi. Por eso una ruta predeterminada rota del Pi puede dejar el teléfono funcionando, y por eso una correcta no puede arreglar un teléfono al que le dieron la puerta de enlace equivocada.

TAP transporta tramas Ethernet y puede ser un puerto de puente. TUN transporta paquetes IP y no puede. Si su diseño sustituyó uno por otro, el puente no es un puente y el resto de esto no se aplica.

Decida quién reparte la concesión del teléfono

La opción 3 de DHCP es la opción de enrutador, y dice al cliente qué puerta de enlace usar para su subred. Cuando el servidor DHCP de la LAN remota es el único asignador, el teléfono obtiene una puerta remota y el diseño es coherente. Cuando algo más en el lado del viaje responde primero, el teléfono obtiene una puerta local, su tráfico de internet sale por el enlace ascendente de viaje y su tráfico hacia la LAN remota no tiene ningún camino.

Ejecute un solo asignador para ese dominio de difusión, y anote qué reparte.

El Pi es un caso aparte incluso cuando toma una dirección de la misma concesión. Decida deliberadamente si debe instalar las rutas que ofrece la concesión, porque una ruta predeterminada remota importada puede arrastrar el transporte VPN propio del Pi al túnel que intenta mantener vivo. Con systemd-networkd esa decisión es UseRoutes= en la sección DHCP; con dhclient es la opción routers en la lista de peticiones.

Mantenga el enlace ascendente fuera de la LAN puenteada

La interfaz que transporta la conexión VPN exterior del Pi no debe convertirse en puerto de puente. Si lo hace, el transporte cifrado se conmuta a la LAN extendida y el túnel acaba transportando sus propios paquetes exteriores, lo que falla de una forma que parece pérdida de paquetes más que un bucle. Mantenga también explícitas la capacidad de AP y el soporte de puente. Una interfaz inalámbrica en modo estación normalmente no puede ser puerto de puente, porque la cabecera 802.11 no tiene sitio para la segunda dirección MAC que necesita un puente.

Defina el dominio de difusión extendido, un plan de direcciones y el filtrado de tramas que realmente quiere. Permitir el escucha VPN en el Pi no concede a cada cliente puenteado acceso a los servicios de gestión del Pi. Son reglas separadas, y tratarlas como una sola es cómo un punto de acceso se convierte silenciosamente en una puerta abierta.

Pruebe las cuatro cosas por separado cuando falla

Cuando el teléfono no puede alcanzar la LAN remota, cuatro observaciones separan las causas. Ejecútelas en este orden y deténgase en la primera que falle.

ip route show default
bridge link show
ip -4 neigh show dev br0
tcpdump -ni br0 arp or icmp

Empiece por la concesión: ¿tiene el teléfono una dirección y una puerta de enlace en la subred remota? Luego mire el puente y confirme que el puerto AP y el puerto TAP reenvían ambos. Luego lea la tabla de vecinos, porque una entrada sin resolver para el enrutador remoto significa que las tramas salen y nada responde. Por último observe las tramas en el puente mientras el teléfono hace ping, lo que le dice si la avería está por debajo de IP o no.

Anote qué dispositivo posee cada ruta predeterminada cuando termine. Una línea de documentación convierte la salida local frente a la remota en una decisión consciente del cliente, y la referencia del puente merece quedarse al lado.