Dê aos usuários de VPN acesso a um serviço, não à sub-rede

Um prestador precisa de uma aplicação web interna e de mais nada, e a resposta fácil é dar a ele um túnel para a sub-rede do servidor. Isso funciona até o dia em que ele a escaneia. O desenho mais estreito exige mais reflexão, porque alcançabilidade, roteamento e permissão da aplicação são três controles separados que precisam concordar.

Escreva o requisito como um serviço, não como uma sub-rede

Comece pelo host de destino, o protocolo e a porta, e depois acrescente o grupo de usuários ou dispositivos que deve alcançá-lo. Inclua a zona DNS privada apenas se a aplicação resolver um nome, e inclua um provedor de identidade apenas se o fluxo de login precisar de um. Todo o resto é uma dependência que você ainda não justificou.

Uma sub-rede é um detalhe de implementação da equipe de rede, enquanto um serviço é o que o negócio pediu e a unidade que pode ser revisada e desativada.

Se a lista de dependências passar de três itens, a aplicação provavelmente precisa de uma conversa de design própria.

Encaminhe de forma estreita, mas aplique em outro lugar

Uma rota ou seletor estreito diz ao túnel quais pacotes ele deve transportar; não é uma política de autorização. O filtro do gateway, o firewall do host de destino e o modelo de permissões da própria aplicação são onde o acesso é decidido. Uma rota que cobre um único endereço é um bom começo, e não é o controle que detém um usuário decidido. É essa separação que permite mudar o filtro sem redesenhar o túnel.

Por outro lado, uma rota ampla com um filtro rígido pode ser legítima, mas apenas se todos os envolvidos souberem qual das duas faz a aplicação da regra.

Documente explicitamente o ponto de aplicação, ou a próxima mudança vai movê-lo por acidente.

Verifique a origem que o serviço realmente vê

O destino vê o endereço do pool do cliente ou o endereço do gateway, dependendo de você traduzir ou não. As regras do firewall do host e os registros devem corresponder à origem real. Se vários usuários compartilham uma origem traduzida, nenhuma regra por usuário nesse host pode distingui-los, e isso é uma restrição de projeto, não um bug.

Escolha a tradução deliberadamente: ela simplifica o roteamento e destrói a identidade da origem, o que importa para auditoria e para regras por usuário.

Anote qual das duas você escolheu, ao lado da regra que depende dela.

A autorização da aplicação não é opcional

Alcançar uma porta não concede um papel. A aplicação ainda precisa do próprio login e das próprias permissões, porque a camada de rede não consegue expressar quais registros um usuário pode editar. Um serviço que confia em qualquer requisição da sub-rede interna transforma um túnel estreito em acesso total para uma credencial comprometida. O túnel decide quem pode abrir o socket, e a aplicação decide o que se pode fazer com ele.

É aqui que o desenho estreito compensa duas vezes, porque menos hosts alcançáveis significa menos lugares onde um erro no nível da aplicação pode ser explorado.

Mantenha a regra de rede e o papel da aplicação em sistemas separados, e desative ambos separadamente.

Comprove tanto o caminho permitido quanto o negado

Conecte-se como o usuário autorizado e execute uma operação representativa inofensiva, depois tente um destino que deveria ser inalcançável. Um desenho que testa apenas a primeira metade não está testado, e é o teste negado que comprova o desenho. Teste uma sessão nova após cada mudança de regra, e olhe o caminho de retorno se as requisições chegam mas as respostas não.

Não desative os filtros de encaminhamento para fazer o teste de aceitação passar, porque isso muda a coisa que está sendo testada.

Quando o usuário não precisar mais do serviço, desative a identidade remota e o papel da aplicação nos respectivos sistemas, e registre ambos. O guia de encaminhamento do strongSwan cobre o lado do gateway do caminho.