Un VPN commerciale blocca la porta 5432? Confronta le tue opzioni

L'applicazione parlava con il suo database dall'ufficio ogni giorno. Poi qualcuno ha attivato il client VPN commerciale sullo stesso portatile, e la connessione ha iniziato a reimpostarsi dopo la stretta di mano. Niente nell'applicazione è cambiato, il tunnel si dichiara sano, e il firewall che controlli non ha alcuna regola di blocco. Ciò che è cambiato è il percorso di uscita: i server del fornitore sono endpoint condivisi ad alto volume, e i fornitori filtrano le porte in uscita per ridurre gli abusi. Le porte di database e di invio della posta prendono la maggior parte, perché sono quelle che attirano scansioni e spam da un pool di indirizzi anonimo.

Il test di cinque minuti che separa il filtraggio da tutto il resto

Dalla stessa macchina, sonda una porta che deve essere aperta e la porta che fallisce, sullo stesso host, con il tunnel attivo e poi spento. Usa lo stesso comando entrambe le volte così l'unica variabile è il tunnel:

Test-NetConnection db.example.com -Port 443
Test-NetConnection db.example.com -Port 5432
nc -vz -w3 db.example.com 5432

Quattro esiti coprono quasi tutti i casi. Se la 443 funziona e la 5432 fallisce solo con il tunnel attivo, stai vedendo un filtraggio di porte sul percorso di uscita. Se entrambe falliscono con il tunnel attivo ed entrambe funzionano senza, il problema è il routing o il DNS, non la politica delle porte. Se entrambe le porte si connettono ma l'applicazione fallisce ancora, la colpa è dell'autenticazione o di TLS, non della raggiungibilità. E se fallisce solo una posizione del server del fornitore, è una politica per server, quindi prova un'altra posizione prima di toccare qualsiasi configurazione.

Opzione uno: tunnel diviso per la sottorete del database

Se il portatile ha bisogno del VPN commerciale solo per altri scopi, escludi l'intervallo di indirizzi del database dal tunnel in modo che il traffico non entri mai nell'uscita condivisa. Questa è l'opzione più pulita quando i due percorsi non devono davvero incontrarsi, e non costa nulla oltre a una regola di routing che puoi documentare. Il compromesso è che il tunnel diviso introduce una seconda superficie di politica: ciò che è escluso dal tunnel deve essere deliberato, non un effetto collaterale di una sottorete aggiunta da qualcuno in seguito.

Smette di funzionare nel momento in cui il database vive dentro la rete che il VPN dovrebbe raggiungere, quindi verificalo prima di impegnarti.

Opzione due: il tuo endpoint, la tua uscita

Eseguire un piccolo endpoint VPN su un VPS ti mette al controllo della politica di uscita, e nessun pool condiviso è coinvolto. È l'opzione che vale la pena confrontare onestamente con il client commerciale: guadagni un indirizzo di origine prevedibile e perdi l'impronta globale e la comodità del fornitore. Per un team che ha bisogno delle porte di database e posta tutto il giorno, il compromesso di solito favorisce il possesso dell'endpoint, perché la modalità di guasto diventa la tua errata configurazione invece della politica anti-abuso di qualcun altro.

Confronta le due opzioni per stabilità dell'indirizzo di origine, per chi può leggere il tuo traffico e per ciò che accade il giorno in cui il fornitore dell'endpoint cambia il proprio filtraggio.

Opzione tre: togli il portatile dal percorso

Un job CI, un container pianificato o un host bastion all'interno della rete consentita non dipendono dallo stato del tunnel di una persona. Raggiungi il database tramite tunnel SSH da un host già consentito, e il portatile non parla mai direttamente alla porta. Questa è l'opzione che scala quando più persone incontrano la stessa restrizione, ed è anche quella che elimina il problema invece di aggirarlo.

Richiede più lavoro in anticipo rispetto a una regola di tunnel diviso, e non aiuta la persona che ha bisogno di una sessione interattiva adesso.

Perché aggiungere l'indirizzo del fornitore a una lista di autorizzati è il confronto sbagliato

Aggiungere l'indirizzo di uscita del fornitore a una lista di autorizzati di un database funziona, e concede anche l'accesso a ogni altro abbonato che condivide quell'indirizzo in quel momento. Per una replica di sola lettura dietro un account applicativo concesso in modo ristretto, l'esposizione potrebbe essere tollerabile per un giorno. Per qualunque cosa scrivibile non è un compromesso che meriti un nome, e gli indirizzi di uscita rotanti lo peggiorano: ogni cambio di server rompe la regola, e la manutenzione invita voci CIDR ampie che annullano lo scopo di una lista di autorizzati.

Gli indirizzi dedicati o statici, dove il fornitore li vende, sono l'unica versione di questo che scala. Lega la lista di autorizzati a un indirizzo che è solo tuo, oppure non legarla affatto.

Qualunque cosa scegli, annota il percorso e il motivo. La persona successiva incontrerà la stessa connessione reimpostata e inizierà a dare la colpa all'applicazione.