Pasos do handshake de VPN: que ocorre antes de que flúa o tráfico

Premer Conectar inicia catro tarefas separadas que teñen éxito ou fallan de forma independente. O cliente debe chegar a un listener, acordar quen é o par, derivar claves e despois entregar un túnel funcional ao resto do sistema. A maioría das conexións fallidas diagnostícanse na tarefa equivocada. Por iso o primeiro erro importa máis que o terceiro intento.

Chegue primeiro ao listener

Antes de que se intercambie calquera identidade, o cliente resolve un nome, escolle unha ruta e abre un transporte cara a un porto. Un portal cativo que responde a todo, un porto pechado e un nome de host incorrecto fallan aquí, e ningún deles é un problema de autenticación. Cambiar un contrasinal non pode arranxar ningún dos tres. Lea a primeira liña do erro antes de tocar as credenciais.

Un tempo de espera esgotado, o rexeitamento dun certificado e unha conta rexeitada son tres fallos distintos con tres comprobacións distintas. Ordenalos primeiro é o que evita que un problema de rede se depure como un problema de credenciais.

Demostre o par e logo derive as claves

Cada protocolo necesita unha forma de recoñecer o servidor previsto, xa sexa mediante unha clave pública configurada ou unha cadea de certificados. O inicio de sesión do usuario é adicional a esa comprobación, non un substituto dela. Un servidor que acepta o seu contrasinal non demostrou nada sobre a súa propia identidade. Por iso un segredo compartido escrito nun cliente non substitúe a verificación de quen respondeu.

O intercambio deriva despois as claves de tráfico a partir das propias entradas do protocolo, e o contrasinal de inicio de sesión xeralmente non é a clave que se estampa en cada paquete. O material de identidade de longa duración e as claves de sesión de curta duración teñen vidas e traballos distintos. Deso trata a confidencialidade cara adiante.

Manteña a verificación activada mentres investiga, porque un túnel que se conecta despois de desactivar unha comprobación non demostrou nada excepto que a comprobación facía algo. Anote que cambiou e vólvao deixar como estaba antes da seguinte proba.

Tres protocolos, tres conversas

Nun despregamento de OpenVPN baseado en TLS, a canle de control negocia os parámetros de seguridade mentres a canle de datos transporta o tráfico do túnel, así que unha opción da canle de datos e un problema de certificado viven en lugares distintos. IKEv2 autentica a ambos os participantes e despois establece asociacións de seguridade IPsec coas súas propias vidas. WireGuard deriva as claves mediante o seu intercambio baseado en Noise e mantén a máquina de estados deliberadamente pequena. Saber cal dos tres executa decide que rexistro paga a pena ler.

Clientes de aspecto semellante non implican mensaxes intercambiables por debaixo, e un campo de configuración que existe nun produto pode non ter equivalente noutro. Copiar un perfil entre eles é unha suposición e non unha migración.

Que non fai o handshake

As rutas, a resolución de nomes e a política de destino permanecen todas despois. Un sitio interno pode quedar inalcanzable porque falta a ruta da súa subrede, aínda que o par se autenticou correctamente e o túnel está activo. Tratar iso como cifrado débil envíalle a buscar na capa equivocada, e normalmente remata cun cambio de cifrado que non arranxa nada.

A renovación de claves e a reconexión tamén se parecen na maioría das pantallas de estado, e ningunha das dúas lle di se se bloqueou o tráfico ordinario durante a interrupción. Só a política de fallo do cliente responde a esa pregunta, así que lea a política e non a icona.

Traballa as etapas na orde anterior e detense na primeira que produza un erro. Cada etapa posterior herda o estado das anteriores, así que un fallo na terceira etapa non di nada sobre a cuarta.

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