Salto seguinte nunha ruta VPN: por que a pasarela debe ser accesible localmente

Unha ruta cara a unha rede VPN leva dous enderezos fáciles de confundir: o prefixo de destino que o paquete intenta alcanzar e o salto seguinte que o moverá un paso máis preto. Nun equipo LAN, ese salto seguinte ten que ser un encamiñador ao que realmente poidades chegar na mesma ligazón. O enderezo VPN remoto non é un salto seguinte, por moi ben que encaixe co destino que tedes na cabeza.

Este manual cobre o caso habitual: un portátil en 192.168.20.0/24, unha pasarela VPN cun enderezo LAN de 192.168.20.5 e unha rede remota 10.70.0.0/24 detrás desa pasarela. Todos os comandos seguintes supoñen que estades no portátil, agás que se indique o contrario.

Dous enderezos, unha ruta

A entrada prevista é 10.70.0.0/24 via 192.168.20.5. O prefixo di a onde vai o paquete; o enderezo via di quen o leva alí. O núcleo négase a instalar unha ruta cuxa pasarela non pode alcanzar pola interface que nomeades, e esa negativa é todo o punto: un salto seguinte que necesita o túnel para ser accesible non pode ser o salto seguinte que constrúe o túnel.

Así que a primeira comprobación non é «funciona a pasarela» senón «está a pasarela nesta ligazón». A subrede propia do portátil, a súa entrada ARP ou de veciño e a interface da ruta teñen que coincidir. Un enderezo que só existe dentro de 10.70.0.0/24 pode ser o destino dunha segunda ruta, nunca o via da primeira.

A que obriga o salto seguinte á pasarela

Instalar a ruta no portátil só decide a primeira entrega. Despois a pasarela necesita o seu propio camiño: reenvío activado, unha ruta de túnel para 10.70.0.0/24 e calquera política de acceso que determine quen pode usala. En Linux iso é net.ipv4.ip_forward=1 máis unha ruta de túnel; un cortalumes diante necesita unha regra que permita o fluxo reenviado.

A dirección de volta é a parte que a xente esquece. O lado remoto debe ter unha ruta de volta a 192.168.20.0/24, ou o deseño debe traducir a orixe do portátil a algo que o lado remoto coñeza. Un ping que funciona desde a pasarela demostra que a pasarela pode alcanzar a rede remota; non di nada sobre se os paquetes do portátil sobreviven á viaxe de volta.

Verificade a busca desde o equipo que envía

Preguntádelle ao núcleo que salto seguinte escollería e lede a interface na resposta:

ip route get 10.70.0.10
ip route show 10.70.0.0/24
ip neigh show 192.168.20.5

Se a busca informa da pasarela e da interface LAN, o primeiro treito está configurado como se pretendía. Se informa do dispositivo de túnel, algo anterior na táboa é máis específico e gaña. Se a ruta non se instala en absoluto, o núcleo diche que a pasarela non é accesible, e esa mensaxe é máis útil que calquera captura de paquetes.

Despois repetide a proba desde o lugar correcto. Unha petición creada na pasarela usa o enderezo de orixe propio da pasarela, o que pode ocultar unha ruta de volta ausente ou unha política que só permite certas orixes. O manual de ip-route separa o destino, a pasarela e a anulación onlink, e paga a pena entender a anulación antes de usala.

Non empreguedes onlink para finxir accesibilidade

onlink dille ao núcleo que se salte a comprobación de accesibilidade dunha pasarela e lle envíe de todos os xeitos. Non crea un camiño, non resolve ARP para un enderezo que non está nin fai que un encamiñador remoto responda no voso segmento Ethernet. É lexítimo para pasarelas que responden pero non están nunha subrede conectada, e é unha trampa cando se usa para silenciar un erro que non explicastes.

Se a ruta só se instala con onlink, a pregunta seguinte é por que a pasarela non está onde pensades. Unha VLAN incorrecta, un segundo enderezo na interface incorrecta ou un erro de mecanografía no último octeto producen isto, e cada un deles tamén rompe o camiño de volta en canto o tráfico comeza a fluír.

Os túneles punto a punto non son Ethernet

Un dispositivo de túnel non fai ARP e a miúdo non ten unha subrede de veciños con sentido. As súas rutas adoitan parecerse a 10.70.0.0/24 dev tun0, sen ningún via, porque o par é o único outro extremo. Copiar un via ao estilo LAN nesa táboa produce unha ruta que o núcleo pode rexeitar ou, peor, unha que apunta a un enderezo ao que o par nunca responde.

Mantede os dous modelos separados no manual: unha ruta LAN ten unha pasarela accesible, unha ruta de túnel ten unha interface e un par. WireGuard, OpenVPN e IPsec expoñen formas lixeiramente distintas, así que anotade a forma que realmente usastes en lugar de xeneralizar desde un só equipo.

Engadide, confirmade, revertide

Todo o cambio son tres comandos e unha comprobación, e debería escribirse nesa orde:

sudo ip route add 10.70.0.0/24 via 192.168.20.5
ip route get 10.70.0.10
ping -c 3 10.70.0.10
sudo ip route del 10.70.0.0/24 via 192.168.20.5

Confirmade o camiño, confirmade un destino e despois tede á man a liña de borrado por se o cambio deixa o equipo inaccesible dunha forma que non previstes. Se a ruta debe sobrevivir a un reinicio, póndea na configuración de rede do equipo e non nun perfil da shell, e probade o reinicio antes de confiar nela. Unha ruta que só existe na shell que a engadiu é unha ruta que depuraredes dúas veces.