Un client VPN in roaming può ospitare un servizio per l'ufficio?

Il portatile dell'ufficio può collegarsi da casa e comunque fornire qualcosa di cui l'ufficio ha bisogno, ma solo quando tre decisioni separate coincidono. Il tunnel è trasporto, l'indirizzo interno è la destinazione e la policy decide chi può bussare. Trattare una di queste come la risposta completa produce la solita lamentela: l'host risponde ai ping ma l'applicazione non si connette mai. I ruoli non sono gli stessi, e la differenza sta esattamente dove vive il lavoro di progettazione.

La direzione della connessione non dice nulla sulla direzione del servizio

Quando un client avvia un tunnel, apre un percorso che entrambe le direzioni possono usare una volta che esiste. Se una nuova connessione possa entrare dall'hub verso quel client è una questione di policy del gateway, non una proprietà di chi si è collegato. Su un hub OpenVPN instradato, per esempio, il server ha bisogno di una rotta verso l'indirizzo interno del client e di un inoltro che consenta la relazione peer.

Immagina un sistema di inventario che interroga un agente su portatili in roaming, o uno sviluppatore che ha bisogno di un'API di test da una postazione di lavoro a casa. Entrambi vogliono che il lato ufficio avvii la conversazione, che è l'opposto del consueto schema client-to-server.

I prodotti di accesso remoto ospitati variano su questo punto, e la variazione non è un bug. Alcune VPN di servizio gestito bloccano deliberatamente le connessioni non sollecitate verso i client connessi perché il loro modello è client-to-resource, non resource-to-client. Leggi l'architettura documentata del prodotto prima di promettere a un collega che il suo portatile può fare da server.

Segui il percorso di ritorno prima di aprire una porta

Il percorso ha tre parti: una rotta sul gateway che punta all'indirizzo interno del client, una policy che consente il chiamante specifico e un servizio in ascolto sul target. Ogni parte fallisce in modo diverso, per questo «la VPN è attiva» non dice quasi nulla.

La buona notizia è che il percorso interno non richiede un port forwarding sul router domestico del client. È proprio questo il senso di pubblicare il servizio sull'indirizzo del tunnel invece che sull'indirizzo WAN di casa, dove l'esposizione e le regole NAT sarebbero del tutto diverse. Un router domestico può anche rifiutarsi di fare hairpin di una connessione che arriva dall'ufficio, così la rotta WAN fallisce per motivi estranei alla tua VPN. Tenere il traffico dentro il tunnel evita entrambi i problemi insieme.

Controlla anche il lato target. Un servizio associato solo a 127.0.0.1 non può accettare una connessione che arriva sull'interfaccia del tunnel, per quanto corrette siano le rotte del gateway. Una regola del firewall dell'host che consente la porta solo dalla sottorete locale scarterà anche il traffico dell'ufficio, e quella regola è indipendente dalla policy VPN sovrastante.

Nomi e indirizzi sono decisioni di progetto

Un indirizzo dentro il tunnel non è automaticamente un nome. Un record DNS privato che controlli è più chiaro che sperare che un protocollo di discovery attraversi il tunnel, perché la risoluzione dei nomi multicast link-local resta sul segmento locale e non diventa DNS tra sottoreti.

La stabilità dell'indirizzo conta altrettanto. Se i client VPN attingono da un pool con lease brevi, l'indirizzo interno del portatile cambia tra le sessioni e ogni segnalibro, ambito del firewall e controllo di monitoraggio costruito su di esso si rompe in silenzio. Usa una prenotazione o un percorso documentato di aggiornamento dinamico.

Concorda il nome con chi possiede l'identità VPN, così che il record, l'assegnazione dell'indirizzo e la policy di accesso cambino insieme invece che in tre ticket separati.

Prova il servizio, non l'appartenenza

Dal target, verifica cosa è in ascolto e su quale indirizzo, poi verifica la visione del gateway del percorso di ritorno:

$ ss -ltnp | grep 8080
LISTEN 0 128 10.80.0.23:8080 0.0.0.0:*
$ ip -4 addr show tun0 | grep inet
inet 10.80.0.23/24 scope global tun0
$ ip route get 10.80.0.1
10.80.0.1 dev tun0 src 10.80.0.23

Ora prova dal lato ufficio con una richiesta reale invece di un echo. Un curl riuscito verso il servizio dimostra rotta, policy e listener in una volta, mentre un ping riuscito dimostra solo che ICMP è consentito. Se la richiesta fallisce, torna indietro attraverso le tre parti invece di allargare il firewall e sperare.

La disponibilità fa parte della stessa conversazione. Un portatile dorme, passa tra reti e si disconnette a fine giornata. Un servizio che deve rispondere a qualsiasi ora appartiene a un host sempre acceso, mentre un servizio best-effort può restare sul client con quel limite scritto.

Pubblica la risorsa deliberatamente, con un nome, un elenco di chiamanti consentiti e un proprietario, e il dispositivo remoto diventa un servizio supportato invece di un server accidentale.