Raggiungere una workstation dietro NAT senza inoltro di porta

Due estremità dietro il NAT dell’operatore e un router d’ufficio bloccato non lasciano alcuna porta in ingresso da inoltrare, e il riflesso è chiederne comunque una. La domanda migliore è quale lato può chiamare verso l’esterno e quale servizio raggiungibile è autorizzato a portare il traffico. Quattro progetti rispondono diversamente a questa domanda e falliscono in modi diversi quando un percorso viene bloccato. Scegliere tra loro è un confronto di garanzie, non di nomi di protocolli.

Quattro progetti, quattro promesse diverse

La tabella qui sotto è la versione breve. Leggete la colonna centrale come la promessa che potete verificare e la colonna di destra come la promessa che nessuno ha fatto.

Quale riga si applica dipende dal compito e non dalla preferenza. Una sessione di desktop remoto, una shell amministrativa e l’accesso a un’intera sottorete privata sono tre requisiti che non hanno bisogno dello stesso punto d’ingresso, anche quando riguardano per caso la stessa macchina.

Un concentratore cambia chi chiama verso l’esterno, non ciò che è consentito

In un progetto con concentratore instradato, il portatile remoto e la workstation, o il gateway del sito davanti a essa, aprono ciascuno un tunnel in uscita verso un servizio che entrambi possono raggiungere. Nulla accetta una connessione non richiesta sul router della workstation, ed è esattamente per questo che questo progetto sopravvive al NAT e funziona anche quando il sito non ha un indirizzo statico. Il concentratore instrada poi il traffico tra i due indirizzi interni secondo la propria politica.

Il costo è che il concentratore deve esistere, essere raggiungibile da entrambi i lati ed essere gestito da qualcuno. Il filtraggio in uscita deve consentire il trasporto, e una rete che lo blocca farà fallire il progetto anche se non serviva alcun inoltro di porta.

Il punto sottile è che raggiungibilità e autorizzazione sono decisioni separate prese in luoghi diversi. Una rotta verso un prefisso non dice nulla su quale servizio della workstation l’identità possa usare, e una regola del firewall che consente il tunnel non dice nulla sulla possibilità dell’account di accedere. Configurate entrambe, provate entrambe e tenete la decisione di autorizzazione presso il sistema che possiede la risorsa, non presso la tabella di routing.

L’attraversamento funziona solo se entrambe le pile lo implementano

L’attraversamento tra pari è una capacità di un sistema specifico, non un’impostazione che migliora una VPN. Interactive Connectivity Establishment raccoglie diversi indirizzi candidati e prova coppie finché una funziona: candidati host sulle interfacce locali, candidati riflessivi del server costruiti da ciò che un NAT rivela e candidati inoltrati assegnati su un relè. Un indirizzo privato da solo non è un percorso, perché l’altro lato non può instradare verso di esso.

Vale la pena capire il caso inoltrato prima di scartarlo. RFC 8656 descrive TURN come un protocollo in cui un client chiede a un server un indirizzo di trasporto inoltrato e il server inoltra il traffico tra quel client e i suoi pari. Il relè porta quindi i dati, il che è materialmente diverso da una directory che aiuta solo le estremità a incontrarsi. Scambiare l’indirizzo del relè con l’altro lato è un passo di coordinamento che l’applicazione deve compiere.

Ciò che non potete promettere è un percorso diretto. Il NAT simmetrico e alcuni firewall aziendali sconfiggono la perforazione dei fori, e quando ciò accade il sistema o ripiega su un relè o fallisce. Non potete nemmeno concludere che due estremità tradotte non potranno mai parlarsi; una pila supportata con ripiego su relè esiste proprio perché spesso possono. Decidete se conta di più la disponibilità o la direttezza, poi verificate quale percorso ha scelto davvero la distribuzione invece di presumere il caso favorevole.

Un broker è più stretto di una rete

Quando il requisito è una sola applicazione, un broker di applicazioni o una connessione inversa avviata dalla workstation possono essere la risposta più piccola. La workstation chiama verso l’esterno un broker, il broker autentica l’utente remoto e viene trasportata solo quella sessione applicativa. Non viene creata alcuna rotta verso la sottorete della workstation, quindi una compromissione della sessione remota non eredita un percorso verso ogni dispositivo accanto.

Questa strettezza ha un prezzo: ogni applicazione aggiuntiva richiede la propria integrazione, e tutto ciò che l’applicazione presume di una rete locale, come una condivisione di file che apre su un server vicino, potrebbe non essere raggiungibile. I broker concentrano anche politica e registrazione in un solo punto, il che è utile finché quel punto diventa l’interruzione.

Confrontate i confini di fiducia, poi provate il percorso

Un concentratore che termina i tunnel può leggere il traffico che instrada. Un relè può portare uno scambio protetto in modo indipendente quando l’applicazione cifra da un capo all’altro, e un broker di solito termina la sessione che presenta. Stabilite dove finisce davvero la protezione prima di decidere che due progetti sono equivalenti perché entrambi sono cifrati.

Poi controllate a cosa riesce ad arrivare davvero la workstation in uscita, dato che ogni progetto sopra dipende da questo. Eseguitelo sulla workstation, sostituendo il nome host che intendete usare.

ss -lntup
nc -vz hub.example.com 443
curl -sS -o /dev/null -w "%{http_code}\n" https://hub.example.com

Accettate il progetto solo dopo che l’operazione remota prevista riesce con l’identità consentita, un’identità non approvata viene rifiutata e il comportamento quando il percorso diretto o inoltrato non è disponibile è noto e documentato. Includete una riconnessione e il contesto di avvio normale della workstation, perché una sessione iniziata in ufficio via LAN non verifica nulla di ciò da cui dipende l’accesso remoto.