Como um encaminhamento local SSH transporta uma sessão TCP OpenVPN

Aqui empilham-se três transportes, e cada um tem o seu próprio enquadramento. A carga útil da VPN viaja dentro de uma sessão TLS, essa sessão TLS viaja dentro de uma conexão TCP para uma porta de loopback, e os bytes dessa conexão viajam dentro do SSH para um host de retransmissão, que abre a conexão TCP real para o ouvinte da VPN. Nada na disposição muda o que OpenVPN autentica, e nada nela torna um ouvinte UDP alcançável por TCP. Leia o resto como uma descrição do caminho dos bytes, não como uma receita para contornar um controlo de rede.

O que o encaminhamento local move realmente

O cliente SSH escuta numa porta local. Quando um processo local se liga, o cliente empacota os bytes no seu canal cifrado, e o lado do servidor abre uma nova conexão TCP para o destino indicado no pedido de encaminhamento.

Esse destino é resolvido pelo relay, não pela sua máquina, e é por isso que um nome que só existe dentro da rede remota continua a funcionar. Também significa que o relay tem de conseguir alcançar o ouvinte da VPN e ter uma rota de regresso até ele. Um nome que se resolve no seu portátil não diz nada sobre o que o relay consegue ver.

Iniciar a sessão SSH prova apenas que o relay está acessível e autenticado. Não diz nada sobre se o ouvinte seguinte está ativo, se uma firewall entre o relay e o ouvinte aceita a ligação, ou se a VPN aceitará o seu perfil.

Aponte o cliente para o ouvinte local

Um exemplo declarado: o relay consegue alcançar um ouvinte TCP em gw.internal.example:443, e uma porta local alta expõe esse caminho apenas a esta máquina.

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

O manual do OpenSSH descreve o encaminhamento local como a aceitação local de ligações TCP e a abertura da ligação seguinte do lado remoto. Ligue o ouvinte ao loopback em vez de a todas as interfaces, porque um encaminhamento alcançável a partir da rede é um relay aberto com o seu nome. Uma ligação com curinga também expõe a porta a qualquer outra conta local numa máquina partilhada.

Depois coloque o cliente da VPN no modo TCP e aponte-o para 127.0.0.1:24011. Se o perfil usar UDP, este desenho não pode ajudar: o encaminhamento transporta um fluxo de bytes e não há caminho de datagramas através dele.

Mantenha as duas autenticações separadas

O SSH autentica o host de retransmissão. O OpenVPN continua a autenticar o par da VPN, e o destino de loopback não muda esse requisito. Desativar as verificações de certificado porque o socket agora aponta para localhost é o pior atalho disponível neste desenho. Converte uma disposição de transporte numa disposição de confiança, e ninguém aprovou a segunda.

Mantenha intactos a âncora de confiança do perfil, a verificação do papel de servidor e a verificação do nome. Se o seu cliente compara o nome do servidor com o endereço para onde ligou, o loopback pode precisar de uma definição explícita de nome em vez de uma verificação desativada, e a documentação do perfil é o local para confirmar que campo é comparado.

Trate o relay como uma segunda parte na história da confiança: o seu administrador pode ver metadados de ligação e pode redirecionar o encaminhamento se a configuração for alterada. A disposição precisa da aprovação tanto do relay como do proprietário do serviço VPN, não apenas de quem precisa dela hoje.

Não construa um laço sob o túnel

Depois de a VPN instalar rotas, a ligação SSH que a transporta continua a precisar de um caminho para o relay que não passe pelo túnel. Se a rota predefinida passar para a VPN e o relay só for alcançável através desse mesmo túnel, o transporte colapsa e a VPN vai com ele. A falha parece um túnel caído em vez de um erro de encaminhamento, e é por isso que é mal diagnosticada.

A correção habitual é uma rota de host para o endereço do relay fixada à interface física antes de o túnel subir, mais uma verificação de que a rota sobrevive a uma reconexão. Verifique-a com uma consulta de rota para o endereço do relay em vez de assumir que a ordem estava correta.

Espere também que esta pilha seja mais lenta e mais frágil do que uma ligação direta, porque agora há dois transportes ordenados e outro ponto final para manter. É uma forma de atravessar uma fronteira de rede, não uma técnica de desempenho.

Feche o ouvinte quando terminar

Pare a sessão SSH quando o túnel já não for necessário, e confirme que a porta local foi libertada. Um encaminhamento esquecido mantém um caminho autenticado aberto numa máquina que pode ser partilhada.

Reveja também os destinos de encaminhamento permitidos do relay, porque uma configuração permissiva transforma qualquer conta comprometida num pivô geral. Anote a porta, o relay e o destino em conjunto, para que a próxima pessoa saiba para que servia o encaminhamento e se ainda está aprovado.