Retirar o PPTP/MS-CHAPv2: manual para uma VPN legada
Uma palavra-passe mais longa não melhora o PPTP com MS-CHAPv2. Siga pela ordem os passos de inventário, migração, verificação e limpeza de credenciais.
Palavras-passe de vinte caracteres, rodadas todos os meses e guardadas num cofre, não transformam um servidor PPTP com MS-CHAPv2 numa VPN moderna. A palavra-passe é uma entrada de um intercâmbio cuja fraqueza está no próprio intercâmbio. Este manual destina-se a quem herdou esse servidor e tem de mover os utilizadores sem cortar o sítio que depende dele. Siga os passos pela ordem, porque cada um deixa um registo de que vai precisar quando alguém perguntar porque é que o acesso mudou de repente.
Escreva a pilha antes de tocar em nada
Três camadas são reunidas na palavra PPTP, e cada uma falha à sua maneira. O túnel é o próprio PPTP, GRE mais TCP 1723. A autenticação é o método PPP que o servidor oferece, aqui MS-CHAPv2. A proteção da ligação é o MPPE, cujas chaves derivam desse intercâmbio de autenticação. Nomear as três evita que uma correção posterior aterre na camada errada.
Leia a configuração viva em vez de confiar numa página wiki, e anote o ficheiro, o ouvinte e as últimas sessões que se autenticaram.
grep -RniE 'mschap|mppe|require-mppe' /etc/ppp/options.pptpd /etc/pptpd.conf
ss -lntp 'sport = :1723'
journalctl -u pptpd -n 40 --no-pager
Num papel de acesso remoto do Windows o mesmo inventário vem de dois comandos, e o segundo importa porque um papel pode anunciar vários métodos ao mesmo tempo enquanto os clientes no terreno só negoceiam sempre o mais fraco.
Get-VpnAuthProtocol
netstat -ano | findstr :1723
Decida o que o túnel transporta hoje na realidade
Liste os consumidores antes de escolher um substituto: portáteis em itinerância, um router de filial, um terminal de pagamento, um conjunto de tablets de campo. Um consumidor que só precisa de alcançar um anfitrião interno é fácil de mover. Um consumidor embutido em hardware que não consegue reflashar pode precisar de um gateway intermédio em vez de uma atualização do cliente, e essa decisão pertence ao plano, não ao meio da migração.
Depois pergunte o que obteria um atacante que consiga observar ou influenciar o intercâmbio de início de sessão. Com MS-CHAPv2 a resposta inclui material que permite recuperar fora de linha a palavra-passe do utilizador, e é precisamente por isso que o comprimento e a rotação não reparam o desenho: o segredo recuperado é válido em todos os sistemas onde o utilizador o reutilizou.
O MPPE herda a mesma fraqueza, já que as suas chaves vêm desse intercâmbio, e não lhe dá a integridade por pacote nem o comportamento de repetição de uma cifra AEAD moderna. Uma sessão que se autentica de forma limpa provou compatibilidade com as verificações configuradas e nada mais.
Nem uma pausa curta para almoço nem um número pequeno de utilizadores convertem uma propriedade criptográfica numa propriedade de política.
Execute a migração numa única janela de manutenção
Ponha o substituto de pé, prove-o com um grupo piloto, e depois pare o ouvinte antigo em vez de o deixar como recurso silencioso. Um recurso a que todos ainda conseguem chegar não é uma migração, e mantém o intercâmbio fraco disponível justamente para os utilizadores que nunca se dão ao trabalho de mudar.
sudo systemctl disable --now pptpd
sudo ss -lntp | grep -E ':(1723|1194|51820)\b'
sudo nft list ruleset | grep -i gre
Feche o caminho da firewall na mesma janela. O GRE não tem porta de que se lembrar, por isso uma regra que permite o protocolo 47 pelo número passa facilmente despercebida e deixa o serviço alcançável mesmo depois de o daemon ter desaparecido. Registe a regra removida, a posição anterior e o motivo, para que uma revisão de alterações posterior não a reponha por acidente.
Trate as credenciais separadamente da configuração. Remover um perfil de cliente não é uma revogação, e uma conta que ainda se autentica noutro lugar não foi retirada.
Verifique se o substituto faz o trabalho que o PPTP fazia
A lista de verificação não é «liga-se?». É se a autenticação, a atribuição de endereços, a resolução DNS, a seleção de rota, o comportamento de reconexão e a verificação do par continuam a valer com o substituto. Teste cada um num dispositivo piloto, nessa ordem, e escreva o resultado observado ao lado do esperado.
ip -4 addr show tun0
ip route get 198.51.100.23
resolvectl query intranet.example.net
Um endereço na interface prova que a negociação terminou. Não prova que o lado remoto autorizou a rota que espera, e a consulta acima responde apenas por este anfitrião, não por uma LAN reencaminhada. Uma resposta do resolver prova a acessibilidade de um resolver, não que a política de DNS dividido lhe envie os nomes certos.
Reconecte por último, porque é aí que a maioria dos substitutos regride: suspenda um portátil, mude de rede e confirme que o túnel se restabelece sem deixar rotas obsoletas.
Reversão, revogação e o registo que deixa
A reversão restaura o serviço; não restaura a segurança, e a diferença tem de ser dita em voz alta antes de a janela abrir. Se o novo caminho falhar, traga os utilizadores de volta através de um segundo ponto final moderno ou de um gateway temporário, não reativando o PPTP para todos. Manter um caminho de emergência no protocolo antigo alarga a exposição que acabou de documentar.
Após a migração, revogue as contas que se autenticaram através de PPTP, deixe expirar os perfis guardados e confirme que a regra GRE desapareceu de todos os dispositivos de periferia, incluindo a cópia de recuperação de desastres de que ninguém se lembra.
Deixe um registo breve: os protocolos que encontrou, a data em que cada ouvinte parou, as versões de cliente suportadas pelo substituto e o proprietário que pode reabrir a decisão. A higiene das palavras-passe continua a importar depois, mas como higiene num protocolo que a merece, não como argumento para manter o antigo vivo.