Llegar a un sitio HTTPS solo por VPN mediante un reenvío SSH

Una máquina ya tiene acceso VPN aprobado, una segunda máquina necesita exactamente un servicio HTTPS privado, y un reenvío SSH local puede salvar esa brecha sin darle un túnel a la segunda máquina. El reenvío transporta un solo destino TCP en lugar de toda la red, y esa limitación es justamente el punto. Recorra los cinco pasos siguientes en orden, porque cada uno falla por una razón distinta y un paso posterior no puede rescatar una brecha anterior. Si falta cualquier condición previa, este diseño no la resuelve y ningún ajuste de comandos lo conseguirá.

Paso uno: confirme las tres condiciones previas

Tres cosas deben ser ciertas antes de que cualquier comando importe. Necesita permiso para usar la primera máquina como host de reenvío, acceso SSH operativo a ella y una política de servidor que permita el destino previsto. Una cuenta SSH creada para transferir archivos puede tener el reenvío desactivado, y un servidor que permite reenvío todavía puede restringir qué destinos son accesibles a través de él. Pregunte antes de probar, porque usar la estación de trabajo de un colega como punto de salto sin acuerdo es un problema de política, incluso cuando el comando funciona sin problemas.

Dos comandos resuelven la mitad técnica de esa lista. El primero demuestra que la cuenta y la clave funcionan sin un aviso interactivo, y el segundo imprime la política efectiva del servidor en lugar del ejemplo comentado en el archivo de configuración.

ssh -o BatchMode=yes [email protected] 'echo ok'
sudo sshd -T | grep -E 'allowtcpforwarding|permitopen'

Paso dos: enlace un puerto de loopback y mantenga viva la sesión

En la máquina que ejecuta la aplicación cliente, abra un reenvío local hacia el servicio privado. Enlácelo explícitamente al loopback para que no se publique en la red local, y elija un puerto alto que ningún servicio local ocupe ya. Mantenga la sesión en marcha mientras trabaja, ya que cerrarla cierra el oyente. ExitOnForwardFailure convierte un enlace rechazado o un puerto ocupado en una salida inmediata en lugar de una sesión que queda levantada sin reenvío, y ese es el modo de fallo que más tiempo desperdicia.

La conexión privada se hace desde el host de salto, así que su DNS, sus rutas, su política VPN y su acceso al servicio deben funcionar todos. La sesión SSH no crea alcanzabilidad que al host de salto le falta, y no puede reparar una ruta que la VPN nunca empujó. Confirme el oyente donde realmente está en lugar de confiar en el silencio del comando.

ssh -N -o ExitOnForwardFailure=yes -L 127.0.0.1:9443:portal.lab.example:443 [email protected]
ss -ltn '( sport = :9443 )'

Paso tres: conserve el nombre HTTPS cuando el socket es local

Navegar a https://127.0.0.1:9443/ cambia el nombre del servidor TLS y la autoridad de la aplicación. Un certificado emitido para portal.lab.example no validará contra una dirección de loopback, y el error resultante parece un certificado roto más que un atajo de reenvío. Para una prueba de línea de comandos, conserve la URL real y cambie solo el destino del socket. Eso es lo que hace --connect-to, y el manual de curl documenta la forma de cuatro campos que se usa abajo.

curl --noproxy portal.lab.example --connect-to portal.lab.example:443:127.0.0.1:9443 https://portal.lab.example/

El nombre permanece en la URL, en el apretón de manos TLS y en la cabecera Host, mientras que la conexión TCP va al oyente local. La opción sin proxy mantiene la prueba en este reenvío en lugar de dejar que un proxy HTTP configurado la intercepte, y mantener la verificación de certificados activa es lo que hace significativo el resultado.

Paso cuatro: sepa qué no puede cubrir un solo reenvío

Un solo reenvío TCP cubre un puerto de destino. Una página que redirige a un segundo nombre de host, carga recursos de un host dentro de la red privada o envía a otro puerto necesita su propio reenvío, y cada uno de ellos necesita la misma comprobación de política que el primero. Los flujos de trabajo del navegador añaden requisitos propios, porque hay que decirle al navegador que envíe el nombre real al puerto local mediante una configuración de proxy o un mapeo local. Por tanto, una prueba de línea de comandos exitosa no demuestra que el navegador lo conseguirá, aunque demuestre la ruta.

UDP, el descubrimiento SMB y el inicio de sesión de dominio no viajan en absoluto por un reenvío TCP. Si el requisito real es acceso general a la red, este diseño es la herramienta equivocada y una pasarela de acceso remoto compatible es la correcta.

Paso cinco: limpie y déjelo registrado

Detenga la sesión cuando termine la prueba y confirme que el oyente desapareció. Si el puerto elegido ya estaba ocupado, elija otro puerto de loopback sin usar y actualice a la vez la URL, el comando de prueba y la nota, en lugar de terminar un servicio local no relacionado para liberar el número. Dejar un reenvío abierto en un portátil convierte un diagnóstico en un servicio no gestionado.

Anote el host de salto, el destino reenviado, el puerto local y quién aprobó el acuerdo. Un reenvío que solo existe en el historial de shell de alguien está a un reinicio de una investigación repetida, y la siguiente persona no sabrá cuál de las tres condiciones previas ya se comprobó.