Bloquea un VPN comercial o porto 5432? Compare as súas opcións

A aplicación falaba coa súa base de datos desde a oficina todos os días. Despois alguén activou o cliente VPN comercial no mesmo portátil e a conexión comezou a reiniciarse tras o apretón de mans. Nada na aplicación cambiou, o túnel informa de que está san e o cortalumes que vostede controla non ten ningunha regra de bloqueo. O que cambiou é a ruta de saída: os servidores do provedor son puntos finais compartidos de alto volume, e os provedores filtran os portos de saída para reducir os abusos. Os portos de base de datos e de envío de correo levan a maior parte, porque son os portos que atraen exploracións e correo lixo desde un conxunto de enderezos anónimo.

A proba de cinco minutos que separa o filtrado de todo o demais

Desde a mesma máquina, sondee un porto que debe estar aberto e o porto que falla, no mesmo host, co túnel activo e despois desactivado. Use o mesmo comando as dúas veces para que a única variable sexa o túnel:

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

Catro resultados cobren case todos os casos. Se o 443 funciona e o 5432 falla só co túnel activo, está a ver filtrado de portos na ruta de saída. Se ambos fallan co túnel activo e ambos funcionan sen el, o problema é de encamiñamento ou de DNS, non de política de portos. Se ambos os portos conectan pero a aplicación segue fallando, a culpa é da autenticación ou de TLS, non da accesibilidade. E se só falla unha localización de servidor do provedor, é política por servidor, así que probe outra localización antes de tocar calquera configuración.

Opción un: túnel dividido para a subrede da base de datos

Se o portátil só necesita o VPN comercial para outros fins, exclúa o rango de enderezos da base de datos do túnel para que o tráfico nunca entre na saída compartida. Esta é a opción máis limpa cando os dous camiños realmente non necesitan atoparse, e non custa nada máis alá dunha regra de encamiñamento que poida documentar. O compromiso é que o túnel dividido introduce unha segunda superficie de política: o que se exclúe do túnel ten que ser deliberado, non un efecto secundario dunha subrede que alguén engadiu despois.

Deixa de funcionar no momento en que a base de datos vive dentro da rede que se supón que o VPN debe alcanzar, así que compróbeo antes de comprometerse con el.

Opción dous: o seu propio punto final, a súa propia saída

Executar un pequeno punto final de VPN nun VPS ponlle ao control da política de saída e non interfire ningún conxunto compartido. Esta é a opción que merece unha comparación honesta co cliente comercial: gaña un enderezo de orixe previsible e perde a pegada global e a comodidade do provedor. Para un equipo que necesita portos de base de datos e de correo todo o día, o compromiso adoita favorecer a posesión do punto final, porque o modo de fallo pasa a ser a súa propia configuración errónea e non a política de abusos doutra persoa.

Compare as dúas pola estabilidade do enderezo de orixe, por quen pode ler o seu tráfico e polo que ocorre o día en que o provedor do punto final cambia o seu propio filtrado.

Opción tres: saque o portátil da ruta

Unha tarefa de CI, un contedor programado ou un host bastión dentro da rede permitida non dependen do estado do túnel dunha persoa. Chegue á base de datos por un túnel SSH desde un host que xa está permitido, e o portátil nunca fala directamente co porto. Esta é a opción que escala cando varias persoas atopan a mesma restrición, e tamén é a que elimina o problema en lugar de sortelo.

Require máis traballo por adiantado que unha regra de túnel dividido, e non axuda a única persoa que necesita unha sesión interactiva agora mesmo.

Por que poñer o enderezo do provedor nunha lista de permitidos é a comparación equivocada

Engadir o enderezo de saída do provedor a unha lista de permitidos de base de datos funciona, e tamén concede acceso a todos os demais subscritores que comparten ese enderezo nese momento. Para unha réplica de só lectura detrás dunha conta de aplicación concedida de forma estreita, a exposición podería ser tolerábel durante un día. Para calquera cousa escribible non é un compromiso que mereza ese nome, e os enderezos de saída rotativos empeorano: cada cambio de servidor rompe a regra, e o mantemento invita entradas CIDR amplas que anulan o propósito dunha lista de permitidos.

Os enderezos dedicados ou estáticos, onde o provedor os vende, son a única versión disto que escala. Ate a lista de permitidos a un enderezo que sexa só seu, ou non a ate en absoluto.

Elixa o que elixa, escriba a ruta e o motivo. A seguinte persoa atoparase coa mesma conexión reiniciándose e comezará culpando a aplicación.