Un solo URL per ufficio e VPN? Perché il mito della lista di autorizzati fallisce

Collegate il tunnel, aprite lo stesso segnalibro e il sito autorizzato risponde esattamente come faceva dall’ufficio. È questa l’ipotesi su cui la maggior parte dei piani di accesso remoto poggia in silenzio, e regge solo finché tre cose distinte restano vere contemporaneamente. Nessuna di esse è una funzione del client VPN, e nessun record DNS può fornirne una. Quando il segnalibro fallisce a casa, il browser vi dà un unico errore generico, che la causa sia una rotta mancante, un indirizzo di uscita non approvato o un proxy che ha sostituito l’origine che dichiara. Trattare quei tre come un solo problema è il modo in cui una piccola correzione di policy diventa una settimana di allargamento delle liste di autorizzati.

Il progetto che sopravvive al contatto con una vera rete d’ufficio è più stretto dell’ipotesi: una tabella decisionale esplicita a tre righe, un punto di applicazione che non può essere aggirato e una prova di rifiuto che dimostra qualcosa. Smontare l’ipotesi viene prima, perché tutto ciò che segue dipende dal sapere quale strato rappresenta male l’origine.

Il mito: connettersi non è instradare

Si stabilisce un tunnel e il client installa rotte per un certo insieme di prefissi. È tutto ciò che fa connettersi. Se una richiesta HTTPS estranea attraversa il tunnel, e da quale indirizzo pubblico sembra arrivare quando giunge, sono decisioni prese più tardi da altri componenti: la tabella di routing sceglie il percorso e l’uscita sceglie l’origine.

Per questo l’ufficio e il tavolo di cucina divergono con lo stesso portatile, lo stesso profilo del browser e lo stesso segnalibro. In ufficio la richiesta esce da un indirizzo pubblico mantenuto che l’operatore del sito ha accettato. Attraverso un tunnel completo può uscire dall’uscita VPN, che è un altro indirizzo e, finché qualcuno non lo aggiunge, non approvato. Attraverso un tunnel diviso può non entrare affatto nel tunnel. Solo due di questi tre percorsi hanno mai fatto parte dell’accordo con il proprietario del sito, e il terzo non è un difetto da rattoppare con una voce allow in più.

Tre stati della richiesta, due uscite approvate

Scrivete la matrice prima di toccare un firewall, perché la tabella è il progetto e la regola ne è solo un’implementazione. Gli indirizzi sotto sono intervalli di documentazione; sostituiteli con i vostri valori mantenuti e conservateli dove il proprietario del sito può verificarli.

La riga centrale è dove la maggior parte di questi piani si spezza. Conta l’indirizzo che osserva il dispositivo di applicazione, non l’indirizzo privato che il portatile tiene dentro il tunnel né il suo indirizzo LAN. Un valore come 10.8.0.6 non significa nulla per un sito pubblico, e 192.168.1.44 nemmeno. L’indirizzo del tunnel è un dettaglio di indirizzamento del tunnel, non una credenziale che il sito possa verificare.

Se la vostra VPN non può fornire un’uscita stabile e documentata, la matrice non ha una riga centrale valida e nessuna quantità di liste di autorizzati ne inventerà una. Le opzioni oneste a quel punto sono un sito privato raggiunto tramite rotte private esplicite o un gateway di accesso consapevole dell’identità davanti all’applicazione. Entrambi hanno un contratto diverso da quello di una lista pubblica di autorizzati, ed entrambi sono più facili da spiegare a un revisore di una lista cresciuta finché non ha funzionato per caso.

Leggete l’origine dove si prende la decisione

Mettete la restrizione sul dispositivo che termina la richiesta e confermate che nessun percorso d’origine alternativo la aggira. Il modulo di accesso di Nginx valuta le direttive allow e deny in ordine, vince la prima corrispondenza, e le regole ereditate da un blocco che racchiude si applicano ancora dentro location. Un allow stretto accanto a un allow ampio nello stesso punto di solito significa che decide l’ampio. Leggete l’intera configurazione effettiva per quel location prima di modificarne anche una sola riga.

server {
    listen 443 ssl;
    server_name intranet.example.com;

    set_real_ip_from 10.20.0.10;
    real_ip_header X-Forwarded-For;
    real_ip_recursive on;

    location /app/ {
        allow 203.0.113.24;    # office public exit
        allow 198.51.100.77;   # approved VPN egress
        deny  all;
        proxy_pass http://app_backend;
    }
}

Dietro un bilanciatore di carico o un proxy inverso, quella regola vede il proxy a meno che non gli diciate altro. Ripristinate l’indirizzo del chiamante solo tramite il meccanismo proxy fidato supportato, con un elenco esplicito di indirizzi proxy. Un’intestazione di richiesta che dichiara un indirizzo approvato non è prova che il chiamante lo possieda, e su un listener pubblico un’intestazione inoltrata non validata trasforma la lista di autorizzati in decorazione.

Poi controllate l’altra famiglia di indirizzi. Un insieme di regole che copre solo IPv4 è una decisione incompleta per un nome host che risponde anche su AAAA, e un client con IPv6 funzionante raggiungerà la stessa applicazione per un percorso che non avete mai esaminato.

Tunnel diviso: la richiesta che non entra mai

Un tunnel diviso trasporta solo i prefissi della sua lista. Le sottoreti interne dell’ufficio di solito figurano in quella lista; un sito web pubblico no. Il browser risolve il nome, confronta l’indirizzo scelto con la tabella di routing e trova comunque il gateway predefinito locale davanti a sé.

Così la richiesta arriva dalla connessione domestica dell’utente, viene rifiutata, e il rapporto dice che la VPN è rotta mentre il tunnel fa esattamente ciò per cui è stato configurato. Due correzioni sono legittime: instradate quella destinazione attraverso il tunnel e lasciate che l’uscita approvata la porti, oppure accettate che il sito sia raggiunto direttamente e date agli utenti remoti un altro percorso approvato, come il gateway di accesso. Allargare la lista pubblica di autorizzati del sito finché un indirizzo domestico non vi rientra per caso non è nessuna delle due, e rimuove il confine che il progetto doveva imporre. Le prime due tengono onesta la matrice; la terza ne cancella silenziosamente una riga.

Dimostrate il rifiuto, poi il ripristino

Provate con una richiesta che eserciti la decisione reale, da un client posto su ogni riga della tabella. Un controllo di raggiungibilità verso una pagina qualsiasi che riporta l’indirizzo non dimostra nulla, perché quella destinazione può seguire un percorso diverso da quello dell’applicazione.

curl -sS -o /dev/null -w 'status=%{http_code}
' https://intranet.example.com/app/login
# repeat with the tunnel up, then with it down
tail -f /var/log/nginx/access.log | grep ' /app/'

Confrontate il registro degli accessi al confine con ciò che la tabella aveva previsto. Poi abbassate il tunnel e fate una nuova richiesta che dovrebbe essere rifiutata; una pagina già caricata, o una connessione già aperta, non prova proprio nulla. Se non compare alcun rifiuto, il punto di applicazione non è dove credete.

Mantenete l’autenticazione dell’applicazione dopo l’ammissione alla rete, perché un’uscita d’ufficio e un’uscita VPN rappresentano ciascuna molte persone e nessuna identifica un individuo. L’istruzione per gli utenti resta breve: alzate il tunnel approvato, poi riprovate. È ciò che tiene comodo un solo URL mentre la regola d’origine resta una decisione e non un’ipotesi.