Um prefixo público para clientes VPN: o que ele realmente quebra

Um pool de clientes escolhido porque os números parecem arrumados é uma rota à espera de ser instalada. O prefixo não precisa de ser privado para a VPN funcionar, e usar um bloco que pertence a outra pessoa também não expõe automaticamente os seus utilizadores à internet. O que faz é tornar esses endereços com um significado diferente enquanto o túnel está ativo, e depois outra coisa quando cai. Percorra as cinco verificações abaixo por ordem e pare onde a resposta for «atribuído noutro lugar».

Atribuir não é anunciar

Colocar um endereço numa interface de túnel não o anuncia à internet. A acessibilidade pública exige uma rota, um caminho autorizado e um fornecedor disposto a transportá-la, e nada disso aparece porque um cliente recebeu o endereço de um pool. A política da firewall e a autorização do anfitrião são outra vez decisões separadas.

É por isso que o risco não é o que a maioria assume. O prefixo emprestado não torna os seus clientes acessíveis; torna os destinos de outra pessoa inacessíveis a partir dos seus clientes, o que é uma falha diferente com um proprietário diferente. Ninguém é atacado e nenhum anúncio escapa. Um utilizador simplesmente não consegue abrir um site que funcionava ontem, e o helpdesk não tem razão para suspeitar do pool da VPN.

A distinção importa quando escolhe um pool. Se a única preocupação fosse a exposição à internet, um bloco público pareceria seguro porque nada o anuncia. A preocupação é a rota local que o cliente instala para esse prefixo, e essa rota é instalada quer alguém mais a possa ver quer não.

O que a rota do cliente captura realmente

Quando o túnel sobe, o cliente recebe uma rota para o prefixo do pool, e essa rota ganha à rota predefinida para cada destino dentro dele. Um pedido a um anfitrião legítimo nesse bloco vai agora para a VPN em vez da internet. Se falha, fica pendurado ou chega ao servidor errado depende do que o seu lado faz com ele.

ip route get 198.51.100.20
ip -br addr show tun0
traceroute -n 198.51.100.20

Execute a consulta com o túnel ativo e novamente com ele inativo. O endereço significa uma coisa no primeiro caso e algo completamente diferente no segundo, e qualquer aplicação que tenha colocado em cache uma ligação ou uma resolução de nome durante essa transição comporta-se de forma inconsistente. Essa inconsistência é mais difícil de suportar do que uma falha limpa, porque depende do momento. Um utilizador que se reconecta no momento errado tem uma experiência diferente de quem não o faz.

Também por isso um endereço IP familiar não é prova de identidade. Mantenha a validação de certificado e de nome de servidor para o destino real, porque o endereço numérico a que chegou há cinco minutos pode agora pertencer a outra conversa.

Compare o pool com todas as redes que conhece

RFC 1918 reserva três blocos para uso privado: 192.168.0.0/16, 172.16.0.0/12 e 10.0.0.0/8. Milhões de organizações separadas reutilizam-nos, por isso privado é uma afirmação sobre a atribuição e nunca uma promessa de que ninguém mais escolheu os mesmos números.

Compare o pool candidato com as LAN de escritório, as VPC da nuvem, outros pools de VPN, as ligações de parceiros e os intervalos que os trabalhadores remotos provavelmente têm em casa. O caso doméstico não é motivo para inventar um prefixo estranho; é motivo para manter o pool pequeno e documentado.

Coordene a atribuição com quem possui o encaminhamento e registe o caminho de retorno no mesmo local. Um pool para o qual ninguém consegue encaminhar de volta é um pool que será redescoberto durante uma falha. Coloque o pool no mesmo documento que os intervalos dos sites, não numa configuração de cliente que só uma pessoa editou. O documento é o que torna a próxima colisão evitável.

Quando o endereçamento público é a resposta certa

As organizações com espaço global atribuído corretamente podem sem dúvida construir um pool de VPN com endereços públicos, e algumas fazem-no deliberadamente para evitar a tradução. Esse desenho continua a precisar de encaminhamento, validação de origem, regras de acesso e autenticação de clientes; a atribuição não fornece nada disso.

O que fornece é unicidade, a propriedade de que o prefixo emprestado carece. Se possui o bloco, a rota que o seu cliente instala aponta para endereços que são genuinamente seus, e o significado não muda quando o túnel cai.

Não acrescente NAT automaticamente para compensar uma escolha de pool. Um desenho privado encaminhado com rotas de retorno explícitas é mais limpo do que uma tradução aplicada porque o endereçamento nunca foi planeado, e o IPv6 precisa do seu próprio plano deliberado em vez de uma cópia dos pressupostos do IPv4.

Retire um pool mau sem perder o acesso

Se o pool já está implementado, faça um inventário antes de o alterar: reservas de endereços, rotas instaladas, registos DNS que resolvem no bloco, âmbitos da firewall e as aplicações que deles dependem. Depois agende a alteração com o mesmo cuidado que qualquer outra mudança de encaminhamento. Anuncie-a às pessoas que a vão notar, porque as sessões delas cairão quando o pool se mover. Uma alteração silenciosa ao endereçamento dos clientes gera pedidos de suporte que parecem não ter relação com o trabalho.

Preserve um caminho de recuperação que não dependa do pool que está a remover, porque o momento em que o retira é o momento em que o seu acesso remoto pode desaparecer com ele. Depois valide ambos os sentidos: os destinos privados previstos ainda funcionam, e os destinos de internet que antes eram capturados agora resolvem para os seus verdadeiros proprietários.

O que quer é um pool que a equipa de rede possa atribuir, encaminhar e retirar como uma única coisa coerente. Um formato de endereço por si só não estabelece segurança nem conectividade.