Limite um listener VPN às interfaces que você pretendia
Um listener curinga e uma regra de firewall são controles diferentes. Leia os sockets reais com ss e depois verifique a família de endereços e o firewall.
Um serviço VPN é acessível de onde seu socket estiver vinculado e o firewall permitir. São duas decisões separadas, e as pessoas geralmente tomam apenas uma delas. Ler o listener real leva dez segundos e resolve uma questão que o palpite não consegue. Comece por aí e depois mude um controle de cada vez.
Tudo abaixo pressupõe que você pode executar comandos no host com root ou sudo.
Leia os sockets antes de mudar qualquer coisa
No Linux, ss -lunp lista listeners UDP com o endereço local, a porta e o processo, e ss -ltnp faz o mesmo para TCP. Procure a porta da VPN e leia a coluna de endereço com atenção. 0.0.0.0:51820 e [::]:51820 significam todas as interfaces, enquanto 10.0.0.5:51820 significa um endereço em uma interface. O manual do ss documenta as colunas se a saída não for familiar. Se o nome do processo estiver faltando, execute o mesmo comando com sudo, porque a coluna de proprietário exige privilégio.
Anote o endereço. É o fato do qual o restante deste guia depende.
Vincule a um endereço, não a um desejo
OpenVPN vincula o listener a um endereço específico com sua diretiva local, e essa é a forma suportada de restringi-lo no nível do processo. Nem toda implementação oferece um equivalente, e um protocolo sem opção de vinculação não pode ser estreitado dessa forma. Se a sua não tiver nenhuma, o firewall é seu único controle, e as notas de implantação devem dizer isso claramente. Em um host com vários endereços, vincule ao que aponta para o túnel; vincular a um endereço flutuante geralmente é um erro.
Um serviço que precisa sobreviver a uma mudança de endereço precisa de um plano para a vinculação obsoleta, não apenas de uma linha de configuração.
Verifique a família de endereços separadamente
IPv4 e IPv6 são sockets separados. Um processo vinculado a 0.0.0.0 ainda pode aceitar IPv6 por meio de um socket de pilha dupla, ou não, dependendo da opção do socket e do padrão da plataforma. Ler apenas a linha IPv4 já enganou mais de uma revisão de implantação. Liste as duas famílias antes de concluir que o listener é estreito.
Se o IPv6 não faz parte do projeto, desativá-lo no nível do socket é mais limpo do que esperar que o firewall o cubra. É uma decisão de política, então registre-a junto com as demais escolhas de interface.
Sobreponha o firewall à vinculação
Uma vinculação estreita não substitui uma regra de firewall, e uma regra de firewall não estreita uma vinculação curinga. Use as duas: vincule onde a implementação oferece suporte, depois permita a porta apenas das origens que deveriam alcançá-la. Os grupos de segurança da nuvem ficam na frente do firewall do host, então verifique ambos quando o caminho cruzar uma fronteira de VPC. A regra efetiva é a interseção das duas, e cada camada só pode subtrair alcance.
Teste de uma origem permitida e de uma deliberadamente excluída. Uma conexão a partir de localhost não prova nada sobre a fronteira pública.
Registre o que você escolheu
Anote o endereço vinculado, a interface que o possui, a regra de firewall e sua finalidade. Uma NIC de reposição ou um endereço de nuvem reatribuído pode mudar a exposição sem que ninguém edite o perfil. Date a nota, porque os endereços de nuvem se movem entre revisões com mais frequência do que as pessoas esperam.
Essa nota é o que torna a próxima revisão uma comparação em vez de um projeto de arqueologia.