Por que os clientes do Access Server ficam inacessíveis a partir da LAN

O portátil conecta, o túnel está ativo e as requisições a um serviço interno travam na conexão. No próprio serviço a requisição chega de um endereço como 10.90.0.25, a resposta sai em direção ao gateway padrão e nada volta, porque esse gateway não faz ideia de onde fica 10.90.0.25. Do outro lado, a mesma falha parece um host interno que não consegue pingar um cliente conectado. Ambos são um único objeto ausente: uma rota de retorno para o conjunto de clientes VPN, que só a rede privada pode adicionar.

Leia o endereço de origem que o serviço vê

Esse único campo decide todo o resto. Se o serviço interno vê o endereço do conjunto, o Access Server está encaminhando em vez de esconder o tráfego dos clientes, e todas as respostas precisam ser encaminhadas de volta ao conjunto. Se em vez disso vê o endereço privado do próprio servidor, o servidor está fazendo masquerade e o caminho de volta já funciona, ao custo de perder qualquer identidade por cliente nos logs e nas regras de acesso do serviço.

Compare as duas pontas antes de mudar qualquer coisa. No servidor, liste as interfaces do túnel e seus endereços; no cliente, confirme qual desses endereços ele realmente tem; no host interno, olhe para uma conexão ativa.

ip -br addr show
ss -tnp state established '( dport = :443 )'
ip route get 10.90.0.25

O último comando é o que falha no caso quebrado: ele relata o prefixo do túnel como inalcançável ou, pior, devolve o seu gateway padrão, e é assim que as respostas acabam na internet.

Não presuma apenas um conjunto. Um servidor pode ter uma faixa dinâmica mais atribuições estáticas por usuário, e o endereço estático pode ficar totalmente fora do prefixo dinâmico. Se você encaminhar apenas a faixa de que se lembra, os usuários com endereços fixos continuam quebrados e todo mundo relata o problema como resolvido.

Adicione a rota onde a resposta é decidida

A rota pertence ao gateway que o serviço interno já usa, não ao serviço, a menos que ele encaminhe o próprio tráfego. Aponte-a para o endereço privado alcançável do Access Server, que é um valor diferente do endereço de túnel que um cliente possui.

ip route add 10.90.0.0/24 via 10.0.1.5
ip route get 10.90.0.25

Numa rede de nuvem a mesma afirmação vira uma entrada da tabela de rotas cujo destino é a instância ou a interface de rede onde o servidor roda, com a verificação de origem e destino desativada nessa interface. Note o que essa entrada não faz: uma rota não é uma concessão de acesso, então grupos de segurança, ACLs de rede e o firewall do host ainda precisam permitir o tráfego.

Torne-a persistente e mantenha os tamanhos dos conjuntos honestos. Dois conjuntos não contíguos exigem duas rotas, e um conjunto que cresce além do prefixo configurado produz silenciosamente clientes cujas respostas não têm para onde ir. Se você controla as faixas dos conjuntos, escolha um resumo que possa encaminhar uma vez e deixar quieto.

O encaminhamento e os filtros devem concordar com a rota

O encaminhamento é só metade do caminho. O servidor precisa ter permissão para encaminhar entre o túnel e a interface privada, o que no Linux significa net.ipv4.ip_forward mais uma cadeia de encaminhamento que permita o par de interfaces, e num host endurecido geralmente uma regra explícita para cada direção.

sysctl net.ipv4.ip_forward
nft list ruleset | grep -A5 forward

A filtragem com estado explica um sintoma que leva as pessoas pelo caminho errado. Uma resposta dentro de um fluxo estabelecido não precisa de uma nova regra de entrada, então uma conexão que trava depois do SYN-ACK não está sendo bloqueada por uma regra de aceitação ausente; está sendo descartada ou encaminhada errado. Mantenha essa distinção, porque ela separa uma mudança de encaminhamento de uma mudança de firewall.

Caminhos de retorno assimétricos são a versão mais silenciosa do mesmo problema. Se duas rotas alcançam o conjunto e a resposta pega a que sai por uma interface diferente daquela por onde a requisição chegou, a filtragem estrita de caminho reverso a descarta e o fluxo falha apenas para alguns clientes.

Encaminhado ou mascarado: escolha a dedo

O modo encaminhado preserva o endereço do conjunto do cliente no serviço, o que possibilita registro e política por cliente, e em troca toda rede interna que precisa responder a um cliente necessita da rota do conjunto. O modo mascarado remove essa exigência porque as respostas voltam ao servidor, mas o serviço não distingue mais um cliente do outro e não consegue iniciar nada na direção de um cliente específico.

Mudar esse comportamento num servidor em produção derruba as sessões existentes, então teste primeiro com um cliente e um fluxo. Se a troca for a resposta certa, é uma decisão de configuração no servidor, não algo a contornar adicionando rotas que depois se tornarão desnecessárias.

Uma sub-rede atrás do cliente é uma tarefa à parte

Alcançar um dispositivo na própria LAN do portátil não é a mesma coisa que alcançar o endereço de túnel do portátil. Exige que o cliente atue como gateway de sub-rede: uma rede declarada no lado do cliente, o encaminhamento ativado no sistema operacional do cliente e uma rota nessa LAN de volta para o cliente. Adicionar uma rota de rede privada para a faixa doméstica do portátil não faz isso, e cria conflitos quando dois usuários têm a mesma faixa doméstica.

A direção também é uma questão de política. A permissão para um cliente abrir uma conexão a um serviço interno não permite automaticamente que um host interno abra uma conexão para esse cliente. Verifique a política de acesso do servidor e o firewall do host do cliente antes de concluir que o caminho está quebrado.

Comprove com um fluxo e uma captura

Prove o caminho com uma única conexão em vez de um teste geral de alcance. Observe o mesmo fluxo nas duas pontas: a requisição chegando ao serviço e a resposta saindo dele.

tcpdump -ni any host 10.90.0.25 and port 443

Antes da correção a captura mostra a resposta saindo em direção a um gateway que não a encaminhará. Depois da correção a resposta sai em direção ao servidor e o fluxo se completa. Em seguida confirme a rota que o gateway usaria para um segundo endereço de cliente, para que um conjunto não coberto apareça agora e não dentro de uma semana.

Termine com as quatro verificações que fecham o assunto: o endereço de origem no serviço corresponde ao modo pretendido, o gateway tem rota para cada conjunto em uso, o encaminhamento e os filtros permitem as duas direções, e um fluxo real se completa de ponta a ponta. Perguntas frequentes sobre encaminhamento no Access Server expõe o mesmo princípio para a versão instalada, cuja interface de configuração suportada pode diferir dos guias antigos.