Um único URL para o escritório e a VPN? Porque o mito da lista de autorizados falha

Ligue o túnel, abra o mesmo marcador, e o site autorizado responde exatamente como respondia a partir do escritório. É esta a suposição em que a maioria dos planos de acesso remoto assenta em silêncio, e só se sustenta enquanto três coisas distintas permanecem verdadeiras ao mesmo tempo. Nenhuma delas é uma funcionalidade do cliente VPN, e nenhum registo DNS pode fornecer qualquer uma. Quando o marcador falha em casa, o navegador dá-lhe um erro genérico, quer a causa seja uma rota em falta, um endereço de saída não aprovado ou um proxy que substituiu a origem que reporta. Tratar estas três como um único problema é a forma como uma pequena correção de política se transforma numa semana de alargar listas de autorizados.

O desenho que sobrevive ao contacto com uma rede de escritório real é mais estreito do que a suposição: uma tabela de decisão explícita de três linhas, um ponto de aplicação que não pode ser contornado e um teste de recusa que prova algo. Desmontar a suposição vem primeiro, porque tudo o que se segue depende de saber que camada está a representar mal a origem.

O mito: ligar não é encaminhar

Estabelece-se um túnel e o cliente instala rotas para um certo conjunto de prefixos. É tudo o que ligar faz. Se um pedido HTTPS alheio viaja pelo túnel, e de que endereço público parece vir quando chega, são decisões tomadas mais tarde por outros componentes: a tabela de rotas escolhe o caminho e a saída escolhe a origem.

É por isso que o escritório e a mesa da cozinha divergem com o mesmo portátil, o mesmo perfil de navegador e o mesmo marcador. No escritório o pedido sai por um endereço público mantido com o qual o operador do site concordou. Por um túnel completo pode sair pela saída VPN, que é outro endereço e, até alguém o acrescentar, não aprovado. Por um túnel dividido pode nunca entrar no túnel. Apenas dois desses três caminhos fizeram alguma vez parte do acordo com o dono do site, e o terceiro não é um defeito a remendar com uma entrada allow extra.

Três estados de pedido, duas saídas aprovadas

Escreva a matriz antes de tocar numa firewall, porque a tabela é o desenho e a regra apenas uma implementação dele. Os endereços abaixo são intervalos de documentação; substitua-os pelos seus próprios valores mantidos e guarde-os onde o dono do site os possa auditar.

A linha do meio é onde a maioria destes planos se quebra. O que conta é o endereço que o dispositivo de aplicação observa, não o endereço privado que o portátil tem dentro do túnel nem o seu endereço LAN. Um valor como 10.8.0.6 não significa nada para um site público, e 192.168.1.44 também não. O endereço do túnel é um detalhe de endereçamento do túnel, não uma credencial que o site possa verificar.

Se a sua VPN não conseguir fornecer uma saída estável e documentada, a matriz não tem linha do meio válida e nenhuma quantidade de listas de autorizados inventa uma. As opções honestas nesse ponto são um site privado alcançado por rotas privadas explícitas ou um gateway de acesso consciente da identidade à frente da aplicação. Ambas têm um contrato diferente de uma lista pública de autorizados, e ambas são mais fáceis de explicar a um auditor do que uma lista que cresceu até passar a funcionar.

Leia a origem onde a decisão é tomada

Coloque a restrição no dispositivo que termina o pedido e confirme que nenhum caminho de origem alternativo a contorna. O módulo de acesso do Nginx avalia as diretivas allow e deny por ordem, ganha a primeira correspondência, e as regras herdadas de um bloco envolvente continuam a aplicar-se dentro do location. Um allow estreito ao lado de um allow amplo no mesmo local costuma significar que decide o amplo. Leia toda a configuração efetiva desse location antes de editar uma única linha dela.

server {
    listen 443 ssl;
    server_name intranet.example.com;

    set_real_ip_from 10.20.0.10;
    real_ip_header X-Forwarded-For;
    real_ip_recursive on;

    location /app/ {
        allow 203.0.113.24;    # office public exit
        allow 198.51.100.77;   # approved VPN egress
        deny  all;
        proxy_pass http://app_backend;
    }
}

Atrás de um balanceador de carga ou de um proxy inverso, essa regra vê o proxy a menos que lhe diga o contrário. Restaure o endereço do chamador apenas através do mecanismo de proxy fidedigno suportado, com uma lista explícita de endereços de proxy. Um cabeçalho de pedido que afirma um endereço aprovado não é prova de que o chamador o possua, e num ouvinte público um cabeçalho reencaminhado não validado transforma a lista de autorizados em decoração.

Depois verifique a outra família de endereços. Um conjunto de regras que cobre apenas IPv4 é uma decisão incompleta para um nome de anfitrião que também responde em AAAA, e um cliente com IPv6 funcional chegará à mesma aplicação por um caminho que nunca revisou.

Túnel dividido: o pedido que nunca entra

Um túnel dividido transporta apenas os prefixos da sua lista. As sub-redes internas do escritório costumam estar nessa lista; um site público não. O navegador resolve o nome, compara o endereço escolhido com a tabela de rotas e ainda assim encontra a gateway local predefinida à frente.

Assim o pedido chega da ligação doméstica do utilizador, é recusado, e o relatório diz que a VPN está avariada enquanto o túnel faz exatamente aquilo para que foi configurado. Há duas correções legítimas: encaminhe esse destino pelo túnel e deixe a saída aprovada transportá-lo, ou aceite que o site é alcançado diretamente e dê aos utilizadores remotos outro caminho aprovado, como o gateway de acesso. Alargar a lista pública de autorizados do site até que um endereço doméstico nela caia por acaso não é nenhuma das duas, e remove a fronteira que o desenho devia impor. As duas primeiras mantêm a matriz honesta; a terceira apaga em silêncio uma linha.

Prove a recusa, depois a recuperação

Teste com um pedido que exerça a decisão real, a partir de um cliente colocado em cada linha da tabela. Uma verificação de alcance contra uma página alheia que mostre o endereço não prova nada, porque esse destino pode seguir um caminho diferente do da aplicação.

curl -sS -o /dev/null -w 'status=%{http_code}
' https://intranet.example.com/app/login
# repeat with the tunnel up, then with it down
tail -f /var/log/nginx/access.log | grep ' /app/'

Compare o registo de acesso na fronteira com o que a tabela previu. Depois baixe o túnel e faça um pedido novo que deveria ser recusado; uma página já carregada, ou uma ligação já aberta, não testa absolutamente nada. Se não aparecer nenhuma recusa, o ponto de aplicação não está onde pensa.

Mantenha a autenticação da aplicação após a admissão na rede, porque uma saída de escritório e uma saída VPN representam cada uma muitas pessoas e nenhuma identifica um indivíduo. A instrução para os utilizadores continua curta: levante o túnel aprovado e tente de novo. É isto que mantém um único URL conveniente enquanto a regra de origem continua a ser uma decisão e não um palpite.