Perché molte connessioni delle applicazioni condividono un’unica sessione OpenVPN

Immaginate un browser che carica una pagina HTTPS mentre un client SSH raggiunge un altro server e un resolver risponde a una query, tutto attraverso un’unica sessione OpenVPN. Sull’interfaccia fisica vedete una conversazione; dentro il tunnel ne vedete tre. Entrambe le viste sono corrette, e sapere perché è la differenza tra una cattura utile e una confusa. Seguite un flusso interno dal socket al cavo e la stratificazione smette di essere astratta.

Una conversazione esterna, molti flussi interni

Ogni applicazione apre il proprio socket, e il kernel le assegna una quintupla composta da indirizzo di origine, porta di origine, indirizzo di destinazione, porta di destinazione e protocollo. Queste quintuple esistono prima che entri in gioco qualsiasi tunnel. Poi l’instradamento decide che escono tutte dal dispositivo tunnel, quindi il pacchetto consegnato a OpenVPN porta ancora le intestazioni originali al suo interno. OpenVPN cifra quel pacchetto interno e avvolge il risultato in un’unica conversazione UDP o TCP esterna con il peer. La conversazione esterna è quindi una, mentre i flussi al suo interno sono tanti quante le applicazioni aperte.

Niente collassa. Le quintuple interne sopravvivono da un capo all’altro, ed è per questo che il lato remoto distingue ancora i tre flussi.

La porta che resta fissa

Ciò che resta costante è la quintupla esterna: il vostro indirizzo, la porta locale che il client ha legato, l’indirizzo del peer e la porta di servizio configurata. È quella quintupla che un firewall o un NAT sul percorso deve consentire, ed è quella che mostrerà una cattura sul collegamento in uscita. È anche quella che cambia dopo una riconnessione o un cambio di rete, perché il client può legare una porta locale diversa. Un tunnel non implica una porta di origine fissa per sempre.

Sono le porte interne che interessano agli estremi. Un flusso HTTPS mantiene la porta di destinazione 443 dentro il tunnel anche se il trasporto esterno siede sulla porta configurata dall’operatore. Gli estremi dell’applicazione non vengono mai a conoscenza di quella esterna.

Che cosa cambia la decapsulazione all’estremo remoto

Presso il peer lo strato esterno viene rimosso, e ciò che resta è il pacchetto interno. Da lì in poi l’inoltro e la politica di accesso si applicano alla destinazione e al protocollo interni. Il server web riceve ancora una connessione HTTPS, il demone SSH riceve ancora SSH e il resolver riceve ancora una query.

Per questo una regola che consente il trasporto esterno non è la stessa regola che consente un servizio interno. La prima descrive un percorso; la seconda descrive un’autorizzazione.

Un TCP esterno significa un solo flusso, non una sola connessione

Quando il trasporto esterno è UDP, il destino di ogni flusso interno è indipendente: un datagramma perso influisce su un trasferimento fino alla sua ritrasmissione. Quando il trasporto esterno è TCP, tutti i flussi interni condividono un unico flusso di byte affidabile.

Quel flusso condiviso è la parte che le persone trascurano. Il ripristino avviene una volta sola, per tutto, quindi un singolo segmento perso ritarda il traffico di ogni applicazione multiplexata al suo interno. Restano molte connessioni agli estremi e una sola connessione sul cavo, ed è sul cavo che vive l’effetto testa di riga. Il numero di porte in ascolto non vi dice nulla su questo, ed è per questo che contare le porte è un modo scadente di ragionare sulle prestazioni di un tunnel.

Descrivete la vostra configurazione con precisione

Nominate il traffico interno selezionato e il trasporto esterno specifico che lo trasporta, invece di dire che la macchina manda tutto su un’unica porta. I servizi locali, un secondo tunnel e l’altra famiglia di indirizzi creano tutti flussi che non entrano mai in questa conversazione. Una cattura sul collegamento in uscita mostra la quintupla esterna; una cattura dentro il tunnel mostra quelle interne.

Prendetele entrambe e mettete i timestamp uno accanto all’altro. Se dovete dimostrare quale applicazione ha generato quale flusso interno, la tabella dei socket sull’host è lo strumento migliore, perché associa direttamente le porte ai processi. Poi annotate la quintupla esterna che avete osservato e il momento in cui l’avete osservata, perché la cattura successiva dopo una riconnessione può legittimamente mostrare numeri diversi.