Chegar a um site HTTPS disponível apenas por VPN através de um encaminhamento SSH

Uma máquina já tem acesso VPN aprovado, uma segunda máquina precisa de exatamente um serviço HTTPS privado, e um encaminhamento SSH local pode colmatar essa lacuna sem dar à segunda máquina um túnel. O encaminhamento transporta um único destino TCP em vez de toda a rede, e é precisamente esse limite que importa. Percorra os cinco passos abaixo por ordem, porque cada um falha por um motivo diferente e um passo posterior não consegue salvar uma lacuna anterior. Se faltar qualquer condição prévia, este desenho não a resolve e nenhum ajuste de comandos o conseguirá.

Passo um: confirme as três condições prévias

Três coisas têm de já ser verdadeiras antes de qualquer comando importar. Precisa de autorização para usar a primeira máquina como anfitrião de encaminhamento, de acesso SSH funcional a ela e de uma política de servidor que permita o destino pretendido. Uma conta SSH criada para transferência de ficheiros pode ter o encaminhamento desativado, e um servidor que permite encaminhamento pode ainda restringir que destinos são acessíveis através dele. Pergunte antes de testar, porque usar a estação de trabalho de um colega como ponto de salto sem acordo é um problema de política, mesmo quando o comando funciona sem falhas.

Dois comandos resolvem a metade técnica dessa lista. O primeiro prova que a conta e a chave funcionam sem um pedido interativo, e o segundo imprime a política efetiva do servidor em vez do exemplo comentado no ficheiro de configuração.

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

Passo dois: ligue uma porta de loopback e mantenha a sessão viva

Na máquina que executa a aplicação cliente, abra um encaminhamento local para o serviço privado. Ligue-o explicitamente ao loopback para que não seja publicado na rede local, e escolha uma porta alta que nenhum serviço local ocupe já. Mantenha a sessão em execução enquanto trabalha, porque fechá-la fecha o ouvinte. ExitOnForwardFailure transforma uma ligação recusada ou uma porta ocupada em saída imediata em vez de uma sessão que fica de pé sem encaminhamento, e esse é o modo de falha que mais tempo desperdiça.

A ligação privada é feita a partir do anfitrião de salto, por isso o DNS, as rotas, a política VPN e o acesso ao serviço desse anfitrião têm todos de funcionar. A sessão SSH não cria alcançabilidade que o anfitrião de salto não tem, e não consegue reparar uma rota que a VPN nunca empurrou. Confirme o ouvinte onde ele realmente está em vez de confiar no silêncio do comando.

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

Passo três: mantenha o nome HTTPS quando o socket é local

Navegar para https://127.0.0.1:9443/ altera o nome do servidor TLS e a autoridade da aplicação. Um certificado emitido para portal.lab.example não será validado contra um endereço de loopback, e o erro resultante parece um certificado quebrado em vez de um atalho de encaminhamento. Para um teste de linha de comandos, mantenha o URL real e altere apenas o destino do socket. É o que --connect-to faz, e o manual do curl documenta a forma de quatro campos usada abaixo.

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

O nome permanece no URL, no aperto de mão TLS e no cabeçalho Host, enquanto a ligação TCP vai para o ouvinte local. A opção sem proxy mantém o teste neste encaminhamento em vez de deixar um proxy HTTP configurado intercetá-lo, e manter a verificação de certificados ativa é o que torna o resultado significativo.

Passo quatro: saiba o que um único encaminhamento não consegue cobrir

Um único encaminhamento TCP cobre uma porta de destino. Uma página que redireciona para um segundo nome de anfitrião, carrega recursos de um anfitrião dentro da rede privada ou envia para outra porta precisa do seu próprio encaminhamento, e cada um deles exige a mesma verificação de política que o primeiro. Os fluxos de trabalho do navegador acrescentam requisitos próprios, porque é preciso dizer ao navegador para enviar o nome real para a porta local através de uma configuração de proxy ou de um mapeamento local. Um teste de linha de comandos bem-sucedido não prova, portanto, que o navegador o conseguirá, embora prove o caminho.

UDP, a descoberta SMB e a autenticação de domínio não passam de todo por um encaminhamento TCP. Se o requisito real for acesso geral à rede, este desenho é a ferramenta errada e uma passagem de acesso remoto suportada é a certa.

Passo cinco: limpe e registe

Pare a sessão quando o teste terminar e confirme que o ouvinte desapareceu. Se a porta escolhida já estava ocupada, escolha outra porta de loopback não usada e atualize ao mesmo tempo o URL, o comando de teste e a nota, em vez de parar um serviço local não relacionado para libertar o número. Deixar um encaminhamento aberto num portátil transforma um diagnóstico num serviço não gerido.

Anote o anfitrião de salto, o destino encaminhado, a porta local e quem aprovou o arranjo. Um encaminhamento que só existe no histórico de shell de alguém está a um reinício de uma investigação repetida, e a pessoa seguinte não saberá qual das três condições prévias já foi verificada.