NordVPN no Linux bloqueia a LAN: lista de permissões e DNS

Tudo parece normal até você tentar alcançar algo na sua própria mesa. O túnel está ativo, as páginas carregam e a unidade de rede expira. Desconecte e a unidade volta antes de você terminar a frase, o que lhe diz mais do que qualquer log: o cliente está recusando deliberadamente o tráfego que não entra no túnel, e sua rede local está do lado errado dessa linha.

O interruptor de segurança está fazendo o seu trabalho

Um interruptor de segurança existe para impedir que o tráfego escape quando o túnel não está disponível. Faixas de endereços privados contam como tráfego que não entra no túnel, então uma implementação rígida as bloqueia junto com todo o resto. Isso não é um bug no sentido que as pessoas querem dizer quando registram o relatório.

Leia primeiro a visão do próprio cliente. Um comando imprime as configurações atuais e um segundo mostra os objetos de firewall que o cliente criou. Você está procurando um drop ou reject que apareça antes de qualquer exceção do túnel, porque é essa ordem que torna a rede local inalcançável.

nordvpn settings
sudo nft list ruleset
sudo iptables -S

Depois execute um teste que divida o problema em dois. Alcance o dispositivo por endereço e depois por nome. Endereço funciona e nome falha significa que o firewall é inocente e o resolvedor não. Ambos falham significa que o firewall está recusando o pacote, e o resto deste artigo se aplica.

Lista de permissões: escolha o tipo de entrada pelo sintoma

O cliente oferece uma lista de permissões com três tipos de entrada, e escolher o tipo certo é a maior parte do trabalho. Uma sub-rede cobre hosts. Uma porta cobre um serviço independentemente do destino. Um grupo multicast cobre o tráfego de descoberta, que é uma forma de tráfego diferente de qualquer coisa endereçada a um único host.

nordvpn allowlist add subnet 192.168.1.0/24
nordvpn allowlist add port 22
nordvpn allowlist add subnet 239.255.255.250/32
sudo nft list ruleset | grep -i allow

Falhas de descoberta surpreendem as pessoas porque uma impressora ou servidor de mídia pode ser encontrado por uma consulta endereçada ao grupo em vez de uma busca pelo próprio endereço. Adicionar a sub-rede do host não cobre esse grupo automaticamente, então o dispositivo continua invisível enquanto a página web dele carrega bem quando você digita o endereço.

Mantenha a exceção tão estreita quanto o sintoma permitir. Um prefixo amplo digitado uma vez é esquecido por anos, e ninguém consegue explicar depois quais máquinas ele deveria admitir. Apague as entradas quando o projeto que precisava delas terminar, e verifique o que resta após uma atualização.

Compilações recentes também expõem uma única configuração de descoberta de LAN. Ela é conveniente, e interage com a lista de permissões em vez de se empilhar sobre ela: ativá-la pode limpar entradas existentes de sub-redes privadas, e uma regra manual de sub-rede privada pode ser recusada enquanto ela permanecer ativada.

Nomes de host exigem uma decisão separada

Permitir uma sub-rede restaura a conectividade por endereço e deixa a nomeação intacta. Nomes de host locais ainda são enviados ao resolvedor que o cliente configurou quando o túnel subiu, então um nome que antes resolvia agora não retorna nada.

Apontar o cliente para o resolvedor do roteador resolve isso em um passo e muda silenciosamente o que você comprou. Então cada consulta, não só as locais, sai pelo roteador, e o túnel deixa de proteger a parte da sua navegação que revela intenções.

O caminho mais estreito mantém o resolvedor do túnel e acrescenta os poucos nomes que importam, seja como domínio de busca ou como entradas individuais. Custa mais atenção e preserva a propriedade pela qual você pagou.

Verifique o resultado com uma chamada ao resolvedor do sistema em vez de um navegador. Os navegadores cada vez mais executam sua própria resolução criptografada e respondem de bom grado por um caminho que o seu shell nunca usa, então a barra de endereços pode parecer saudável enquanto o resolvedor do sistema ainda está quebrado.

O problema de instalação que vem primeiro

Uma boa parte desses relatórios nunca chega ao firewall, porque o comando simplesmente não existe. O pacote de inicialização do fornecedor registra um repositório e uma chave de assinatura. Ele não instala o cliente, então um comando ausente logo depois é o resultado esperado e não uma falha.

Atualize as listas de pacotes e instale pelo nome. Se o gerenciador de pacotes reclamar de uma chave pública ausente, a chave não chegou onde ele a procura, e a correção é colocá-la lá antes de atualizar novamente.

Se o nome de host do repositório resolver para um endereço privado, pare e leia esse resultado duas vezes. Você talvez já esteja executando um túnel cujo resolvedor responde por nomes públicos, e repetir a instalação produzirá a mesma mensagem indefinidamente.

Anote antes de fechar a tampa

Estabeleça que o túnel é a única coisa que mudou e então permita a menor coisa que restaure o sintoma. Mantenha a nomeação como uma decisão própria com sua própria nota.

Registre qual exceção existe para qual dispositivo e quem a pediu. Uma rede local que só funciona porque alguém digitou um prefixo amplo é uma decisão que já sobreviveu à razão dela.

Teste novamente depois que o cliente for atualizado. O layout do firewall muda entre versões, e a lista de permissões do mês passado não é um fato sobre este mês.