Punto de acceso VPN ponteado: que ruta predeterminada usa o teléfono?

O teléfono do seu punto de acceso ponteado obtén o seu enderezo e a súa porta de enlace de algún sitio, e esa non é a ruta predeterminada do Pi. Cambiar a ruta predeterminada do Pi cambia a onde o Pi envía o seu propio tráfico. O teléfono segue usando a porta de enlace que lle indicaron, e cando esa porta está na LAN remota, as súas tramas simplemente cruzan a ponte. Dous consumidores, dúas decisións. Separaas explica a maioría dos informes dun punto de acceso sen internet mentres o Pi está ben.

Dous dispositivos, dúas decisións de porta de enlace distintas

O Pi ten a súa propia pila IP e a súa propia ruta predeterminada. O teléfono ten a súa propia pila IP e a súa propia ruta predeterminada.

Esa táboa é todo o modelo. A porta de enlace do teléfono é un enderezo na LAN remota, e as súas tramas reenvíanse na capa 2 cara a ese encamiñador. A ruta predeterminada do Pi refírese ao seu propio transporte exterior, que debe acadar o par VPN polo enlace ascendente de viaxe.

Unha ponte reenvía tramas, non encamiña paquetes

Unha ponte de Linux reenvía tramas Ethernet pola MAC de destino, e iso é todo o que fai entre os seus portos. A trama do teléfono dirixida á MAC do encamiñador remoto conmútase ao porto TAP e cruza o túnel sen tocar a táboa de encamiñamento do Pi. Por iso unha ruta predeterminada rota do Pi pode deixar o teléfono funcionando, e por iso unha correcta non pode arranxar un teléfono ao que lle deron a porta de enlace equivocada.

TAP transporta tramas Ethernet e pode ser un porto de ponte. TUN transporta paquetes IP e non pode. Se o seu deseño substituíu un polo outro, a ponte non é unha ponte e o resto disto non se aplica.

Decida quen reparte a concesión do teléfono

A opción 3 de DHCP é a opción de encamiñador, e di ao cliente que porta de enlace usar para a súa subrede. Cando o servidor DHCP da LAN remota é o único asignador, o teléfono obtén unha porta remota e o deseño é coherente. Cando outra cousa no lado da viaxe responde primeiro, o teléfono obtén unha porta local, o seu tráfico de internet sae polo enlace ascendente de viaxe e o seu tráfico cara á LAN remota non ten ningún camiño.

Executa un só asignador para ese dominio de difusión, e anota que reparte.

O Pi é un caso aparte mesmo cando toma un enderezo da mesma concesión. Decida deliberadamente se debe instalar as rutas que ofrece a concesión, porque unha ruta predeterminada remota importada pode arrastrar o transporte VPN propio do Pi dentro do túnel que intenta manter vivo. Con systemd-networkd esa decisión é UseRoutes= na sección DHCP; con dhclient é a opción routers na lista de peticións.

Manteña o enlace ascendente fóra da LAN ponteada

A interface que transporta a conexión VPN exterior do Pi non debe converterse en porto de ponte. Se o fai, o transporte cifrado conmútase á LAN estendida e o túnel acaba transportando os seus propios paquetes exteriores, o que falla dun xeito que parece perda de paquetes máis que un bucle. Manteña tamén explícitas a capacidade de AP e o soporte de ponte. Unha interface sen fíos en modo estación normalmente non pode ser porto de ponte, porque a cabeceira 802.11 non ten sitio para o segundo enderezo MAC que necesita unha ponte.

Defina o dominio de difusión estendido, un plan de enderezos e o filtrado de tramas que realmente quere. Permitir o oínte VPN no Pi non concede a cada cliente ponteado acceso aos servizos de xestión do Pi. Son regras separadas, e tratalas como unha soa é como un punto de acceso se converte silenciosamente nunha porta aberta.

Probe as catro cousas por separado cando falla

Cando o teléfono non pode acadar a LAN remota, catro observacións separan as causas. Execúteas nesta orde e detéñase na primeira que falle.

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

Comece pola concesión: ten o teléfono un enderezo e unha porta de enlace na subrede remota? Despois mire a ponte e confirme que o porto AP e o porto TAP ambos reenvían. Despois lea a táboa de veciños, porque unha entrada non resolvida para o encamiñador remoto significa que as tramas saen e nada responde. Por último observe as tramas na ponte mentres o teléfono fai ping, o que lle di se a avaría está por baixo de IP ou non.

Anote que dispositivo posúe cada ruta predeterminada cando remate. Unha liña de documentación converte a saída local fronte á remota nunha decisión consciente do cliente, e a referencia da ponte merece quedar ao lado.