Que endereço de origem o NGINX registrará para um cliente VPN?

Numa instalação de NGINX com OpenVPN no mesmo host aparecem três endereços de cliente, um por cada caminho que um pedido pode seguir. Um navegador que chega ao endereço do túnel, um navegador que chega ao endereço público e um programa que sai pelo caminho de internet da gateway parecem todos diferentes no socket à escuta. Decida que caminho está a observar antes de interpretar a linha de registo. A decisão depende do destino usado pelo cliente, da exceção que mantém para o ponto final externo da VPN e de haver ou não algo que traduza o pacote pelo caminho.

Decida pelo destino, não por quem é o utilizador

Comece pelo endereço para onde o pedido foi enviado, porque é esse endereço que escolhe o caminho. Um pedido para o endereço do túnel do host chega à interface do túnel com o endereço interno do cliente como origem. Um pedido para o endereço público do host chega normalmente à interface virada para a internet com o endereço público do cliente, mesmo quando o mesmo portátil tem um túnel estabelecido nesse momento. Pertencer ao conjunto da VPN é, portanto, uma propriedade do caminho do pacote, não uma propriedade que siga o utilizador.

É precisamente esta terceira linha que vale a pena verificar primeiro quando um utilizador da VPN aparece no registo com um endereço que nada tem a ver com o túnel. Também explica por que dois utilizadores com o mesmo perfil podem gerar entradas diferentes: as suas próprias redes de acesso são diferentes e nada dentro do túnel o substitui.

Por que o ponto final externo cria um segundo caminho público

O cliente tem de alcançar o endereço público da gateway para estabelecer o túnel, pelo que tem de existir uma rota para esse endereço fora do túnel. Quando um cliente redireciona todo o tráfego para dentro, uma implementação sensata mantém uma rota de host explícita para o endereço público do servidor, para evitar um túnel que dependa de si mesmo. Essa exceção não distingue serviços, pelo que qualquer pedido para o mesmo endereço público a segue, incluindo um pedido de navegador para um site alojado na gateway.

É este o mecanismo por trás da maioria dos relatos confusos nesta área, e depende da implementação do cliente e não do servidor. Dois clientes com perfis idênticos podem, por isso, comportar-se de forma diferente. Remover a exceção para »corrigir« o registo deita também o túnel abaixo, por isso mantenha-a e desenhe em torno dela.

Leia o socket, a tabela e o formato do registo em conjunto

Três observações decidem que caminho está a ver: onde o socket escuta, que interface responde ao destino e o que o formato do registo realmente grava. Se o ouvinte estiver ligado apenas ao endereço do túnel, um pedido público não o consegue alcançar de todo, o que elimina duas linhas de imediato. Se a pesquisa para o cliente devolver o dispositivo do túnel, o pedido chegou com uma origem interna e o registo deveria mostrá-lo.

ss -lntp 'sport = :443'
ip route get 10.24.0.20
ip route get 192.0.2.44

Depois leia o formato em vez da linha. Um campo alimentado por um cabeçalho reencaminhado registra uma alegação, não um par do socket, e a alegação só conta quando o par imediato é um proxy de confiança. Escrever ambos os valores no registo resolve discussões posteriores, porque o par imediato e o endereço substituído são factos diferentes e só um deles veio da rede.

log_format tunneled '$remote_addr $realip_remote_addr $request $status';
grep -n 'log_format' /etc/nginx/nginx.conf

Escolha o ponto de entrada que quer e faça o DNS concordar

Se o site se destina apenas ao túnel, dê-lhe um nome que, para os clientes VPN, resolva no endereço do túnel, e aplique política no socket à escuta. Uma resposta de DNS dividido que devolve 10.24.0.1 para o nome interno é uma decisão de encaminhamento disfarçada de detalhe de resolução de nomes. Se o site também tiver de ser público, mantenha dois nomes ou duas portas e deixe o registo dizer qual serviu o pedido.

As regras de permitir seguem a mesma lógica. Permitir o conjunto do túnel não autoriza um pedido público e não preenche um endereço interno numa ligação que chegou pela internet. Misturar os dois pontos de entrada sob um único nome torna a origem registada num efeito secundário do encaminhamento do cliente em vez de uma escolha de projeto.

Verifique o caminho e depois a política

Confirme o caminho com uma captura na gateway e um pedido que controle. Uma captura no dispositivo do túnel e outra na interface pública mostram qual transportou os bytes, e a ordem dos pacotes indica se houve uma tradução entre ambos.

tcpdump -ni tun0 port 443 -c 5
tcpdump -ni eth0 port 443 -c 5

Depois verifique o acesso nos dois sentidos: a entrada com nome prevista funciona para o cliente previsto, e um caminho público não aprovado é recusado em vez de ser apenas lento. Um site genérico de eco de IP prova algo sobre a saída da gateway para a internet e nada sobre este site no mesmo host. Quando uma página e um WebSocket discordam, compare os respetivos URL, famílias de endereços e respostas DNS antes de tocar na configuração do servidor.