sshuttle davant d'una VPN completa: què cobreix realment el seu mètode
sshuttle només porta allò que el seu mètode de reenviament admet: comproveu primer la cobertura de TCP, DNS i UDP, el privilegi local que necessita i l'ajudant remot.
sshuttle es tria perquè SSH ja funciona i la criptografia sembla familiar, i aquest raonament omet l'única pregunta que decideix si encaixa. Quins paquets surten de la màquina, quin compte els porta a l'altre costat i quant privilegi local exigeix l'eina. Aquestes tres respostes varien segons el mètode de reenviament, així que una configuració que funciona per a una aplicació pot fallar en silenci per a la següent. El recorregut de sota comença pel protocol que l'aplicació necessita de debò.
Comenceu pel protocol que necessita l'aplicació
El suport de protocols a sshuttle 2.0 depèn del mètode que trieu. Els mètodes NAT i nft de Linux gestionen TCP i DNS, i TPROXY afegeix UDP general. Cada plataforma i cada mètode aporten els seus límits, i macOS intercepta amb un mecanisme completament diferent. Anoteu la versió instal·lada, el mètode triat i els protocols que necessita l'aplicació abans de triar res.
Per tant, una petició TCP que funcioni demostra ben poc sobre una aplicació UDP o sobre cada consulta DNS. sshuttle també tracta TCP com a fluxos en lloc de tunelar paquets IP sencers, així que una conclusió de rendiment manllevada d'una VPN convencional no es trasllada. Compareu el mecanisme que executeu de debò amb la càrrega que teniu de debò.
| 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 |
Què necessita el client localment
La disposició documentada del client requereix root o sudo, perquè instal·la regles d'intercepció locals en lloc de crear una interfície de túnel. Aquest sol fet canvia la història de seguretat: un procés amb aquest privilegi pot redirigir el trànsit de tota la màquina, no només d'una aplicació. Tracteu el privilegi com a part del disseny i no com un detall d'instal·lació.
Confirmeu quines regles ha instal·lat l'eina i que desapareixen en sortir. Una sessió que caigui i deixi regles d'intercepció pot enviar el trànsit a un forat negre molt després que l'operador cregui que la connexió s'ha acabat, i el símptoma sembla una avaria de xarxa i no una regla sobrera.
sudo sshuttle --method nft --dns 172.19.4.0/24
nft list ruleset | grep -i sshuttle
ip routeLa primera ordre és la forma d'una invocació típica, amb el prefix que necessiteu de debò. La segona mostra què ha instal·lat l'eina, i la tercera confirma que no ha aparegut cap interfície de túnel, que és el resultat esperat per a aquest disseny.
Què executa el costat remot
El costat remot és un compte SSH autoritzat més un entorn d'ajudant de Python compatible. Un inici de sessió que funciona en un shell restringit no concedeix automàticament permís per executar aquest ajudant, i un compte que pot executar l'ajudant no arriba automàticament a cada servei de destí. Tots dos fets pertanyen a la sol·licitud d'accés i no a les notes de resolució de problemes.
Protegiu la verificació de la identitat de l'amfitrió i l'autenticació del compte. Acceptar una clau d'amfitrió desconeguda per fer funcionar la primera connexió elimina la comprovació que el costat remot és la màquina que volíeu, i això aquí importa més que en un reenviament d'una sola finalitat.
Limiteu el compte remot als serveis que necessita el flux de treball i negocieu aquest abast amb qui opera l'amfitrió. Formen part de la relació de confiança, i cap paràmetre del costat del client ho canvia.
On se situa la frontera de confiança
Reenviar una connexió d'API privada per SSH no autoritza cada operació d'API. El TLS de l'aplicació i l'inici de sessió de l'aplicació encara s'apliquen, i l'eina no pot fer segur un servei sense autenticació. Un salt addicional des de l'amfitrió remot tampoc no és automàticament el mateix segment protegit que el canal SSH, perquè aquesta segona connexió segueix la política que tingui l'amfitrió remot.
Escriviu la frontera en una frase: el trànsit cap a aquests prefixos surt per aquest compte en aquell amfitrió. Si la frase necessita un paràgraf d'excepcions, el disseny fa més del que afirma la seva documentació i mereix una segona mirada abans d'arribar a producció.
Demostreu-ho per protocol i després trieu l'eina
Proveu cada protocol necessari amb una petició innòcua, inclòs el camí del resolutor i les famílies d'adreces que fa servir l'aplicació. Incloeu una desconnexió a la prova, perquè el comportament de fallada permès de l'aplicació sigui un resultat conegut i no una sorpresa durant un incident. Una sessió que reenviava correctament mentre era engegada no diu res sobre què passa quan cau.
Per a un grapat de serveis anomenats explícitament, un reenviament local ordinari és més fàcil de posseir i d'auditar. Per al trànsit d'aplicacions que encaixa amb el seu mètode, sshuttle ofereix un terme mitjà legítim. Quan el requisit és connectivitat IP àmplia, el disseny VPN és la resposta honesta, i l'elecció segueix la cobertura i la responsabilitat operativa i no un rànquing d'algorismes de xifratge.