Passos de l’apretada de mans VPN: què passa abans que hi hagi trànsit

Prémer Connecta engega quatre tasques separades que tenen èxit o fallen de manera independent. El client ha d’arribar a un oient, acordar qui és el parell, derivar claus i després lliurar un túnel funcional a la resta del sistema. La majoria de connexions fallides es diagnostiquen a la tasca equivocada. Per això el primer error importa més que el tercer reintent.

Arribeu primer a l’oient

Abans que s’intercanviï cap identitat, el client resol un nom, tria una ruta i obre un transport cap a un port. Un portal captiu que respon a tot, un port tancat i un nom d’amfitrió equivocat fallen tots aquí, i cap dels tres no és un problema d’autenticació. Canviar una contrasenya no pot arreglar cap dels tres. Llegiu la primera línia de l’error abans de tocar les credencials.

Un temps d’espera esgotat, el rebuig d’un certificat i un compte rebutjat són tres avaries diferents amb tres comprovacions diferents. Ordenar-les primer és el que evita que un problema de xarxa es depuri com a problema de credencials.

Demostreu el parell i després deriveu les claus

Cada protocol necessita una manera de reconèixer el servidor previst, ja sigui mitjançant una clau pública configurada o una cadena de certificats. L’inici de sessió de l’usuari és addicional a aquesta comprovació, no un substitut. Un servidor que accepta la vostra contrasenya no ha demostrat res sobre la seva pròpia identitat. Per això un secret compartit escrit en un client no substitueix la verificació de qui ha respost.

L’intercanvi després deriva les claus de trànsit a partir de les entrades pròpies del protocol, i la contrasenya d’inici de sessió generalment no és la clau que es grava a cada paquet. El material d’identitat de llarga durada i les claus de sessió de curta durada tenen vides i feines diferents. Aquesta separació és el que significa la confidencialitat directa.

Mantingueu la verificació activada mentre investigueu, perquè un túnel que es connecta després que desactiveu una comprovació no ha demostrat res excepte que la comprovació feia alguna cosa. Anoteu què heu canviat i torneu-ho a posar abans de la prova següent.

Tres protocols, tres converses

En un desplegament OpenVPN basat en TLS, el canal de control negocia els paràmetres de seguretat mentre el canal de dades porta el trànsit del túnel, així que una opció del canal de dades i un problema de certificat viuen en llocs diferents. IKEv2 autentica tots dos participants i després estableix associacions de seguretat IPsec amb les seves pròpies vides. WireGuard deriva les claus mitjançant el seu intercanvi basat en Noise i manté la màquina d’estats deliberadament petita. Saber quin dels tres executeu decideix quin registre val la pena llegir.

Clients d’aspecte semblant no impliquen missatges intercanviables a sota, i un camp de configuració que existeix en un producte pot no tenir equivalent en un altre. Copiar un perfil entre ells és una conjectura i no una migració.

Què no fa l’apretada de mans

Les rutes, la resolució de noms i la política de destinació romanen totes després. Un lloc intern pot quedar inabastable perquè falta la ruta de la seva subxarxa, tot i que el parell s’ha autenticat correctament i el túnel està actiu. Tractar-ho com un xifratge feble us envia a buscar a la capa equivocada, i normalment acaba amb un canvi de xifrador que no arregla res.

La renovació de claus i la reconnexió també semblen iguals en la majoria de visualitzacions d’estat, i cap de les dues no us diu si es va bloquejar el trànsit ordinari durant la interrupció. Només la política de fallada del client respon aquesta pregunta, així que llegiu la política i no la icona.

Feu les etapes en l’ordre anterior i atureu-vos a la primera que produeixi un error. Cada etapa posterior hereta l’estat de les anteriors, així que una fallada a la tercera etapa no diu res sobre la quarta.

ip -brief address show tun0
ip route get 10.60.7.15
resolvectl query intranet.corp.internal