Adapteu el client VPN de Linux al protocol de l'aparell vell

Quatre famílies de protocols cobreixen gairebé qualsevol aparell que encara sigui en un rack, i cadascuna falla de manera diferent a Linux. Els ports publicats i les propostes configurades de l'extrem remot decideixen el vostre paquet, no la distribució que executeu per casualitat. Instal·lar el que esmenta un missatge de fòrum i després editar fins que alguna cosa connecta és com desapareix una tarda. Llegiu l'aparell, instal·leu segon, verifiqueu tercer.

Anoteu què publica l'extrem remot

Anoteu el protocol, els ports i l'autenticació que espera l'aparell abans d'obrir un gestor de paquets. Quatre famílies cobreixen la major part de l'equipament vell, i la taula de sota és tota la decisió en una pantalla.

El manual i les regles de tallafoc del mateix aparell són més fiables que el nom del protocol a la seva pàgina d'inici de sessió. Un dispositiu que anuncia IPsec potser només parla IKEv1, i una versió de firmware que ningú no ha aplicat pot ser el que finalment afegeix IKEv2. Confirmeu el camí de dades i també el port de configuració, perquè és aquí on l'equipament vell i les xarxes modernes discrepen. Equivocar-vos en aquest pas vol dir depurar el client contra una funció que l'altre extrem mai no ha tingut.

PPTP: demostreu GRE abans d'editar pppd

PPTP a Linux no és un dimoni que engegueu, sinó una invocació de pppd, i els paràmetres de connexió viuen en un fitxer peer amb nom que pppd llegeix quan se'l crida. Les distribucions encara l'empaqueten, tot i que les debilitats conegudes del protocol el fan inadequat per a qualsevol cosa sensible, així que reserveu-lo estrictament per a un aparell que no ofereixi res més. Vigileu GRE mentre el client negocia, amb una captura curta en lloc d'una suposició. La fallada que fa perdre més temps no és l'autenticació, sinó el camí de dades que falta.

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

Si la configuració acaba i l'enllaç no transporta mai trànsit, sospiteu del camí GRE abans de tocar les credencials. Els grups de seguretat del núvol necessiten una regla explícita per al protocol 47, i algunes xarxes el bloquegen del tot sense cap error visible. Proveu des de la xarxa que realment fareu servir, no des d'un laboratori que ho permet tot.

L2TP/IPsec: una proposta encertada val més que deu intents

Llegiu el registre del dimoni en lloc del diàleg d'escriptori, perquè el diàleg ajunta diverses fallades diferents en un sol missatge. Un error NO_PROPOSAL_CHOSEN pertany a la primera fase: el client ha ofert un xifratge, un hash o un grup Diffie-Hellman que el servidor no acceptarà. Enumeru què admet l'aparell i escriviu una proposta que hi encaixi, perquè les combinacions a l'atzar solen produir el mateix error més lentament. En un escriptori, el client pràctic és el connector L2TP de NetworkManager amb strongSwan o Libreswan a sota.

Una cadena de proposta que per a un connector d'escriptori significa una cosa pot significar-ne una altra per al dimoni a qui lliura la feina, així que manteniu la sintaxi adequada a la capa que editeu. Si l'aparell també exigeix un secret de túnel, és una etapa separada de la clau IPsec. Confirmeu quina de les dues demana la interfície abans d'escriure-hi res.

IKEv1 agressiu amb XAuth, i el cas del portal

Un extrem d'estil FortiGate normalment vol mode agressiu amb XAuth i una adreça en mode configurat, cosa que potser un connector gràfic no exposa gens. El dimoni natiu se n'encarrega, i el bloc de sota és la forma d'aquesta configuració, no un fitxer complet. Consulteu la documentació actual del fabricant per als valors de la proposta.

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

Les versions antigues de strongSwan feien servir xauth=client on la versió 5 fa servir leftauth2=xauth, així que un fragment copiat pot fallar només per la sintaxi. Per a un portal TLS, openconnect, que parla el protocol AnyConnect, s'encarrega de Cisco i de la majoria de marques renomades, i necessita un dispositiu TUN i els privilegis per configurar-lo. Passeu l'adreça del portal exactament com la mostra el navegador, incloent-hi qualsevol camí que l'aparell esperi, i després comproveu l'adreça assignada abans de provar res al darrere. Crear la interfície per endavant elimina una classe de sorpreses durant la configuració.

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

Connecteu, després verifiqueu en un ordre fix

Executeu exactament un gestor de VPN alhora, perquè un perfil de NetworkManager i un dimoni engegat a mà es barallaran per les rutes i el DNS. Baixeu el perfil abans de provar una connexió manual, i confirmeu que no sobreviu cap interfície de túnel antiga. Després verifiqueu en aquest ordre: adreça del túnel, ruta cap a l'únic host intern que necessiteu, resolució de noms i, finalment, una petició real. Una icona verda demostra l'autenticació i res més.

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

Si una passa falla, atureu-vos allà en lloc de provar la següent, perquè una fallada de DNS aigües avall d'una ruta trencada no us ensenya res. Deseu una còpia del perfil que funciona abans d'experimentar, perquè un fitxer de connexió esborrat és fàcil de perdre i feixuc de reconstruir. Guardeu els valors de la proposta a la mateixa nota que el model de l'aparell i la versió del firmware, perquè aquesta nota és la diferència entre una migració i un projecte d'arqueologia quan substituïu la caixa.