Quale indirizzo vede un firewall cloud quando la VPN è attiva
Un tunnel completo cambia l’indirizzo di origine che vede il tuo database. Sposta l’elenco consentito, il percorso privato o il tunnel diviso, non la credenziale.
Un database che funziona prima che la VPN si connetta e fallisce dopo è raramente un problema di credenziali. I firewall cloud confrontano indirizzi di origine, e un tunnel completo sostituisce proprio quello che stavano confrontando. La differenza tra ciò che pensi che il tuo portatile invii e ciò che riceve il server è tutto il difetto, e si misura in un solo passo.
In che cosa diventa l’indirizzo di origine
In un tunnel completo ogni pacchetto esce dalla gateway VPN, quindi il server vede l’indirizzo di uscita della gateway anziché la tua connessione domestica. Se sul percorso c’è un proxy in avanti, è il suo indirizzo ad arrivare. Entrambi sono origini legittime, e nessuno dei due è l’indirizzo della tua regola originale.
Le regole del firewall di Azure SQL a livello di server e di database confrontano l’indirizzo del client che raggiunge il server logico, che dopo un tunnel completo è l’indirizzo di uscita. Un gruppo di sicurezza AWS che consente un solo indirizzo si comporta allo stesso modo. Il pacchetto viene scartato prima dell’autenticazione, quindi l’errore che ricevi sembra un guasto di rete invece di un problema di permessi. È esattamente per questo che le persone iniziano a reimpostare le password.
Dove si decide l’elenco consentito
Leggi la regola che corrisponde al percorso che fallisce, non quella che ricordi di aver creato. Annota la sua portata, la sua porta, il suo protocollo e se viene valutata prima di qualsiasi controllo di identità.
Poi decidi quale livello possiede legittimamente la decisione. Una regola di indirizzo risponde da dove arriva il traffico. Un endpoint privato risponde se il servizio è raggiungibile del tutto tramite un percorso privato. Un’eccezione di tunnel diviso risponde quali destinazioni aggirano il tunnel. Non sono intercambiabili, e ciascuna fallisce in modo diverso quando il tunnel cambia.
Tre riparazioni, tre livelli
Ogni opzione qui sotto corregge il flusso per un motivo diverso, e scegliere quella sbagliata produce una connessione che funziona fino al successivo cambio di gateway.
| Repair | Layer it changes | What it does not fix |
|---|---|---|
| Add the egress address to the rule | Source address matching | Nothing about routing, and it breaks when the egress moves |
| Use a private endpoint | Whether the service is reached privately | A client that still resolves the public name |
| Add a split-tunnel exception | Which flows bypass the tunnel | An expired credential or a wrong password |
Aggiungere l’indirizzo di uscita è la modifica più piccola e la più fragile, perché una nuova gateway o una regione diversa la invalidano in silenzio. Documenta l’indirizzo accanto alla definizione del tunnel perché i due si muovano insieme. Un intervallo ampio temporaneo è una diagnosi, non una riparazione; lasciarlo al suo posto è il modo in cui i servizi interni finiscono esposti.
Perché una piattaforma gestita non può unirsi al tunnel
Piattaforme applicative come Heroku, AppHarbor o CloudBees eseguono il tuo codice in un ambiente senza dispositivo tun o tap e senza privilegi per crearne uno. Il loro modello di ingresso è HTTP e non un socket in ascolto arbitrario. Un buildpack che include un binario VPN continua a non avere un posto dove mettere l’interfaccia. Gli schemi praticabili sono un indirizzo di uscita statico che il database può consentire, un prodotto di connessione privata offerto dalla piattaforma o un proxy in una DMZ raggiungibile via HTTPS.
Quel proxy è un percorso di accesso con la propria autenticazione e registrazione. Non rende la piattaforma un membro della tua VPN, e descriverla così produce regole che nessuno può verificare.
Verifica dal client che ha fallito
Riconnettiti e ripeti il percorso esatto del client. Controlla l’indirizzo di origine che il servizio registra, la rotta che il client sceglie per il nome del database e il risultato della query reale, in quest’ordine. Un test dalla gateway dimostra che la gateway funziona, cosa che non è mai stata in dubbio. Se la connessione ora si autentica e la query fallisce ancora, il problema rimanente è il permesso del database.
Rivedi queste regole ogni volta che il tunnel cambia. Una gateway sostituita o un nuovo intervallo di uscita rompono il percorso senza alcuna modifica alla configurazione dell’applicazione.