Um VPN comercial bloqueia a porta 5432? Compare as suas opções
Uma base de dados ou cliente de e-mail que falha apenas enquanto o VPN está ativo está a encontrar um filtro do fornecedor, não a sua firewall. Teste a porta e depois escolha uma solução.
A aplicação falava com a sua base de dados a partir do escritório todos os dias. Depois alguém ativou o cliente VPN comercial no mesmo portátil, e a ligação começou a reiniciar-se após o handshake. Nada na aplicação mudou, o túnel declara-se saudável, e a firewall que controla não tem qualquer regra de bloqueio. O que mudou foi o caminho de saída: os servidores do fornecedor são pontos finais partilhados de elevado volume, e os fornecedores filtram portas de saída para reduzir os abusos. As portas de base de dados e de envio de correio recebem a maior parte, porque são essas as portas que atraem análises e spam de um conjunto de endereços anónimo.
O teste de cinco minutos que separa a filtragem de tudo o resto
A partir da mesma máquina, sonda uma porta que tem de estar aberta e a porta que falha, no mesmo anfitrião, com o túnel ativo e depois desligado. Usa o mesmo comando nas duas vezes para que a única variável seja o túnel:
Test-NetConnection db.example.com -Port 443
Test-NetConnection db.example.com -Port 5432
nc -vz -w3 db.example.com 5432Quatro resultados cobrem quase todos os casos. Se a 443 funciona e a 5432 falha apenas com o túnel ativo, está a ver filtragem de portas no caminho de saída. Se ambas falham com o túnel ativo e ambas funcionam sem ele, o problema é de encaminhamento ou DNS, não de política de portas. Se ambas as portas ligam mas a aplicação continua a falhar, a culpa é da autenticação ou do TLS, não da acessibilidade. E se falha apenas uma localização do servidor do fornecedor, é política por servidor, por isso experimente outra localização antes de tocar em qualquer configuração.
Opção um: túnel dividido para a sub-rede da base de dados
Se o portátil só precisa do VPN comercial para outros fins, exclua o intervalo de endereços da base de dados do túnel para que o tráfego nunca entre na saída partilhada. Esta é a opção mais limpa quando os dois caminhos realmente não precisam de se encontrar, e não custa nada além de uma regra de encaminhamento que possa documentar. O compromisso é que o túnel dividido introduz uma segunda superfície de política: o que é excluído do túnel tem de ser deliberado, não um efeito secundário de uma sub-rede que alguém acrescentou mais tarde.
Deixa de funcionar no momento em que a base de dados vive dentro da rede que o VPN deve alcançar, por isso verifique isso antes de assumir o compromisso.
Opção dois: o seu próprio ponto final, a sua própria saída
Executar um pequeno ponto final de VPN num VPS coloca a política de saída sob o seu controlo, e não está envolvido qualquer conjunto partilhado. É a opção que vale a pena comparar honestamente com o cliente comercial: ganha um endereço de origem previsível e perde a pegada global e a comodidade do fornecedor. Para uma equipa que precisa de portas de base de dados e de correio todo o dia, o compromisso costuma favorecer a posse do ponto final, porque o modo de falha passa a ser a sua própria configuração errada e não a política de abuso de outra pessoa.
Compare as duas pela estabilidade do endereço de origem, por quem pode ler o seu tráfego e pelo que acontece no dia em que o fornecedor do ponto final altera a sua própria filtragem.
Opção três: tire o portátil do caminho
Uma tarefa de CI, um contentor agendado ou um anfitrião bastião dentro da rede permitida não dependem do estado do túnel de uma pessoa. Chegue à base de dados por túnel SSH a partir de um anfitrião que já está permitido, e o portátil nunca fala diretamente com a porta. Esta é a opção que escala quando várias pessoas encontram a mesma restrição, e é também a que elimina o problema em vez de o contornar.
Exige mais trabalho prévio do que uma regra de túnel dividido, e não ajuda a única pessoa que precisa de uma sessão interativa agora.
Porque colocar o endereço do fornecedor numa lista de permitidos é a comparação errada
Acrescentar o endereço de saída do fornecedor a uma lista de permitidos de base de dados funciona, e também dá acesso a todos os outros subscritores que partilham esse endereço naquele momento. Para uma réplica só de leitura atrás de uma conta de aplicação concedida de forma estreita, a exposição pode ser tolerável durante um dia. Para qualquer coisa gravável não é um compromisso que mereça esse nome, e os endereços de saída rotativos pioram-no: cada mudança de servidor quebra a regra, e a manutenção convida entradas CIDR amplas que anulam o propósito de uma lista de permitidos.
Os endereços dedicados ou estáticos, onde o fornecedor os vende, são a única versão disto que escala. Ate a lista de permitidos a um endereço que seja só seu, ou não a ate de todo.
Escolha o que escolher, anote o caminho e o motivo. A próxima pessoa vai encontrar a mesma ligação a reiniciar-se e começará por culpar a aplicação.