Come impostare il tunneling SSH su un VPS

introduzione

In questo articolo imparerai come creare un tunnel sicuro e crittografato tra il tuo computer e il tuo VPS insieme a come aggirare i limiti in una rete aziendale, come aggirare il NAT, ecc.

Questo articolo coprirà alcune teorie di base, che puoi saltare se vuoi semplicemente andando direttamente agli esempi più in basso.

Comunicazione in Internet, protocolli di rete e porte di comunicazione

Ogni pezzo di software installato nel tuo computer, che vuole inviare o ricevere dati attraverso Internet, deve utilizzare un protocollo del livello dell'applicazione dallo stack TCP/IP. Tali protocolli definiscono un modo di comunicare e il formato dei messaggi inviati tra gli host su Internet, ecc. Ad esempio:

HTTP: utilizzato per scaricare siti Web e file dal tuo browser Web
FTP - utilizzato per inviare file tra un client e un server
DNS - utilizzato per modificare il nome host in un indirizzo IP e viceversa
POP3 e (o) IMAP - utilizzati per scaricare/navigare la tua posta elettronica
SMTP - utilizzato per inviare e-mail
telnet - utilizzato per connettersi in remoto a un server
SSH - simile a telnet, ma in una versione crittografata sicura, in modo che nessuno possa vedere cosa inviamo a un server e cosa il server ci invia.

Successivamente, i messaggi del protocollo specificato devono essere impacchettati in un segmento TCP o datagramma UDP (nel livello di trasporto). Questi protocolli vengono utilizzati per trasportare dati attraverso Internet: funzionano a livello di trasporto. Il protocollo TCP è orientato alla connessione, il che significa che prima di inviare dati è necessario creare una connessione tra le macchine remote. TCP fornisce sempre i dati nell'ordine corretto. Se un segmento andrà perso nella rete, verrà inviato nuovamente se non riceve la conferma in tempo. TCP è considerato abbastanza affidabile.

Il protocollo UDP non è orientato alla connessione. Non fornisce la ritrasmissione per i datagrammi persi. Se i pacchetti non vengono ricevuti nell'ordine corretto, UDP li fornirà comunque a un'applicazione nell'ordine in cui sono stati ricevuti. Per questo motivo, UDP viene utilizzato principalmente per trasmettere dati multimediali in tempo reale: conversazioni VoIP, videoconferenze, audio e video. L'UDP viene talvolta utilizzato da altri protocolli nel livello dell'applicazione, ad esempio nel caso del DNS.

In questo caso un protocollo di livello superiore deve inviare nuovamente una query dopo non aver ricevuto una risposta nel tempo specificato. UDP è utilizzato principalmente qui, perché ha un basso sovraccarico: l'invio di 1 piccola query in 1 datagramma e la ricezione di una risposta richiede meno tempo e deve trasmettere meno dati rispetto a una connessione TCP (scambio di 3 segmenti tra host): l'invio di una query da un client, inviando una conferma dal server, inviando una risposta dal server, quindi inviando una conferma da un client e disconnettendo la connessione (4 segmenti).

