Faga que o reenvío IPv4 persista tras reiniciar unha pasarela VPN

Facer ping á pasarela funciona e chegar a calquera cousa detrás dela non, e esa é a forma dun problema de reenvío e non dun problema de túnel. A entrega local á pasarela demostra que o túnel se levantou e que a asignación de enderezos funcionou; non di nada sobre se o núcleo deixará pasar un paquete dunha interface a outra. Antes de tocar calquera sysctl, confirme que a máquina debe encamiñar este tráfico e localice o contexto de rede que contén a interface orientada ao cliente. Despois lea o valor alí, non onde casualmente mirou a última guía que leu.

Chegar á pasarela non é o mesmo que reenviar

Dentro do núcleo ocorren dúas decisións separadas. A entrega a un enderezo local remata a viaxe do paquete; o reenvío volve envialo por outra interface, e esa segunda decisión gobiérnase por espazo de nomes de rede. Unha pasarela pode ser perfectamente accesible mentres o reenvío está desactivado, e desde un indicador de ping os dous fallos parecen idénticos.

Anote por que interface chega o paquete do cliente e por que interface sae o camiño seguinte. Ambas pertencen a un só espazo de nomes, e ese espazo de nomes contén o axuste que importa.

Lea o valor onde os paquetes están realmente

Nunha pasarela que encamiña no espazo de nomes do host, un só comando responde a pregunta: sysctl net.ipv4.ip_forward. Cando o camiño de entrada e o seguinte viven nun espazo de nomes con nome, pregúntelle a ese espazo de nomes: ip netns exec vpn-gw sysctl net.ipv4.ip_forward. O valor do host non substitúe o valor do espazo de nomes, e un un no host non é proba de nada.

Non todos os contextos de encamiñamento teñen unha etiqueta que poida pasar a ip netns. Os contornos de execución de contedores e os servizos crean espazos de nomes que nunca se rexistran cun nome amigable, e para eses use as ferramentas de inspección do contorno. Substitúa vpn-gw polo nome real, ou polo mecanismo do contorno que chega ao mesmo contexto, e deixe de adiviñar no nivel do host.

Dea ao axuste un único propietario

Nunha pasarela anfitrioa convencional con systemd, a forma duradeira é un ficheiro drop-in cun nome elixido polo administrador, como /etc/sysctl.d/60-vpn-forwarding.conf, que conteña net.ipv4.ip_forward = 1. Escriba o ficheiro e despois cargue ese ficheiro concreto para que o estado vivo tamén cambie: sudo sysctl -p /etc/sysctl.d/60-vpn-forwarding.conf, seguido dunha lectura de retorno. O nome do ficheiro é un exemplo e non un camiño VPN reservado, e o número inicial importa porque os ficheiros ordenados máis tarde gañan.

A precedencia é onde a persistencia rompe en silencio. Revise tanto o cargador da distribución como o seu propio drop-in, porque procps sysctl --system tamén le /etc/sysctl.conf ao final, mentres que a orde sysctl.d de systemd é unha secuencia completamente distinta. Unha asignación posterior pode devolver a mesma clave de inmediato, deixando o seu ficheiro correcto e o valor efectivo incorrecto. Non sobrescriba un ficheiro de administrador existente para gañar esa discusión; atope o propietario e cambie alí.

Un espazo de nomes creado despois do arranque non se rexe en absoluto por un drop-in do host. O seu axuste pertence a quen o crea, xa sexa o contorno de execución de contedores ou a unidade de aprovisionamento do espazo de nomes. Conceder a un contedor amplos privilexios de host para evitar a pregunta é un mal negocio comparado con dedicar dez minutos a identificar o propietario correcto.

Saiba canto custa o interruptor antes de accionalo

ip_forward non é un booleano inofensivo. A documentación do núcleo sinala que cambialo restablece varios outros parámetros IPv4 aos seus valores predeterminados de host ou de encamiñador, así que un cambio de diagnóstico pode descartar axustes feitos noutro lugar e non mencionalo nunca. Tráteo como un cambio de configuración con efectos secundarios e non como unha sonda que se poida executar sen coidado.

Iso tamén descarta activalo e desactivalo cada vez que un cliente non pode chegar a un host. Se o valor xa é un, a falla está noutro punto do camiño, e reescribir a mesma clave por terceira vez non o moverá.

Demostre a persistencia e logo probe o resto do camiño

Lea o valor de volta en catro momentos: xusto despois do cambio, despois de que apareza a interface VPN, despois dunha reconexión e despois dun reinicio planificado. Un valor que reverte en calquera deses puntos ten un segundo propietario, e outra escritura puntual só o agocha ata o próximo reinicio.

O reenvío activado aínda deixa tres cousas por verificar. O cliente necesita unha ruta ata o destino, a pasarela necesita unha ruta seguinte máis permiso para usala, e o destino necesita un camiño de retorno cara ao enderezo do túnel do cliente. Unha LAN privada encamiñada non necesita NAT automaticamente, así que non engada masquerading antes de saber cal das tres falta, e probe desde o cliente previsto e non desde a propia pasarela, porque unha petición orixinada na pasarela nunca toca o camiño de reenvío que acaba de activar. IPv6 ten a súa propia política de reenvío e encamiñamento, así que unha proba IPv4 que funcione non di nada sobre ela.

Manteña xuntos no runbook o camiño do drop-in, o propietario do espazo de nomes e o comando de lectura de retorno. Quen o colla despois debería poder ler o valor, ver quen o posúe e decidir nun minuto se o problema é a persistencia ou o resto do camiño.