Por que um recurso de VPN funciona e outro expira

Um serviço privado carrega pelo túnel e o seguinte expira, e a tentação é reconstruir todo o perfil do cliente. O serviço que funciona é mais útil como controlo do que como razão para recomeçar. Prova que um destino, uma porta e um caminho de autorização foram satisfeitos, e nada mais.

Dois serviços no mesmo gateway podem ser alcançados por famílias de endereços diferentes, sub-redes diferentes e políticas diferentes.

Separe o fluxo que funciona do que falha

Trate cada serviço como o seu próprio fluxo e não como um sintoma da VPN. Um cliente ilustrativo pode abrir portal.corp.example em 172.20.4.15:443 e ainda assim não chegar a uma base de dados em 172.20.9.40:5432, porque são dois destinos com dois conjuntos de regras. Anote as duas linhas antes de mudar qualquer coisa, incluindo a porta e o protocolo, porque uma regra que permite TCP 443 num host não diz nada sobre TCP 5432 no mesmo host.

A linha que falha é a que deve ser investigada. A linha que funciona só diz onde está a linha de base, e será o ponto de comparação depois de cada alteração.

Compare endereços antes de comparar nomes

Resolva cada nome completo pela política que a aplicação realmente usa e depois registe a família de endereços escolhida. Um nome pode devolver um endereço IPv6 enquanto outro devolve IPv4, e uma resposta antiga em cache pode enviar um pedido para um endereço público que não tem nada a ver com o serviço privado.

ip route get 172.20.4.15
ip route get 172.20.9.40
ip -6 route get 2001:db8:60::20

A consulta responde a uma pergunta estreita: que rota este host escolheria para esse destino, com as tabelas e regras de política atuais. Uma rota para 172.20.4.0/24 não cobre 172.20.9.0/24, e um segundo gestor de rede ou uma rota local com melhor especificidade podem anular o túnel em silêncio. Repita a consulta dentro do espaço de nomes ou com a marca que a aplicação usa quando diferem da sua consola. Registe também a interface por onde o pacote sai, porque a tabela de rotas pode nomear uma interface enquanto o encaminhamento por política envia o fluxo por outra.

Uma rota que corresponde é uma condição necessária, não uma permissão. Diz que o pacote tem para onde ir e nada sobre se uma firewall, um serviço de autorização ou o próprio host o aceitarão.

O protocolo e a fase de resposta dizem onde pára

Uma resposta de ping não prova que uma porta de base de dados está aberta, e uma página HTTPS bem-sucedida não autoriza uma partilha de ficheiros na mesma máquina. Registe o que voltou realmente em vez de aplanar cada falha numa só categoria. Um tempo limite, um reset, um erro de identidade TLS e uma recusa ao nível da aplicação apontam cada um para uma camada diferente.

A distinção importa porque as correções divergem. O silêncio significa normalmente um problema de rota, de firewall ou de tradução no caminho. Um reset imediato sugere que algo chegou ao host e recusou a porta. Um erro de certificado significa que a ligação chegou e o nome não coincidia, o que é um problema de configuração e não de acessibilidade. Uma recusa da aplicação significa que a rede fez o seu trabalho e a identidade foi rejeitada depois.

Quando um recurso é publicado através de um gateway, compare o endereço de origem que o destino vê com a origem que o seu cliente pensa estar a usar. Um pedido originado pelo próprio gateway pode ter sucesso enquanto o mesmo pedido de um cliente falha, porque os dois chegam de endereços diferentes e encontram regras diferentes.

Mude uma variável e execute novamente os dois pedidos

A identidade é o último lugar onde as pessoas olham e o primeiro onde aparece uma recusa correta. O início de sessão da VPN, o grupo do diretório e a conta da aplicação são três identidades separadas que podem divergir. O acesso a um portal nunca implica acesso à base de dados por trás dele, e um nome num diretório não cria uma linha noutro. Se o serviço está fora do âmbito previsto do utilizador, a recusa é o sistema a funcionar.

Peça ao proprietário do recurso que confirme o direito previsto em vez de adicionar uma rota ampla ou abrir um grupo como teste. Alargar a rede para provar um ponto é a forma como um diagnóstico temporário se torna uma exposição permanente, e destrói o controlo com que começou. Uma discrepância demonstrada por iteração é suficiente: uma rota em falta, uma família de endereços errada, uma porta bloqueada ou uma pertença a grupo em falta.

Depois de cada alteração, repita os dois pedidos e mantenha as saídas lado a lado. A investigação termina quando o serviço que falhava funciona sob a sua própria política, enquanto o serviço que funciona e as recusas que ainda espera se comportam exatamente como antes.