Per identificare connessioni diverse da e verso lo stesso indirizzo IP, utilizziamo i numeri di porta. Ogni server di un dato protocollo a livello di applicazione si collega a un dato numero di porta e attende una connessione in entrata. Il client si connette a questa porta (nel caso di una connessione TCP) o invia un datagramma a quella porta (nel caso di UDP). Per i protocolli più usati e conosciuti, ci sono numeri di porta riservati. Ad esempio, il server HTTP di solito è in ascolto sulla porta 80 TCP (in alternativa, i client dovrebbero connettersi ad esso specificando il numero di porta stesso in un indirizzo - http://example.org:1234/), il server DNS di solito è in ascolto sulla porta 53 UDP (a volte anche la porta 53 TCP). Anche il client deve utilizzare una porta su un lato. Sono \porte alte\ come 52044 e sono generate casualmente.

Qui puoi vedere più porte riservate che usiamo tutti i giorni.

I segmenti e i datagrammi vengono quindi impacchettati in pacchetti IP, nel livello di rete. Nei pacchetti, il computer di origine e quello di destinazione sono identificati da indirizzi IP. Sono globali: solo 1 host alla volta può utilizzare lo stesso indirizzo (esclusa una magia come NAT utilizzata nei router domestici con indirizzi IP privati: 192.168.x.x, 10.x.x.x, 172.16-31.x.x; x è un numero compreso tra 1 e 255). Sulla base di questi indirizzi, i router possono decidere come inviare il pacchetto per raggiungere il computer di destinazione.

I pacchetti vengono quindi impacchettati in frame/celle nel livello di collegamento dati e quindi trasmessi in un cavo o sotto forma di onde radio sulla rete locale. Nel livello di collegamento dati, nei frame, i computer sono identificati dai loro indirizzi MAC. I frame con indirizzi MAC vengono completamente eliminati dai router che ne estraggono i pacchetti. Decidono a quale rete inviare i pacchetti, li impacchettano in nuovi frame e li inviano per la loro strada. Se una rete tra entrambi i router utilizza indirizzi MAC, gli indirizzi di tali router sono inclusi nel frame: quello di origine e quello di destinazione. Non è possibile comunicare tra due computer in reti diverse utilizzando solo indirizzi MAC, anche se non sono duplicati: il produttore associa un solo indirizzo a una scheda, quindi qualsiasi carrello prodotto può avere lo stesso indirizzo MAC di una scheda prodotta da un altro produttore .

A proposito di SSH. Teoria, parte 1

SSH è un protocollo nel livello dell'applicazione. È il successore di telnet e viene utilizzato per connettersi al proprio VPS da remoto in modalità testo. A differenza di telnet, SSH è crittografato. Utilizza la porta 22 TCP, ma puoi facilmente modificare la porta nella configurazione dei tuoi server.

Per esempio:

utilizzando un nome utente e una password
usando una coppia di chiavi - prima una privata (top secret) e la seconda - pubblica (sul server): un programma che usi per connetterti con SSH deve risolvere un problema di matematica usando una chiave privata e inviare la soluzione al server. Il problema è diverso ogni volta, quindi è difficile decifrare la chiave utilizzando quel metodo di autenticazione.

Al giorno d'oggi usiamo la versione 2 di SSH.

L'implementazione del server SSH più popolare è OpenSSH. I client più popolari sono PuTTY (per Windows) e OpenSSH (per Linux). Sia PuTTY che OpenSHH consentono agli utenti di creare tunnel.

SSH consente agli utenti di creare un tunnel TCP tra il server e il client e di inviare dati attraverso quel tunnel. SSH supporta solo i tunnel TCP, ma puoi aggirare il problema, ad esempio tramite un proxy SOCKS. Un tunnel come quello viene stabilito tra una porta TCP scelta sul server e una porta locale scelta. Non è crittografato, ovviamente, quindi chiunque può controllare per cosa lo usiamo.

Concetti che verranno utilizzati

Interfaccia di loopback - una scheda di rete virtuale installata nel sistema con l'indirizzo IP 127.0.0.1. Solo le applicazioni installate sul sistema hanno accesso a tale indirizzo. L'accesso remoto non è possibile. Puoi avviare un VPS su quell'interfaccia e avere accesso remoto solo dallo stesso sistema o tramite tunnel.

SMTP - un protocollo a livello di applicazione che consente di inviare e-mail. Viene utilizzato sia per la comunicazione tra server di posta che per la comunicazione tra un server e un client di posta. SMTP utilizza la porta 25 TCP per la comunicazione non crittografata e la porta 587 TCP o 465 TCP (deprecata - non consigliata) per una connessione crittografata (SSL).

POP3 - protocollo nel livello dell'applicazione utilizzato per scaricare nuove e-mail da un server al client di posta locale. Al giorno d'oggi è usato raramente poiché è stato sostituito da IMAP. Per le connessioni non crittografate utilizza la porta 110 TCP, per le connessioni crittografate - porta 995 TCP.

IMAP - un protocollo simile a POP3, ma con supporto per cartelle, etichette, lettura e gestione di messaggi e cartelle sul server senza scaricare tutto sul PC locale ed eliminarlo dal server. IMAP utilizza la porta 143 TCP per le connessioni non crittografate e la porta 993 TCP per le connessioni crittografate.

Esempio 1: Tunnel verso un server IMAP

Un tunnel tra la porta locale 143 sull'interfaccia di loopback - 127.0.0.1 - e il server IMAP per la ricezione della posta (connessione non crittografata) sulla stessa macchina remota.

Unix e OpenSSH:

ssh abc@def -L 110:127.0.0.1:110
 
abc - username on server
def - server address
110: - local port that will be opened on loopback interface (127.0.0.1) on local machine
127.0.0.1 - IP address of computer that we creating a tunnel to via our SSH tunnel
:110 - port number of target machine we'll get to via tunnel

Windows e PuTTY:

Ora puoi semplicemente configurare il tuo client di posta per connettersi al VPS non direttamente, ma utilizzando la porta 110 dell'interfaccia di loopback - 127.0.0.1. Puoi fare la stessa cosa con diversi protocolli: SMTP (25), IMAP (143), ecc.

Esempio 2. Tunnel a un server Web

Un tunnel tra la porta locale 8080 sull'interfaccia locale (127.0.0.1) e il server WWW, collegato alla porta 80 di una macchina remota. Questa volta ci collegheremo utilizzando l'interfaccia di loopback.

Come ho detto prima, il protocollo HTTP viene utilizzato per scaricare i siti Web WWW nel browser.

Unix e OpenSSH:

ssh abc@def -L 8080:11.22.33.44:80
 
    abc - username on server
    def - server address
    8080: - port on the local machine that will be opened on loopback interface (127.0.0.1)
    11.22.33.44 - IP address of the server that we'll create a tunnel to using SSH

Windows e PuTTY:

Teoricamente parlando, dopo essere andato su 127.0.0.1:8080 nel tuo browser, dovresti vedere un sito web situato sul server remoto a cui ci siamo connessi.

In pratica, HTTP 1.1 ha introdotto il parametro Host nelle query. Questo parametro viene utilizzato per inviare il nome di dominio DNS del VPS a cui ci si connette. Se utilizza il meccanismo dell'host virtuale, la pagina che otterrai sarà una pagina di errore o la pagina principale del server, ma non attraverso il tunnel.

In questo caso, dobbiamo fare ancora una cosa: nel file hosts sul PC locale, aggiungi l'indirizzo VPS e la tua interfaccia di loopback:

127.0.0.1 website

website è l'indirizzo del sito a cui vuoi connetterti (senza http:// all'inizio e / alla fine).

