O PPTP do MikroTik cai? Corrija a rota até o servidor

Um cliente PPTP no RouterOS conecta, move um pouco de tráfego e depois morre, e o registro parece um problema de credenciais ou do servidor. Normalmente não é nenhum dos dois. O túnel carrega os próprios pacotes de transporte porque a rota até o servidor também coincide com a rota que o túnel instalou. O outro lado para de ouvir o roteador, e a sessão morre enquanto a interface ainda afirma estar ativa.

A correção é uma rota, ou um ajuste, que mantém o servidor acessível pelo WAN físico. Qual delas depende de o roteador dever ser um gateway de túnel completo.

O sintoma: conecta, move tráfego, morre

O padrão se repete a cada reconexão, e essa é a primeira pista útil. Uma senha rejeitada falha antes de a interface subir, uma configuração errada de firewall normalmente bloqueia uma direção, e um laço de roteamento deixa a interface estabelecer e depois a estrangula. Olhe os contadores: o túnel mostra uma rajada de pacotes iniciais e depois nada, enquanto a interface WAN continua transmitindo cópias encapsuladas. Isso é um roteador alimentando a própria saída de volta para si mesmo.

O PPTP torna isso fácil de provocar porque o transporte é IP simples até o endereço do servidor, não um túnel cuja extremidade remota fica em outra sub-rede. Qualquer coisa que redirecione esse endereço redireciona o transporte junto.

Por que o túnel engole os próprios pacotes

Quando o cliente conecta, instala uma rota cujo gateway é a interface do túnel. Se o perfil também instalar uma rota padrão, então todo destino sem correspondência mais específica, incluindo o endereço público do servidor, é resolvido para o túnel. O roteador encapsula o pacote, endereça o pacote externo ao servidor e procura a rota de novo: mesmo destino, mesmo padrão, mesmo túnel. Dependendo da versão, essa recursão é descartada, enfileirada ou posta em laço até o outro lado desistir e derrubar a sessão.

Os fabricantes de equipamentos costumam adicionar automaticamente uma rota de host para o próprio servidor, justamente para evitar isso. O RouterOS não assume isso, então o operador precisa expressar a exceção ou evitar a rota padrão desde o início.

Fixe o endereço do servidor no WAN

Adicione a rota mais estreita possível: uma /32 para o endereço público do servidor, com o gateway do provedor como próximo salto, na interface que chega à internet. Uma /32 vence qualquer rota padrão pelo comprimento do prefixo, e uma distância menor vence se já existir outra rota para o mesmo prefixo. Depois reconecte e confirme que a rota está ativa e não apenas presente na lista.

/ip route add dst-address=198.51.100.10/32 gateway=192.0.2.1 distance=10

Se o gateway do provedor é aprendido por DHCP, use o endereço de gateway que o DHCP instalou, ou amarre a rota à interface se a versão suportar. Um gateway codificado à mão que muda na próxima concessão é uma falha adiada. Verifique o endereço depois de uma reconexão do WAN, porque é aí que surge um gateway obsoleto e o túnel começa a cair de novo.

Ou impeça o túnel de reivindicar a rota padrão

Uma filial que precisa de uma única LAN remota deve manter o perfil PPTP completamente longe da rota padrão. Desative essa opção no perfil do cliente e adicione, em vez disso, uma rota específica para o prefixo remoto pela interface do túnel. O tráfego comum fica no WAN, o transporte do próprio túnel mantém o caminho natural, e a tabela de roteamento fica mais fácil de explicar. Esse é o desenho melhor para uma filial que precisa de uma sub-rede, não para um roteador que deve ser a saída do local.

O túnel completo tem os próprios requisitos: roteamento por política para fontes selecionadas, um plano para o tráfego de retorno e uma decisão sobre o que acontece quando o túnel cai. Nada disso é resolvido pela rota de host, que só mantém o transporte vivo.

Verifique por camadas e depois feche o buraco de gestão

Teste por camadas: faça ping ao endereço público do servidor antes de conectar, faça ping ao gateway remoto depois de conectar, e então faça ping a um host da LAN remota. Adicione masquerade na interface do túnel se os hosts atrás do roteador precisam que as respostas voltem por ela.

/ip firewall nat add chain=srcnat out-interface=pptp-out1 action=masquerade

Depois reinicie o roteador ou force uma reconexão do WAN e repita os três pings, porque uma rota que só existe na configuração em execução não sobrevive. Uma configuração exportada para um arquivo de backup e restaurada mais tarde é o outro lugar onde isso quebra, já que a rota pode faltar na exportação se foi adicionada em tempo de execução.

Por fim, limite o Winbox e a gestão web a endereços de origem conhecidos antes de publicar qualquer mudança de VPN ou de rota. Um roteador que termina túneis é um alvo de gestão, e a porta 80 aberta para o mundo é um achado maior do que a rota que você acabou de corrigir.