Quando un client di accesso remoto deve agire come gateway di sede

Un portatile connesso a una VPN può raggiungere la sede centrale. La stampante e il file server sulla stessa scrivania non possono, perché nulla inoltra i loro pacchetti in quel tunnel né riporta indietro le risposte. Trasformare il client in un gateway di sede è una decisione di routing e di responsabilità prima che di configurazione. Il nome del protocollo sulla confezione non risponde se quel ruolo è supportato.

Cosa non vi dice l’etichetta del protocollo

OpenVPN documenta un progetto da sede a sede in cui un connettore inoltra un’intera sottorete, e Access Server lo implementa con un ruolo di gateway e routing esplicito. Un altro prodotto commercializzato come VPN SSL può esporre solo funzioni per utenti remoti, senza alcun modo supportato di annunciare una rete dietro il client. Anche la versione conta, perché una funzione presente in un’edizione non è una promessa su un’altra. Leggete l’implementazione che eseguite davvero e trattate una ricetta scritta per un altro prodotto come un indizio, non come un progetto.

La domanda da risolvere per prima è se il proprietario della VPN supporti il ruolo di inoltro. Se no, nessun routing lato client lo rende supportato.

Il contratto ha due lati: sede e sede centrale

Dal lato della sede, un solo host possiede inoltro, filtraggio e ripristino. Ha bisogno di un percorso deliberato da ogni dispositivo della sede, e la connessione VPN esterna deve restare raggiungibile attraverso la rete sottostante anche quando il tunnel è inattivo. Dal lato della sede centrale, qualcuno deve definire la sottorete della sede, accettare l’identità del gateway e consentire risorse specifiche. Nessuna metà funziona da sola.

Il percorso di ritorno è la parte che viene saltata. Un indirizzo di tunnel per il client non annuncia la sottorete che sta dietro, quindi i router della sede centrale hanno bisogno di una rotta che punti al gateway VPN per quel prefisso.

In un progetto instradato, il concentratore inoltra i pacchetti del prefisso della sede e il routing della LAN superiore sa come rispedire le risposte. In un progetto tradotto, la sorgente che la sede centrale vede viene riscritta, il che può eliminare la necessità di una rotta di ritorno mentre nasconde quale macchina della sede ha inviato il traffico. Quel compromesso appartiene al documento di progetto, perché i log delle applicazioni e le regole di accesso perdono l’identità per dispositivo non appena entra in gioco la traduzione.

Instradato o tradotto: scegliete il percorso di ritorno consapevolmente

Scegliete instradato quando contano l’identità per dispositivo e la politica per host e potete mantenere la rotta di ritorno su ogni router rilevante.

Scegliete tradotto quando non potete aggiungere rotte ma accettate che la sede centrale veda un solo indirizzo di origine. Esistono progetti misti e sono più difficili da ragionare, quindi annotate quali prefissi sono instradati e quali tradotti. Poi verificate la scelta con una cattura su entrambe le estremità invece di fidarvi dello stato del tunnel.

Un controllo utile è asimmetrico: richiedete una risorsa da un dispositivo della sede, poi confermate che la risposta lasci la sede centrale verso il prefisso della sede. traceroute -n 10.60.4.20 da un host della sede centrale mostra se quel percorso passa dal gateway VPN.

Gestitelo come infrastruttura, non come un accesso

Decidete come il gateway si avvia, si autentica, si aggiorna e si ripristina senza nessuno connesso. Il rinnovo delle credenziali, le richieste multifattoriali, il comportamento in sospensione e chi risponde quando la sede perde l’accesso diventano tutti questioni operative. Più persone che condividono un percorso di rete non devono ereditare i privilegi personali dell’utente del gateway, quindi l’autorizzazione delle risorse, l’ambito della registrazione e la politica di guasto hanno bisogno di un proprietario nominato. Condividere un account per evitare l’iscrizione di ogni dispositivo non è un progetto.

Confrontate la soluzione con un gateway di sede supportato con gli stessi requisiti prima di impegnarvi. Riusare un vecchio desktop non elimina la manutenzione né il ripristino, e il prezzo dell’usato non descrive il costo operativo.

Validate le applicazioni della sede previste, il loro traffico di ritorno e una destinazione negata nell’ambito di un piano approvato. Il successo somiglia a un servizio di rete posseduto con un’identità di sede nominata e una politica esplicita, non a una finestra del client che dice Connesso.