Il file Hosts si trova in /etc/hosts (Linux) o C:\Windows\system32\drivers\etc\hosts (Windows). Per modificare questo file, devi essere un amministratore o disporre di privilegi amministrativi.

Importante! Se si desidera creare un tunnel su una porta locale numerata inferiore a 1024 su sistemi Unix, è necessario disporre dei privilegi di root.

Esempio 3. Proxy SOCKS

Un proxy SOCKS ti consente di inviare traffico da qualsiasi protocollo attraverso un tunnel. Sembra, dall'esterno, come una singola connessione TCP.

In questo esempio, creeremo un tunnel tra un server SSH e un client sulla porta 5555 sull'interfaccia di loopback. Successivamente, imposteremo il nostro browser per utilizzare il nostro server SOCKS come server proxy per tutte le connessioni in uscita.

Questa soluzione potrebbe essere utile per aggirare le restrizioni sulle reti aziendali. Se la porta utilizzata dal nostro SSH è bloccata, possiamo dire al server di restare in ascolto sulla porta 443 utilizzando l'opzione Ascolta nel file di configurazione di OpenSSH (/etc/ssh/sshd_config o /etc/openssh/sshd_config ).

Unix e OpenSSH:

ssh abc@def -D 5555
 
    abc - username
    def - server address
    5555 - local port number, where the tunnel will be created

