Date a un Pi remoto un proxy SOCKS tramite il vostro client SSH

Date per scontato che un proxy SOCKS debba girare dove l'accesso alla rete esiste già. OpenSSH può collocare l'ascoltatore altrove del tutto. Un inoltro dinamico remoto apre la porta SOCKS su un host remoto e origina ogni connessione dal vostro client SSH locale, che porta il percorso VPN approvato del portatile. Il Pi ottiene un proxy circoscritto; non eredita il vostro tunnel né i vostri privilegi.

L'ascoltatore e il lato da cui nasce la connessione possono essere diversi

Un ssh -D 1080 ordinario esegue l'ascoltatore sulla vostra macchina e invia le connessioni da lì. Un inoltro dinamico remoto lo rovescia: l'ascoltatore compare sull'host remoto e ogni connessione che accetta viene aperta dal lato locale. Il manuale del client OpenSSH documenta -R senza una destinazione fissa esattamente come questa disposizione SOCKS4/5.

Un comando supportato dal portatile si presenta così, con l'account, gli host e la porta trattati come segnaposto:

ssh -NT -S none -o ExitOnForwardFailure=yes \
  -o PermitRemoteOpen=app.corp.example:443 \
  -R 1080 [email protected]

Tre dettagli fanno lì un lavoro utile. -S none tiene la sessione lontana da un master di controllo condiviso, ExitOnForwardFailure fallisce subito invece di lasciarvi con una sessione semiaperta, e PermitRemoteOpen limita ciò che l'ascoltatore remoto può raggiungere. Usate un account Pi autorizzato e verificate la chiave dell'host prima di aggiungere qualcosa di tutto questo.

Che cosa espone davvero l'ascoltatore remoto

Controllate la politica di inoltro del server prima di affidarvi all'ascoltatore. Con GatewayPorts no l'inoltro remoto resta legato al loopback, ed è l'esposizione che volete. Un server configurato per forzare l'inoltro con caratteri jolly pubblica la stessa porta su ogni interfaccia, il che trasforma un proxy personale in qualcosa che la rete locale può raggiungere.

Anche il loopback non è un confine per utente. Un altro processo sul Pi può connettersi a 127.0.0.1:1080 se conosce la porta, quindi gli account locali del Pi e tutto ciò che vi gira fanno parte del vostro progetto di accesso. Questo è un motivo per tenere stretta la lista delle destinazioni, non un motivo per saltare il controllo della politica.

Tenete la destinazione consentita specifica per l'applicazione che cercate di raggiungere. Sostituirla con un inoltro senza restrizioni per far funzionare un programma estraneo allarga il percorso ben oltre il problema da cui siete partiti. Una lista di destinazioni registra anche a cosa serviva la sessione, il che aiuta chi la verificherà più tardi. Annotatela accanto all'account che avete usato.

Fate passare un'applicazione dal proxy:

Un client consapevole del proxy sul Pi può quindi fare la richiesta. Il prefisso socks5h consegna il nome di destinazione al proxy, così la risoluzione e la connessione avvengono entrambe dal lato del portatile, e corrisponde alla destinazione nominata in PermitRemoteOpen:

curl --proxy socks5h://127.0.0.1:1080 \
  --noproxy '' https://app.corp.example/

Mantenete la normale convalida dei certificati e l'autenticazione propria dell'applicazione. Il proxy cambia dove viene stabilita la connessione TCP; non rende sicuro un servizio senza autenticazione e non trasforma un endpoint autofirmato in uno attendibile.

Il portatile ha ancora bisogno della propria rotta e dell'accesso al resolver sia verso il server SSH sia verso l'applicazione. Il traffico del suo client SSH deve essere selezionato dalla politica VPN approvata, e un'esclusione split-tunnel può inviare quel traffico su un percorso diverso da quello che avete provato.

Dimostrate il percorso e chiudetelo

Confermate che l'ascoltatore esiste dove lo aspettate e che risponde solo la destinazione prevista:

$ ss -ltnp | grep 1080
LISTEN 0 128 127.0.0.1:1080 0.0.0.0:*
$ curl -sS -o /dev/null -w '%{http_code}\n' \
    --proxy socks5h://127.0.0.1:1080 https://app.corp.example/

ExitOnForwardFailure può dimostrare che l'inoltro è stato stabilito, e tuttavia non può certificare che l'accesso all'applicazione riesca a valle. Provate l'applicazione, non solo la porta. Un ascoltatore che accetta e poi fa fallire ogni richiesta di solito significa che il nome di destinazione o la rotta del portatile sono sbagliati, non che il tunnel abbia fallito.

Questa disposizione trasporta solo TCP. UDP, ICMP e i programmi che ignorano le impostazioni del proxy restano fuori, e l'inoltro finisce nel momento in cui finisce la sessione SSH. Fermate quella sessione quando avete finito e togliete l'impostazione del proxy che avete aggiunto all'applicazione.

Per un accesso permanente, usate invece l'iscrizione supportata dal proprietario della rete o un gateway gestito. Un proxy inverso è lo strumento sbagliato per eludere le restrizioni di dispositivo o di risorse di una VPN; usato al loro interno, è semplicemente un percorso applicativo autorizzato con limiti espliciti.