Inoltro locale SSH verso un proxy HTTP esistente: due indirizzi di loopback

Il tuo proxy approvato gira su un host di salto dove ascolta solo su loopback, quindi nulla fuori da quella macchina può raggiungerlo. Non ti servono una VPN né un nuovo proxy; ti serve una porta di quella macchina trasportata su una porta tua. Un inoltro locale fa esattamente questo, e richiede un comando più un’impostazione dell’applicazione. La confusione di solito nasce dal confondere quale indirizzo di loopback appartiene a quale macchina.

Decidi se esiste già un proxy fisso

Questa tecnica inoltra un servizio che è già in esecuzione. Se l’host remoto ha solo un demone SSH e nessun proxy, nessuna quantità di inoltro ne creerà uno, e la connessione verrà rifiutata dal lato remoto. Verifica che il proxy sia associato, qual è la sua porta e se ascolta su 127.0.0.1 o su un indirizzo di interfaccia specifico, perché è quell’indirizzo che l’inoltro deve puntare.

Verificarlo subito ti risparmia il debug di un tunnel che non è mai stato collegato a nulla.

Costruisci l’inoltro e leggi il comando

La forma che vuoi associa una porta di loopback sul tuo portatile e la collega, dal lato del server, all’indirizzo del proxy come lo vede il server.

ssh -NT -o ControlPath=none -o ExitOnForwardFailure=yes \
  -L 127.0.0.1:13128:127.0.0.1:3128 [email protected]

-N sopprime un comando remoto e -T sopprime l’assegnazione di termios, perché vuoi un tunnel e non una shell. Il primo indirizzo di loopback è dove ascolta il portatile; il secondo viene risolto dal server SSH, quindi 127.0.0.1 lì significa il proxy su quella macchina. ExitOnForwardFailure fa fallire rumorosamente il comando se la porta locale è già occupata, invece di avviare una sessione che non inoltra nulla. Scrivi l’indirizzo di destinazione come lo risolve il server, perché un nome che solo il tuo portatile può risolvere fallirà dall’altra parte.

La politica del server stesso si applica prima che qualcosa di tutto ciò funzioni. AllowTcpForwarding deve consentirlo, e PermitOpen può limitare quali destinazioni e porte una sessione può raggiungere, quindi un inoltro che il client accetta può comunque essere rifiutato dal server. Il rifiuto appare come un errore di inoltro o di canale sul client, e leggere quel messaggio è più veloce che modificare il comando.

Punta un’applicazione sull’inoltro

Configura l’applicazione per usare un proxy HTTP su http://127.0.0.1:13128, con credenziali se il proxy remoto le richiede. Mantieni la verifica dei certificati propria dell’applicazione per le destinazioni HTTPS, dato che il tunnel del proxy non la sostituisce. Questo è un inoltro fisso di un solo servizio, quindi all’applicazione va detto che esiste un proxy invece di lasciarla scoprirlo.

Una verifica rapida prima di configurare qualcosa di permanente: curl -x http://127.0.0.1:13128 -I https://example.com, che esercita il metodo HTTP CONNECT che il proxy deve supportare.

Mantieni l’autorità dove era

Il proxy remoto decide ancora quali destinazioni e metodi permette, e un accesso SSH non dovrebbe concedere silenziosamente un relè web generale a ogni account. L’associazione a 127.0.0.1 sul portatile evita di pubblicare la porta sulla tua rete locale, e non rende la porta privata rispetto ad altri processi sulla stessa macchina. Sostituire quell’associazione con un indirizzo wildcard per condividere il proxy è il modo in cui nasce un relè aperto non gestito.

Il trasporto SSH protegge il salto verso il server. Oltre quel punto il proxy apre la propria connessione, quindi una richiesta HTTP semplice verso una destinazione resta semplice oltre il server, anche se il primo tratto era cifrato.

Verifica entrambi i capi, poi pulisci

L’installazione del tunnel locale e il successo del servizio remoto sono risultati diversi, e lo stato di uscita del comando ti dice solo del primo. Controlla che l’ascoltatore esista con ss -ltn, poi fai una richiesta consentita dell’applicazione e una richiesta che il proxy dovrebbe rifiutare. Se entrambi si comportano come previsto, il percorso è reale; se il tunnel è attivo e ogni richiesta fallisce, il proxy sta rifiutando o non riesce a raggiungere la destinazione.

Quando hai finito, ferma il processo SSH che lo possiede, rimuovi l’impostazione del proxy dall’applicazione e conferma che la porta locale è sparita invece di lasciare un ascoltatore che sopravvive al compito.