Una porta OpenVPN, tre servizi: perché contano le porte interne

Una sessione SSH, un'applicazione web e una risoluzione di nome possono condividere un'unica connessione VPN senza litigare per le porte. Il client costruisce un unico flusso cifrato verso il gateway, e ogni conversazione applicativa viaggia al suo interno. All'esterno si vedono solo il trasporto e la porta propri del tunnel. All'interno ogni servizio mantiene la propria porta e ha ancora bisogno della propria autorizzazione.

Cosa trasporta il flusso esterno e cosa nasconde

Il client incapsula ogni pacchetto nel trasporto del tunnel prima che lasci la macchina. Quel flusso esterno ha un'unica porta di destinazione, fissata quando è stata configurata la VPN. Dentro l'involucro, ogni pacchetto originale conserva l'indirizzo e la porta del servizio a cui è diretto. Il gateway rimuove l'involucro e instrada in base all'intestazione interna, così la destinazione vede un client ordinario che arriva dalla rete.

Una cattura sull'interfaccia WAN mostra quindi una conversazione, non tre. Le porte interne compaiono solo dopo la decapsulazione. Ecco perché una sola apertura del firewall può trasportare SSH, HTTPS e DNS contemporaneamente.

# WAN side: one outer tuple, whatever the inner services are
tcpdump -ni wan0 'udp port 443'
# tunnel side: the inner tuples appear after decapsulation
tcpdump -ni tun0

La documentazione TUN/TAP tratta il passaggio in cui un dispositivo TUN instradato trasferisce pacchetti IP tra il kernel e un processo nello spazio utente. È quel passaggio a rendere visibile l'intestazione interna al codice di instradamento e del firewall del gateway. Spiega anche perché la porta esterna non dice nulla su quali servizi siano consentiti.

L'inoltro NAT appartiene al listener, non alle applicazioni

Un gateway auto-ospitato dietro un NAT IPv4 necessita di un'unica traduzione in ingresso: l'indirizzo e la porta pubblici mappati sul listener VPN. Non serve alcuna regola per SSH, HTTPS o DNS solo perché gli utenti del tunnel li raggiungono. Pubblicare quelle porte esporrebbe servizi che il tunnel già protegge. La regola di inoltro descrive la raggiungibilità del listener, non un permesso per qualcosa all'interno.

Vale anche il contrario. Aprire la porta del tunnel non espone nient'altro, quindi un servizio raggiungibile solo attraverso il tunnel mantiene chiusa la sua superficie pubblica. Questa separazione è di solito proprio il motivo per cui il servizio resta privato.

È la politica interna a decidere davvero l'accesso

La cifratura protegge il percorso; non autorizza una destinazione. Le rotte del client scelgono quali prefissi entrano nel tunnel, la politica di inoltro del gateway decide se i pacchetti possono uscirne, e il firewall della destinazione più l'accesso decidono se il servizio risponde. Il DNS è il caso più chiaro: trasportare le query non fa sì che un resolver le accetti dal vostro pool di client. Ogni livello può dire no in modo indipendente.

Provate ogni servizio separatamente attraverso il tunnel. Una risoluzione riuscita non dice nulla sulla porta web, e una richiesta web riuscita non dice nulla su SSH.

dig @10.40.0.53 app.corp.example
nc -vz 10.40.0.10 8443
ssh -p 2222 [email protected]

Quando il tunnel è attivo e tutto fallisce, leggete prima la tabella di routing del client. Quando un servizio fallisce mentre gli altri funzionano, il guasto è su quella destinazione. Queste due osservazioni indicano responsabili diversi, e mescolarle fa perdere tempo.

WireGuard traccia la stessa linea

WireGuard chiama il suo listener esterno con ListenPort, e un'applicazione interna usa ancora la porta di servizio di cui ha bisogno. AllowedIPs è un insieme di prefissi instradati, non un elenco di porte di servizio consentite. Leggerlo come una lista di autorizzazione delle porte produce regole che non corrispondono a ciò che fa il tunnel. La denominazione è diversa; la stratificazione no.

Consentite il servizio nella politica di input locale quando gira sull'endpoint stesso, o nella politica di inoltro quando si trova dietro quell'endpoint. La distinzione decide quale insieme di regole vede il pacchetto.

La forma generale è un trasporto esterno con molte conversazioni interne. I prodotti che richiedono più scambi esterni, o un protocollo IP diverso, ricordano che lo schema a porta pubblica unica descrive questo progetto e non ogni VPN.