sshuttle contro una VPN completa: cosa copre davvero il suo metodo
sshuttle trasporta solo ciò che il suo metodo di inoltro supporta: verificate prima la copertura di TCP, DNS e UDP, il privilegio locale necessario e l'assistente remoto.
sshuttle viene scelto perché SSH funziona già e la crittografia sembra familiare, e questo ragionamento salta l'unica domanda che decide se è adatto. Quali pacchetti lasciano la macchina, quale account li trasporta dall'altra parte e quanto privilegio locale richiede lo strumento. Queste tre risposte cambiano con il metodo di inoltro, quindi una configurazione che funziona per un'applicazione può fallire in silenzio per la successiva. Il percorso qui sotto parte dal protocollo di cui l'applicazione ha davvero bisogno.
Partite dal protocollo di cui ha bisogno l'applicazione
Il supporto dei protocolli in sshuttle 2.0 dipende dal metodo scelto. I metodi NAT e nft di Linux gestiscono TCP e DNS, e TPROXY aggiunge UDP generale. Ogni piattaforma e ogni metodo hanno i propri limiti, e macOS intercetta con un meccanismo del tutto diverso. Annotate la versione installata, il metodo scelto e i protocolli di cui l'applicazione ha bisogno prima di scegliere qualsiasi cosa.
Una richiesta TCP funzionante dimostra quindi molto poco su un'applicazione UDP o su ogni interrogazione DNS. sshuttle tratta anche TCP come flussi invece di incapsulare pacchetti IP interi, quindi una conclusione sulla velocità presa da una VPN tradizionale non si trasferisce. Confrontate il meccanismo che eseguite davvero con il carico che avete davvero.
| 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 |
Cosa serve al client localmente
La disposizione del client documentata richiede root o sudo, perché installa regole di intercettazione locali invece di creare un'interfaccia di tunnel. Questo unico fatto cambia la storia della sicurezza: un processo con quel privilegio può reindirizzare il traffico dell'intera macchina, non solo quello di un'applicazione. Trattate il privilegio come parte del progetto e non come dettaglio di installazione.
Verificate quali regole ha installato lo strumento e che spariscono all'uscita. Una sessione che si blocca e lascia regole di intercettazione può mandare il traffico in un buco nero molto dopo che l'operatore crede che la connessione sia andata, e il sintomo sembra un guasto di rete e non una regola rimasta.
sudo sshuttle --method nft --dns 172.19.4.0/24
nft list ruleset | grep -i sshuttle
ip routeIl primo comando è la forma di una chiamata tipica, con il prefisso che vi serve davvero. Il secondo mostra cosa ha installato lo strumento, e il terzo conferma che non è apparsa alcuna interfaccia di tunnel, che è il risultato atteso per questo progetto.
Cosa esegue il lato remoto
Il lato remoto è un account SSH autorizzato più un ambiente assistente Python compatibile. Un accesso che riesce in una shell limitata non concede automaticamente il permesso di eseguire quell'assistente, e un account che può eseguire l'assistente non raggiunge automaticamente ogni servizio di destinazione. Entrambi i fatti appartengono alla richiesta di accesso e non alle note di risoluzione dei problemi.
Proteggete la verifica dell'identità dell'host e l'autenticazione dell'account. Accettare una chiave host sconosciuta per far funzionare la prima connessione elimina il controllo che il lato remoto sia la macchina che intendevate, e questo qui conta più che in un inoltro a scopo singolo.
Limitate l'account remoto ai servizi di cui ha bisogno il flusso di lavoro e negoziate quel perimetro con chi gestisce l'host. Fanno parte della relazione di fiducia, e nessuna impostazione lato client cambia questo.
Dove si trova il confine di fiducia
Inoltrare una connessione API privata tramite SSH non autorizza ogni operazione API. TLS dell'applicazione e accesso all'applicazione valgono ancora, e lo strumento non può rendere sicuro un servizio senza autenticazione. Anche un salto successivo dall'host remoto non è automaticamente lo stesso segmento protetto del canale SSH, perché quella seconda connessione segue qualunque politica abbia l'host remoto.
Scrivete il confine in una frase: il traffico verso questi prefissi esce da questo account su quell'host. Se la frase richiede un paragrafo di eccezioni, il progetto fa più di quanto dichiari la sua documentazione e merita un secondo sguardo prima di arrivare in produzione.
Provatelo per protocollo, poi scegliete lo strumento
Provate ogni protocollo necessario con una richiesta innocua, compreso il percorso del resolver e le famiglie di indirizzi che l'applicazione usa. Includete una disconnessione nella prova, così il comportamento di errore consentito dell'applicazione diventa un risultato noto e non una sorpresa durante un incidente. Una sessione che inoltrava correttamente mentre era attiva non dice nulla su cosa succede quando cade.
Per una manciata di servizi nominati esplicitamente, un inoltro locale ordinario è più facile da possedere e da verificare. Per il traffico delle applicazioni che si adatta al suo metodo, sshuttle offre una via di mezzo legittima. Quando il requisito è una connettività IP ampia, un progetto VPN è la risposta onesta, e la scelta segue la copertura e la responsabilità operativa e non una classifica degli algoritmi di cifratura.