Adapte o cliente VPN de Linux ao protocolo do dispositivo antigo

Catro familias de protocolos cobren case calquera dispositivo que siga nun rack, e cada unha falla de forma distinta en Linux. Os portos publicados e as propostas configuradas do extremo remoto deciden o seu paquete, non a distribución que execute por casualidade. Instalar o que menciona unha mensaxe de foro e logo editar ata que algo conecte é como se perde unha tarde. Lea o dispositivo, instale segundo, verifique terceiro.

Anote o que publica o extremo remoto

Anote o protocolo, os portos e a autenticación que espera o dispositivo antes de abrir un xestor de paquetes. Catro familias cobren a maior parte do equipo vello, e a táboa de abaixo é toda a decisión nunha pantalla.

O manual e as regras de devasado do propio dispositivo son máis fiables que o nome do protocolo na súa páxina de inicio de sesión. Un dispositivo que anuncia IPsec pode que só fale IKEv1, e unha versión de firmware que ninguén aplicou pode ser a que finalmente engada IKEv2. Confirme a ruta de datos e tamén o porto de configuración, porque é aí onde o equipo vello e as redes modernas discrepan. Equivocarse neste paso significa depurar o cliente contra unha función que o outro extremo nunca tivo.

PPTP: demostre GRE antes de editar pppd

PPTP en Linux non é un demo que se inicia, senón unha invocación de pppd, e os parámetros de conexión viven nun ficheiro peer con nome que pppd le cando se lle chama. As distribucións aínda o empaquetan, aínda que as debilidades coñecidas do protocolo fano inadecuado para calquera cousa sensible, así que resérveo estritamente para un dispositivo que non ofreza nada máis. Vixíe GRE mentres o cliente negocia, cunha captura breve en lugar dunha suposición. O fallo que máis tempo consume non é a autenticación, senón a ruta de datos ausente.

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

Se a configuración remata e a ligazón nunca transporta tráfico, sospeite da ruta GRE antes de tocar as credenciais. Os grupos de seguridade da nube necesitan unha regra explícita para o protocolo 47, e algunhas redes bloquéano por completo sen un erro visible. Probe desde a rede que realmente usará, non desde un laboratorio que o permite todo.

L2TP/IPsec: unha proposta acertada vence a dez intentos

Lea o rexistro do demo en lugar do diálogo do escritorio, porque o diálogo funde varios fallos distintos nunha soa mensaxe. Un erro NO_PROPOSAL_CHOSEN pertence á primeira fase: o cliente ofreceu un cifrado, un hash ou un grupo Diffie-Hellman que o servidor non aceptará. Enumere o que admite o dispositivo e escriba unha proposta que encaixe, porque as combinacións ao azar adoitan producir o mesmo erro máis amodo. Nun escritorio, o cliente práctico é o complemento L2TP de NetworkManager con strongSwan ou Libreswan debaixo.

Unha cadea de proposta que para un complemento de escritorio significa unha cousa pode significar outra para o demo ao que lle entrega o traballo, así que manteña a sintaxe adecuada á capa que edita. Se o dispositivo esixe ademais un segredo de túnel, é unha etapa separada da clave IPsec. Confirme cal das dúas pide a interface antes de escribir nada nela.

IKEv1 agresivo con XAuth, e o caso do portal

Un extremo estilo FortiGate normalmente quere modo agresivo con XAuth e un enderezo en modo configurado, algo que un complemento gráfico pode non expoñer en absoluto. O demo nativo encárgase diso, e o bloque de abaixo é a forma desa configuración, non un ficheiro completo. Consulte a documentación actual do fabricante para os valores da proposta.

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

As versións antigas de strongSwan usaban xauth=client onde a versión 5 usa leftauth2=xauth, así que un fragmento copiado pode fallar só pola sintaxe. Para un portal TLS, openconnect, que fala o protocolo AnyConnect, encárgase de Cisco e da maioría das marcas renomeadas, e necesita un dispositivo TUN e os privilexios para configuralo. Pase o enderezo do portal exactamente como o mostra o navegador, incluída calquera ruta que o dispositivo espere, e logo comprobe o enderezo asignado antes de probar nada detrás. Crear a interface de antemán elimina unha clase de sorpresas durante a configuración.

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

Conecte, logo verifique nunha orde fixa

Execute exactamente un xestor de VPN á vez, porque un perfil de NetworkManager e un demo iniciado a man pelexarán polas rutas e o DNS. Baixe o perfil antes de probar unha conexión manual, e confirme que non sobrevive ningunha interface de túnel antiga. Logo verifique nesta orde: enderezo do túnel, ruta ao único host interno que necesite, resolución de nomes e, por último, unha petición real. Unha icona verde demostra a autenticación e nada máis.

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

Se un paso falla, detéñase aí en lugar de probar o seguinte, porque un fallo de DNS augas abaixo dunha ruta rota non lle ensina nada. Garde unha copia do perfil que funciona antes de experimentar, porque un ficheiro de conexión borrado pérdese facilmente e custa reconstruír. Conserve os valores da proposta na mesma nota que o modelo do dispositivo e a versión de firmware, porque esa nota é a diferenza entre unha migración e un proxecto de arqueoloxía cando se substitúe a caixa.