Windows e PuTTY:

Nelle impostazioni del tuo browser, imposta un proxy SOCKS che funzioni su 127.0.0.1:5555, da ora fino a quando non chiudi la connessione in PuTTY o OpenSSH.

Esempio 4. Bypassare NAT

NAT (in particolare PAT, che è la forma NAT utilizzata nei router domestici) è un meccanismo che consente a molte persone di utilizzare una connessione Internet. Un router che utilizza NAT ha un indirizzo pubblico e modifica tutti gli indirizzi privati nei pacchetti ricevuti dalla rete interna al proprio indirizzo pubblico e li invia a Internet. Dopo aver ricevuto i pacchetti, fa il contrario: ricorda gli indirizzi IP e i numeri di porta in una speciale tabella NAT.

Una connessione dall'esterno è possibile solo quando impostiamo il port forwarding appropriato sul router. Tuttavia, possiamo aggirare questo problema e creare un tunnel tra il nostro computer e il server per connettere direttamente il nostro computer e il nostro server.

Parte 1.

Nella seconda parte, creeremo un tunnel tra la porta locale 80 (sul nostro computer - il server HTTP locale) e la porta 8080 sul server remoto. Tuttavia, per motivi di sicurezza, la porta remota 8080 verrà aperta solo sull'interfaccia di loopback del VPS - 127.0.0.1. Per questo motivo, dobbiamo riconfigurare il nostro server per aprire le connessioni su ogni porta. Bene, fallo ora.

In your favorite editor, open the /etc/ssh/sshd_config (or /etc/openssh/sshd_config) file as root.
```
nano /etc/ssh/sshd_config
```
Find:
```
#GatewayPorts no
```
Change that line to:
```
GatewayPorts yes
```
Save the file and close the editor.

Restart SSHD server:

Debian/Ubuntu: service ssh restart

CentOS: /etc/init.d/sshd restart

Parte 2.

In questa sezione, creeremo il tunnel.

Unix e OpenSSH:

ssh abc@def -R 8080:127.0.0.1:80
 
    abc - username
    def - server address
    8080 - port number that will be opened on remote server - our proxy server
    127.0.0.1 - IP address we open tunnel to
    80 - port number we open tunnel to

Questa volta il nostro tunnel è locale, ma possiamo stabilire una connessione tramite tunnel ad altri computer nella stessa rete utilizzando NAT.

Windows e PuTTY:

Dopo aver effettuato l'accesso, possiamo accedere al nostro server HTTP locale dall'esterno della nostra rete tramite un server proxy OpenSSH con un indirizzo IP pubblico. Apri quanto segue in un browser:

http://IP-address-or-domain-of-our-server-change-that-for-your-name:8080/

Teoria continua

Come puoi vedere, ci sono tre tipi di tunnel SSH:

Locale - opzione -L - un tunnel viene aperto sulla nostra porta locale e ascolta le connessioni che vengono reindirizzate prima alla nostra connessione salvata al server SSH e accanto all'host di destinazione.
Remoto - opzione -R - viene aperto un tunnel sul server SSH. Dopo aver ricevuto una connessione dal server, tutte le trasmissioni vengono reindirizzate fuori dal nostro tunnel locale.
Dinamico - opzione -D - viene aperto un tunnel su un'interfaccia di loopback locale. La trasmissione avviene attraverso il protocollo SOCKS. Puoi eseguire il tunneling di qualsiasi pacchetto attraverso questo: TCP, UDP. È possibile connettersi a qualsiasi server su Internet tramite un server proxy SSH. Per reindirizzare tutto il traffico di sistema attraverso il proxy SOCKS, puoi utilizzare un programma come proxifier.