PostgreSQL por VPN: que endereço de origem o pg_hba verá

O PostgreSQL nunca descobre que um cliente está numa VPN. Recebe uma ligação TCP de um endereço e um conjunto de credenciais, e decide o que fazer com eles. Tornar o acesso dependente do túnel significa, portanto, organizar três decisões separadas para que concordem, e depois verificar o único endereço que o servidor realmente vê em vez daquele que desenhou no diagrama.

Três decisões que não devem fundir-se

Onde o servidor escuta é uma decisão. Que tráfego pode chegar a esse endereço é uma segunda, tomada pela firewall do anfitrião e por qualquer fronteira de rede à sua frente. Que identidade de base de dados pode autenticar-se a partir de que origem é uma terceira, tomada em pg_hba.conf.

Cada uma é aplicada por um componente diferente, e cada uma falha com uma mensagem diferente. Fundi-las numa discussão é como as pessoas acabam a editar o ficheiro HBA para corrigir um problema de firewall. Mantenha-as por ordem: um listener que não está ligado não pode ser alcançado, a uma porta filtrada não se pode ligar, e uma regra HBA decide apenas o que acontece depois de existir uma ligação. Quando uma alteração não tem efeito, identifique qual das três camadas alterou realmente.

Onde o servidor escuta

Ligue a um endereço que esteja realmente atribuído à máquina, não a um nome de interface:

listen_addresses = '10.20.0.30'

A base de dados pode estar atrás da gateway VPN sem a sua própria interface de túnel, e é exatamente por isso que um endereço é a coisa certa a nomear. Alterar esta definição exige um reinício completo; um recarregamento não basta.

Depois filtre a porta, normalmente 5432, no anfitrião e em cada fronteira à sua frente. Ligar-se a um endereço privado não é prova de negação pública, porque um encaminhamento de porta ou um mapeamento de endereço na nuvem ainda pode entregar pacotes a esse listener privado.

O endereço que o HBA realmente vê

Com acesso encaminhado, o servidor vê o endereço interno do túnel de cada cliente. Com tradução de origem, vê em vez disso o endereço traduzido da gateway, e cada cliente colapsa nesse único valor. Inspecione a origem através das próprias evidências de ligação do servidor antes de escolher um prefixo a permitir.

Para uma implementação que já usa TLS e SCRAM, um exemplo deliberadamente estreito de acesso remoto tem este aspeto:

hostssl appdb app_login 10.8.0.0/24 scram-sha-256
host all all 0.0.0.0/0 reject
host all all ::/0 reject

Isso permite um papel e uma base de dados sobre TLS a partir do conjunto indicado, e depois rejeita outro acesso TCP remoto. Não substitui um ficheiro HBA completo: mantenha a administração local, a replicação e qualquer outro serviço autorizado, e coloque as regras estreitas antes das autorizações mais amplas.

Quando a tradução está em jogo, o HBA não consegue distinguir os clientes pelos seus endereços originais. Mantenha a admissão de rede apertada e exija credenciais reais de base de dados, e nunca substitua a autenticação trust por uma conta real.

Ganha a primeira correspondência, sem alternativa

O PostgreSQL lê o ficheiro de cima para baixo e usa o primeiro registo que corresponde à ligação. Não há segunda tentativa se a autenticação desse registo falhar, pelo que uma autorização ampla anterior derrota silenciosamente uma rejeição posterior.

Essa regra de ordem é o motivo mais comum para uma rejeição cuidadosamente escrita nunca entrar em vigor. Coloque as regras específicas primeiro e as amplas por último, e depois leia o ficheiro como uma sequência e não como um conjunto. Uma regra que acrescentou no fundo não é uma política, é um comentário. Mova-a para cima e recarregue antes de concluir que o ficheiro está a ser ignorado.

A referência HBA define tanto a ordem como a diferença entre os registos host e hostssl, o que importa quando o objetivo da regra é que a ligação tem de ser cifrada.

Recarregamento, reinício e o caso negado

As alterações HBA são aplicadas com um recarregamento, e a vista pg_hba_file_rules ajuda-o a encontrar erros de análise. Essa vista descreve o conteúdo atual do ficheiro, não se o servidor em execução os carregou com sucesso, pelo que uma listagem limpa não é prova de que as novas regras estão ativas.

As alterações ao listener exigem o seu próprio reinício, e as duas operações confundem-se facilmente quando uma alteração parece não ter efeito.

Teste com sessões novas: um cliente aprovado com a conta pretendida liga-se, a mesma conta a partir de um caminho não aprovado não, e uma identidade de base de dados não autorizada continua a falhar de dentro da VPN. Esses três resultados separam a fronteira de rede da autorização da base de dados, que é todo o sentido de manter as decisões separadas.