sshuttle fronte a unha VPN completa: que cobre realmente o seu método
sshuttle só transporta o que admite o seu método de reenvío: comprobe primeiro a cobertura de TCP, DNS e UDP, o privilexio local que necesita e o axudante remoto.
sshuttle escóllese porque SSH xa funciona e a criptografía resulta familiar, e ese razoamento omite a única pregunta que decide se encaixa. Que paquetes saen da máquina, que conta os transporta ao outro lado e canto privilexio local esixe a ferramenta. Esas tres respostas cambian segundo o método de reenvío, así que unha configuración que funciona para unha aplicación pode fallar en silencio para a seguinte. O percorrido de abaixo comeza polo protocolo que a aplicación necesita de verdade.
Comece polo protocolo que necesita a aplicación
O soporte de protocolos en sshuttle 2.0 depende do método que escolla. Os métodos NAT e nft de Linux manexan TCP e DNS, e TPROXY engade UDP xeral. Cada plataforma e cada método traen os seus propios límites, e macOS intercepta mediante un mecanismo completamente distinto. Anote a versión instalada, o método escollido e os protocolos que necesita a aplicación antes de escoller nada.
Por tanto, unha petición TCP que funcione demostra moi pouco sobre unha aplicación UDP ou sobre cada consulta DNS. sshuttle tamén trata TCP como fluxos en lugar de tunelar paquetes IP enteiros, así que unha conclusión de rendemento tomada dunha VPN convencional non se traslada. Compare o mecanismo que executa realmente coa carga que realmente ten.
| Approach | What it carries | What it needs locally |
|---|---|---|
| SSH local forward | One explicitly named TCP destination | Nothing beyond the SSH client |
| sshuttle, nft or nat method | TCP and DNS to the routed prefixes | Root or sudo for firewall rules |
| sshuttle, tproxy method | TCP, DNS and general UDP | Root or sudo, and kernel support |
| IP VPN | Routed IP traffic in a tunnel | A client with the required privileges |
Que necesita o cliente localmente
A disposición documentada do cliente require root ou sudo, porque instala regras locais de interceptación en vez de crear unha interface de túnel. Ese único feito cambia a historia de seguridade: un proceso con ese privilexio pode redirixir o tráfico de toda a máquina, non só o dunha aplicación. Trate o privilexio como parte do deseño e non como un detalle de instalación.
Confirme que regras instalou a ferramenta e que desaparecen ao saír. Unha sesión que caia e deixe regras de interceptación pode enviar o tráfico a un burato negro moito despois de que o operador crea que a conexión se foi, e o síntoma parece unha avaría de rede e non unha regra sobrante.
sudo sshuttle --method nft --dns 172.19.4.0/24
nft list ruleset | grep -i sshuttle
ip routeO primeiro comando é a forma dunha invocación típica, co prefixo que realmente necesita. O segundo mostra que instalou a ferramenta, e o terceiro confirma que non apareceu ningunha interface de túnel, que é o resultado esperado para este deseño.
Que executa o lado remoto
O lado remoto é unha conta SSH autorizada máis un ambiente de axudante de Python compatible. Un inicio de sesión que funciona nun shell restrinxido non concede automaticamente permiso para executar ese axudante, e unha conta que pode executar o axudante non chega automaticamente a cada servizo de destino. Ambos os feitos pertencen á solicitude de acceso e non ás notas de resolución de problemas.
Protexa a verificación da identidade do host e a autenticación da conta. Aceptar unha chave de host descoñecida para que funcione a primeira conexión elimina a comprobación de que o lado remoto é a máquina que vostede pretendía, e iso aquí importa máis que nun reenvío dun só propósito.
Limite a conta remota aos servizos que necesita o fluxo de traballo e negocie ese alcance con quen opera o host. Forman parte da relación de confianza, e ningún axuste do lado do cliente cambia iso.
Onde está a fronteira de confianza
Reenviar unha conexión de API privada por SSH non autoriza cada operación de API. O TLS da aplicación e o inicio de sesión na aplicación seguen aplicándose, e a ferramenta non pode facer seguro un servizo sen autenticación. Un salto adicional desde o host remoto tampouco é automaticamente o mesmo segmento protexido que a canle SSH, porque esa segunda conexión segue a política que teña o host remoto.
Escriba a fronteira nunha frase: o tráfico cara a estes prefixos sae por esta conta naquel host. Se a frase necesita un parágrafo de excepcións, o deseño fai máis do que afirma a súa documentación e merece unha segunda ollada antes de chegar a produción.
Demostreo por protocolo e logo escolla a ferramenta
Probe cada protocolo necesario cunha petición inocua, incluído o camiño do resolvedor e as familias de enderezos que usa a aplicación. Inclúa unha desconexión na proba, para que o comportamento de fallo permitido da aplicación sexa un resultado coñecido e non unha sorpresa durante un incidente. Unha sesión que reenviaba correctamente mentres estaba activa non di nada sobre que ocorre cando cae.
Para un puñado de servizos nomeados explicitamente, un reenvío local corrente é máis fácil de posuír e de auditar. Para o tráfico de aplicacións que encaixa co seu método, sshuttle ofrece un termo medio lexítimo. Cando o requisito é conectividade IP ampla, o deseño de VPN é a resposta honesta, e a elección segue a cobertura e a responsabilidade operativa e non unha clasificación de algoritmos de cifrado.