Adapte el cliente VPN de Linux al protocolo del dispositivo antiguo

Cuatro familias de protocolos cubren casi cualquier dispositivo que siga en un rack, y cada una falla de forma distinta en Linux. Los puertos publicados y las propuestas configuradas del extremo remoto deciden su paquete, no la distribución que ejecute por casualidad. Instalar lo que menciona un mensaje de foro y luego editar hasta que algo conecte es como se pierde una tarde. Lea el dispositivo, instale segundo, verifique tercero.

Anote lo que publica el extremo remoto

Anote el protocolo, los puertos y la autenticación que espera el dispositivo antes de abrir un gestor de paquetes. Cuatro familias cubren la mayor parte del equipo viejo, y la tabla de abajo es toda la decisión en una pantalla.

El manual y las reglas de cortafuegos del propio dispositivo son más fiables que el nombre del protocolo en su página de inicio de sesión. Un dispositivo que anuncia IPsec puede que solo hable IKEv1, y una versión de firmware que nadie aplicó puede ser la que finalmente añada IKEv2. Confirme la ruta de datos y también el puerto de configuración, porque es ahí donde el equipo viejo y las redes modernas discrepan. Equivocarse en este paso significa depurar el cliente contra una función que el otro extremo nunca tuvo.

PPTP: demuestre GRE antes de editar pppd

PPTP en Linux no es un demonio que se inicia, sino una invocación de pppd, y los parámetros de conexión viven en un archivo peer con nombre que pppd lee cuando se le llama. Las distribuciones todavía lo empaquetan, aunque las debilidades conocidas del protocolo lo hacen inadecuado para cualquier cosa sensible, así que resérvelo estrictamente para un dispositivo que no ofrezca nada más. Vigile GRE mientras el cliente negocia, con una captura breve en lugar de una suposición. El fallo que más tiempo consume no es la autenticación, sino la ruta de datos ausente.

pppd call branch-office
tcpdump -ni any proto gre -c 5

Si la configuración termina y el enlace nunca transporta tráfico, sospeche de la ruta GRE antes de tocar las credenciales. Los grupos de seguridad de la nube necesitan una regla explícita para el protocolo 47, y algunas redes lo bloquean por completo sin un error visible. Pruebe desde la red que realmente usará, no desde un laboratorio que lo permite todo.

L2TP/IPsec: una propuesta acertada vence a diez intentos

Lea el registro del demonio en lugar del diálogo del escritorio, porque el diálogo funde varios fallos distintos en un solo mensaje. Un error NO_PROPOSAL_CHOSEN pertenece a la primera fase: el cliente ofreció un cifrado, un hash o un grupo Diffie-Hellman que el servidor no aceptará. Enumere lo que admite el dispositivo y escriba una propuesta que encaje, porque las combinaciones al azar suelen producir el mismo error más despacio. En un escritorio, el cliente práctico es el complemento L2TP de NetworkManager con strongSwan o Libreswan debajo.

Una cadena de propuesta que para un complemento de escritorio significa una cosa puede significar otra para el demonio al que entrega el trabajo, así que mantenga la sintaxis adecuada a la capa que edita. Si el dispositivo exige además un secreto de túnel, es una etapa separada de la clave IPsec. Confirme cuál de las dos pide la interfaz antes de escribir nada en ella.

IKEv1 agresivo con XAuth, y el caso del portal

Un extremo estilo FortiGate normalmente quiere modo agresivo con XAuth y una dirección en modo configurado, algo que un complemento gráfico puede no exponer en absoluto. El demonio nativo se encarga de ello, y el bloque de abajo es la forma de esa configuración, no un archivo completo. Consulte la documentación actual del fabricante para los valores de la propuesta.

conn branch
    keyexchange=ikev1
    aggressive=yes
    leftauth=psk
    leftauth2=xauth
    leftsourceip=%config
    right=203.0.113.10

Las versiones antiguas de strongSwan usaban xauth=client donde la versión 5 usa leftauth2=xauth, así que un fragmento copiado puede fallar solo por la sintaxis. Para un portal TLS, openconnect, que habla el protocolo AnyConnect, se encarga de Cisco y de la mayoría de las marcas renombradas, y necesita un dispositivo TUN y los privilegios para configurarlo. Pase la dirección del portal exactamente como la muestra el navegador, incluida cualquier ruta que el dispositivo espere, y luego compruebe la dirección asignada antes de probar nada detrás. Crear la interfaz de antemano elimina una clase de sorpresas durante la configuración.

sudo ip tuntap add dev tun0 mode tun
sudo openconnect --protocol=anyconnect vpn.example.com

Conecte, luego verifique en un orden fijo

Ejecute exactamente un gestor de VPN a la vez, porque un perfil de NetworkManager y un demonio iniciado a mano se pelearán por las rutas y el DNS. Baje el perfil antes de probar una conexión manual, y confirme que no sobrevive ninguna interfaz de túnel antigua. Luego verifique en este orden: dirección del túnel, ruta al único host interno que necesita, resolución de nombres y, por último, una petición real. Un icono verde demuestra la autenticación y nada más.

ip -4 addr show tun0
ip route get 10.20.30.10
getent hosts app.internal

Si un paso falla, deténgase ahí en lugar de probar el siguiente, porque un fallo de DNS aguas abajo de una ruta rota no le enseña nada. Guarde una copia del perfil que funciona antes de experimentar, porque un archivo de conexión borrado se pierde fácil y cuesta reconstruirlo. Conserve los valores de la propuesta en la misma nota que el modelo del dispositivo y la versión de firmware, porque esa nota es la diferencia entre una migración y un proyecto de arqueología cuando se sustituya la caja.