Chegar a un sitio HTTPS só por VPN mediante un reenvío SSH

Unha máquina xa ten acceso VPN aprobado, unha segunda máquina necesita exactamente un servizo HTTPS privado, e un reenvío SSH local pode salvar esa fenda sen darlle un túnel á segunda máquina. O reenvío transporta un só destino TCP en lugar de toda a rede, e esa limitación é xustamente o punto. Percorra os cinco pasos seguintes en orde, porque cada un falla por unha razón distinta e un paso posterior non pode rescatar unha fenda anterior. Se falta calquera condición previa, este deseño non a resolve e ningún axuste de comandos o conseguirá.

Paso un: confirme as tres condicións previas

Tres cousas deben ser certas antes de que calquera comando importe. Necesita permiso para usar a primeira máquina como host de reenvío, acceso SSH operativo a ela e unha política de servidor que permita o destino previsto. Unha conta SSH creada para transferir ficheiros pode ter o reenvío desactivado, e un servidor que permite reenvío aínda pode restrinxir que destinos son accesibles a través del. Pregunte antes de probar, porque usar a estación de traballo dun colega como punto de salto sen acordo é un problema de política, mesmo cando o comando funciona sen problemas.

Dous comandos resolven a metade técnica desa lista. O primeiro demostra que a conta e a chave funcionan sen un aviso interactivo, e o segundo imprime a política efectiva do servidor en lugar do exemplo comentado no ficheiro de configuración.

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

Paso dous: ligue un porto de loopback e manteña viva a sesión

Na máquina que executa a aplicación cliente, abra un reenvío local cara ao servizo privado. Lígueo explicitamente ao loopback para que non se publique na rede local, e escolla un porto alto que ningún servizo local ocupe xa. Manteña a sesión en marcha mentres traballa, xa que pechala pecha o oínte. ExitOnForwardFailure converte unha ligazón rexeitada ou un porto ocupado nunha saída inmediata en lugar dunha sesión que queda levantada sen reenvío, e ese é o modo de fallo que máis tempo desperdicia.

A conexión privada faise desde o host de salto, así que o seu DNS, as súas rutas, a súa política VPN e o seu acceso ao servizo deben funcionar todos. A sesión SSH non crea alcanzabilidade que ao host de salto lle falta, e non pode reparar unha ruta que a VPN nunca empuxou. Confirme o oínte onde realmente está en lugar de confiar no silencio do 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 o nome HTTPS cando o socket é local

Navegar a https://127.0.0.1:9443/ cambia o nome do servidor TLS e a autoridade da aplicación. Un certificado emitido para portal.lab.example non validará contra un enderezo de loopback, e o erro resultante parece un certificado roto máis que un atallo de reenvío. Para unha proba de liña de comandos, conserve a URL real e cambie só o destino do socket. Iso é o que fai --connect-to, e o manual de curl documenta a forma de catro campos que se usa abaixo.

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

O nome permanece na URL, no apretón de mans TLS e na cabeceira Host, mentres que a conexión TCP vai ao oínte local. A opción sen proxy mantén a proba neste reenvío en lugar de deixar que un proxy HTTP configurado a intercepte, e manter a verificación de certificados activa é o que fai significativo o resultado.

Paso catro: saiba que non pode cubrir un só reenvío

Un só reenvío TCP cobre un porto de destino. Unha páxina que redirixe a un segundo nome de host, carga recursos dun host dentro da rede privada ou envía a outro porto necesita o seu propio reenvío, e cada un deles necesita a mesma comprobación de política que o primeiro. Os fluxos de traballo do navegador engaden requisitos propios, porque hai que dicirlle ao navegador que envíe o nome real ao porto local mediante unha configuración de proxy ou unha asignación local. Por tanto, unha proba de liña de comandos exitosa non demostra que o navegador o conseguirá, aínda que demostre a ruta.

UDP, o descubrimento SMB e o inicio de sesión de dominio non viaxan en absoluto por un reenvío TCP. Se o requisito real é acceso xeral á rede, este deseño é a ferramenta equivocada e unha pasarela de acceso remoto compatible é a correcta.

Paso cinco: limpe e déixeo rexistrado

Detéñase a sesión cando remate a proba e confirme que o oínte desapareceu. Se o porto elixido xa estaba ocupado, escolla outro porto de loopback sen usar e actualice á vez a URL, o comando de proba e a nota, en lugar de terminar un servizo local non relacionado para liberar o número. Deixar un reenvío aberto nun portátil converte un diagnóstico nun servizo non xestionado.

Anote o host de salto, o destino reenviado, o porto local e quen aprobou o acordo. Un reenvío que só existe no historial de shell de alguén está a un reinicio dunha investigación repetida, e a seguinte persoa non saberá cal das tres condicións previas xa se comprobou.