Un par VPN fai ping a outras interfaces porque son locais

Un cliente de WireGuard conéctase e fai ping a un enderezo nunha interface completamente distinta, e a resposta chega. As capturas mostran a petición só no túnel. Nada está roto, e o axuste de reenvío que se desactivou con coidado non ten nada que ver. Esta é unha comparación entre dúas rutas que parecen iguais nun diagrama e son completamente distintas no kernel.

Unha ruta reenvía paquetes por outro; a outra entrégaos ao propio host.

Un paquete dirixido ao host queda no host

O cliente remoto envía un paquete IP a un enderezo que posúe o host. O encamiñamento fai unha pregunta sobre ese paquete: este destino é local? Cada enderezo que ten o host aparece na táboa de encamiñamento local, e esa táboa consultase antes ca principal, así que o paquete vai á pila propia do host en vez de saír por outra interface. A resposta xérase localmente, e volve polo túnel porque de alí veu a consulta.

Ese é todo o mecanismo. Non se produce ningún reenvío, non intervén ningún cambio de estado da interface, e o enderezo en cuestión non precisa ser alcanzable desde ningún outro sitio.

Por que ip_forward non se aplica

O reenvío goberna os paquetes que deben saír por unha interface distinta daquela pola que chegaron. Un ping ao propio host nunca toma esa ruta: o paquete consómese localmente e a resposta xérase localmente. Por iso, establecer net.ipv4.ip_forward=0 non cambia nada aquí, e unha regra na cadea de reenvío nunca ve ese tráfico. O control correcto está na ruta de entrada, limitado pola interface entrante ou a fonte.

Por iso, desactivar o reenvío e supor que o host está illado produce unha falsa sensación de seguridade.

Lea a táboa local que decidiu

ip rule show normalmente informa dunha regra con prioridade cero que envía todas as consultas primeiro á táboa local, e ip route show table local enumera os enderezos propios do host con ámbito local. Esa táboa inclúe enderezos en interfaces administrativamente baixadas pero aínda configuradas. Os enderezos IPv4 asignados estaticamente adoitan sobrevivir a unha caída da ligazón, e así é como un ping a unha ponte baixada pode aínda ter éxito e sorprender o operador.

IPv6 discrepa exactamente neste punto. Os seus enderezos normalmente retíranse cando cae a ligazón, agás que keep_addr_on_down estea establecido. Compare as familias en lugar de supor que unha regra cobre ambas.

A que chega realmente un par

Unha resposta desde o enderezo propio do router nun segmento non di nada sobre as máquinas detrás dese segmento. O par non pode chegar a un host detrás da outra interface por esta ruta; só chega aos enderezos que o propio router posúe. Probar un servizo nun host LAN separado, en lugar de facer ping ao enderezo do router, é o que establece se o reenvío está permitido de feito.

Restrinxir un par aos servizos ligados ao enderezo do túnel é unha cuestión de política de entrada. Permita o servizo desexado na interface do túnel e restrinxa as fontes que o poden usar, porque o paquete chega de verdade alí.

Revise tamén os enderezos que pensaba retirar. Quitar un enderezo dunha interface é máis fiable que apillar regras de cortalumes sobre un enderezo obsoleto.