Como un reenvío local SSH transporta unha sesión TCP de OpenVPN

Aquí apílanse tres transportes, e cada un ten o seu propio encadramento. A carga útil da VPN viaxa dentro dunha sesión TLS, esa sesión TLS viaxa dentro dunha conexión TCP cara a un porto de bucle local, e os bytes desa conexión viaxan dentro de SSH cara a un host de retransmisión, que abre a conexión TCP real cara ao receptor da VPN. Nada na disposición cambia o que OpenVPN autentica, e nada nela fai que un receptor UDP sexa alcanzable por TCP. Lea o resto como unha descrición do camiño dos bytes, non como unha receita para eludir un control de rede.

Que move realmente o reenvío local

O cliente SSH escoita nun porto local. Cando un proceso local se conecta, o cliente empaqueta os bytes na súa canle cifrada, e o lado do servidor abre unha nova conexión TCP cara ao destino nomeado na petición de reenvío.

Ese destino resólveo o relay, non a súa máquina, por iso un nome que só existe dentro da rede remota segue funcionando. Tamén significa que o relay debe poder alcanzar o receptor da VPN e ter unha ruta de volta cara a el. Un nome que se resolve no seu portátil non di nada sobre o que o relay pode ver.

Iniciar a sesión SSH só demostra que o relay é alcanzable e está autenticado. Non di nada sobre se o seguinte receptor está activo, se un cortafocos entre o relay e o receptor acepta a conexión, ou se a VPN aceptará o seu perfil.

Apunta o cliente ao receptor local

Un exemplo declarado: o relay pode alcanzar un receptor TCP en gw.internal.example:443, e un porto local alto expón ese camiño só a esta máquina.

ssh -N -L 127.0.0.1:24011:gw.internal.example:443 [email protected]

O manual de OpenSSH describe o reenvío local como a aceptación de conexións TCP de forma local e a apertura da seguinte conexión desde o lado remoto. Ate o receptor ao bucle local en lugar de a todas as interfaces, porque un reenvío alcanzable desde a rede é un relay aberto co seu nome. Unha vinculación comodín tamén expón o porto a calquera outra conta local nunha máquina compartida.

Despois pon o cliente da VPN no seu modo TCP e apúntao a 127.0.0.1:24011. Se o perfil usa UDP, este deseño non pode axudar: o reenvío transporta un fluxo de bytes e non hai ningún camiño de datagramas a través del.

Manteña as dúas autenticacións separadas

SSH autentica o host de retransmisión. OpenVPN segue autenticando o par da VPN, e o destino de bucle local non cambia ese requisito. Desactivar as comprobacións de certificado porque o socket agora apunta a localhost é o peor atallo dispoñible neste deseño. Converte unha disposición de transporte nunha disposición de confianza, e ninguén aprobou a segunda.

Manteña intactos a áncora de confianza do perfil, a comprobación do rol de servidor e a verificación do nome. Se o seu cliente compara o nome do servidor co enderezo ao que chamou, o bucle local pode necesitar un axuste explícito de nome en lugar dunha comprobación desactivada, e a documentación do perfil é o lugar para confirmar que campo se compara.

Trate o relay como unha segunda parte na historia de confianza: o seu administrador pode ver metadatos de conexión e pode redirixir o reenvío se se cambia a configuración. A disposición necesita a aprobación tanto do relay como do propietario do servizo VPN, non só de quen o necesita hoxe.

Non constrúa un bucle baixo o túnel

Unha vez que a VPN instala rutas, a conexión SSH que a transporta aínda necesita un camiño cara ao relay que non pase polo túnel. Se a ruta por defecto pasa á VPN e o relay só é alcanzable por ese mesmo túnel, o transporte derrúbese e a VPN vai con el. O fallo parece un túnel caído máis que un erro de encamiñamento, e por iso se diagnostica mal.

A solución habitual é unha ruta de host cara ao enderezo do relay fixada á interface física antes de que suba o túnel, máis unha comprobación de que a ruta sobrevive a unha reconexión. Verifíquea cunha consulta de ruta para o enderezo do relay en lugar de supoñer que a orde era correcta.

Tamén espere que esta pila sexa máis lenta e máis fráxil que unha conexión directa, porque agora hai dous transportes ordenados e outro punto final que manter. É unha forma de cruzar unha fronteira de rede, non unha técnica de rendemento.

Pecha o receptor cando remate

Detén a sesión SSH cando o túnel xa non sexa necesario e confirma que o porto local se liberou. Un reenvío esquecido mantén un camiño autenticado aberto nunha máquina que pode ser compartida.

Revise tamén os destinos de reenvío permitidos do relay, porque unha configuración permisiva converte calquera conta comprometida nun pivote xeral. Anote o porto, o relay e o destino xuntos, para que a seguinte persoa poida saber para que servía o reenvío e se aínda está aprobado.