sshuttle contra uma VPN completa: o que o seu método cobre realmente

o sshuttle é escolhido porque o SSH já funciona e a criptografia parece familiar, e esse raciocínio salta a única pergunta que decide se serve. Que pacotes saem da máquina, que conta os transporta do outro lado e quanto privilégio local a ferramenta exige. Estas três respostas variam com o método de encaminhamento, por isso uma configuração que funciona para uma aplicação pode falhar em silêncio para a seguinte. O percurso abaixo começa pelo protocolo de que a aplicação realmente precisa.

Comece pelo protocolo de que a aplicação precisa

O suporte de protocolos no sshuttle 2.0 depende do método que escolher. Os métodos NAT e nft do Linux tratam TCP e DNS, e o TPROXY acrescenta UDP geral. Cada plataforma e cada método trazem os seus próprios limites, e o macOS intercepta através de um mecanismo completamente diferente. Anote a versão instalada, o método escolhido e os protocolos de que a aplicação precisa antes de escolher seja o que for.

Um pedido TCP bem-sucedido prova, portanto, muito pouco sobre uma aplicação UDP ou sobre cada consulta DNS. O sshuttle também trata o TCP como fluxos em vez de encapsular pacotes IP inteiros, pelo que uma conclusão de débito emprestada de uma VPN convencional não se transpõe. Compare o mecanismo que executa de facto com a carga que de facto tem.

O que o cliente precisa localmente

A disposição documentada do cliente exige root ou sudo, porque instala regras locais de interceção em vez de criar uma interface de túnel. Esse único facto muda a história da segurança: um processo com esse privilégio pode redirecionar o tráfego de toda a máquina, não apenas de uma aplicação. Trate o privilégio como parte do desenho e não como um detalhe de instalação.

Confirme que regras a ferramenta instalou e que desaparecem quando sai. Uma sessão que falhe e deixe regras de interceção pode enviar o tráfego para um buraco negro muito depois de o operador acreditar que a ligação se foi, e o sintoma parece uma falha de rede e não uma regra sobrante.

sudo sshuttle --method nft --dns 172.19.4.0/24
nft list ruleset | grep -i sshuttle
ip route

O primeiro comando é a forma de uma invocação típica, com o prefixo de que realmente precisa. O segundo mostra o que a ferramenta instalou, e o terceiro confirma que não surgiu nenhuma interface de túnel, que é o resultado esperado para este desenho.

O que executa o lado remoto

O lado remoto é uma conta SSH autorizada mais um ambiente de assistente de Python compatível. Um início de sessão que funciona num shell restrito não concede automaticamente permissão para executar esse assistente, e uma conta que consegue executar o assistente não chega automaticamente a cada serviço de destino. Ambos os factos pertencem ao pedido de acesso e não às notas de resolução de problemas.

Proteja a verificação da identidade do anfitrião e a autenticação da conta. Aceitar uma chave de anfitrião desconhecida para a primeira ligação funcionar remove a verificação de que o lado remoto é a máquina pretendida, e isso aqui pesa mais do que num encaminhamento de um só propósito.

Limite a conta remota aos serviços de que o fluxo de trabalho precisa e negoceie esse âmbito com quem opera o anfitrião. Fazem parte da relação de confiança, e nenhum ajuste do lado do cliente muda isso.

Onde fica a fronteira de confiança

Encaminhar uma ligação de API privada através de SSH não autoriza cada operação de API. O TLS da aplicação e o início de sessão na aplicação continuam a aplicar-se, e a ferramenta não consegue tornar seguro um serviço sem autenticação. Um salto adicional a partir do anfitrião remoto também não é automaticamente o mesmo segmento protegido que o canal SSH, porque essa segunda ligação segue a política que o anfitrião remoto tiver.

Escreva a fronteira numa frase: o tráfego para estes prefixos sai por esta conta naquele anfitrião. Se a frase precisar de um parágrafo de exceções, o desenho faz mais do que a sua documentação afirma e merece uma segunda análise antes de chegar à produção.

Prove-o por protocolo e depois escolha a ferramenta

Teste cada protocolo necessário com um pedido inofensivo, incluindo o caminho do resolvedor e as famílias de endereços que a aplicação usa. Inclua uma desconexão no teste, para que o comportamento de falha permitido da aplicação seja um resultado conhecido e não uma surpresa durante um incidente. Uma sessão que encaminhava corretamente enquanto estava ativa não diz nada sobre o que acontece quando cai.

Para um punhado de serviços nomeados explicitamente, um encaminhamento local comum é mais fácil de possuir e de auditar. Para o tráfego de aplicações que se adequa ao seu método, o sshuttle oferece uma via intermédia legítima. Quando o requisito é conectividade IP ampla, um desenho de VPN é a resposta honesta, e a escolha segue a cobertura e a responsabilidade operacional e não uma classificação de algoritmos de cifra.