Cae o PPTP de MikroTik? Arranxa a ruta ao servidor

Un cliente PPTP de RouterOS conecta, move algo de tráfico e logo morre, e o rexistro parece un problema de credenciais ou do servidor. Normalmente non é nin unha cousa nin a outra. O túnel transporta os seus propios paquetes porque a ruta ao servidor tamén coincide coa ruta que instalou o túnel. O outro extremo deixa de oír o router, e a sesión morre mentres a interface segue dicindo que está activa.

A solución é unha ruta, ou un axuste, que manteña o servidor accesible polo WAN físico. Cal depende de se o router debe ser unha pasarela de túnel completo.

O síntoma: conecta, move tráfico, morre

O patrón repítese en cada reconexión, e esa é a primeira pista útil. Un contrasinal rexeitado falla antes de que a interface suba, unha configuración errónea da devasa normalmente bloquea unha dirección, e un bucle de encamiñamento deixa que a interface se estableza e despois afógaa. Mira os contadores: o túnel mostra unha ráfaga de paquetes iniciais e despois nada, mentres a interface WAN segue transmitindo copias encapsuladas. Iso é un router alimentando a súa propia saída de volta cara a si mesmo.

PPTP fai que isto sexa fácil de provocar porque o transporte é IP simple cara ao enderezo do servidor, non un túnel cuxo extremo afastado está noutra subrede. Calquera cousa que redirixa ese enderezo redirixe o transporte con el.

Por que o túnel traga os seus propios paquetes

Cando o cliente conecta, instala unha ruta cuxa pasarela é a interface do túnel. Se o perfil tamén instala unha ruta por defecto, entón cada destino sen unha coincidencia máis específica, incluído o enderezo público do servidor, resólvese cara ao túnel. O router encapsula o paquete, endereza o paquete exterior ao servidor e volve buscar a ruta: mesmo destino, mesmo defecto, mesmo túnel. Segundo a versión, esa recursión descártase, encolase ou déixase en bucle ata que o outro extremo se rende e corta a sesión.

Os fabricantes de aparellos adoitan engadir automaticamente unha ruta de host para o seu propio servidor, precisamente para evitar isto. RouterOS non o presupón, así que o operador ten que expresar a excepción ou evitar a ruta por defecto desde o principio.

Fixa o enderezo do servidor no WAN

Engade a ruta máis estreita posible: unha /32 para o enderezo público do servidor, coa pasarela do provedor como seguinte salto, na interface que chega a internet. Unha /32 gaña a calquera ruta por defecto pola lonxitude do prefixo, e unha distancia menor gaña se xa existe outra ruta para o mesmo prefixo. Logo reconecta e confirma que a ruta está activa e non só presente na lista.

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

Se a pasarela do provedor se aprende por DHCP, usa o enderezo que instalou DHCP, ou liga a ruta á interface se a versión o admite. Unha pasarela codificada a man que cambia no seguinte arrendamento é un fallo diferido. Comproba o enderezo tras unha reconexión do WAN, porque é cando aparece unha pasarela obsoleta e o túnel comeza a caer de novo.

Ou impide que o túnel reclame a ruta por defecto

Unha sucursal que necesita unha soa LAN remota debería manter o perfil PPTP totalmente lonxe da ruta por defecto. Desactiva esa opción no perfil do cliente e engade no seu lugar unha ruta específica para o prefixo remoto a través da interface do túnel. O tráfico normal queda no WAN, o transporte do túnel conserva o seu camiño natural, e a táboa de encamiñamento faise máis fácil de explicar. Ese é o deseño mellor para unha sucursal que necesita unha subrede, non para un router que debe ser a saída do sitio.

O túnel completo ten os seus propios requisitos: encamiñamento por políticas para fontes seleccionadas, un plan para o tráfico de retorno e unha decisión sobre que pasa cando o túnel cae. Nada diso o resolve a ruta de host, que só mantén vivo o transporte.

Verifica por capas e despois pecha o burato de xestión

Proba por capas: fai ping ao enderezo público do servidor antes de conectar, fai ping á pasarela remota despois de conectar, e logo fai ping a un host da LAN remota. Engade masquerade na interface do túnel se os hosts detrás do router necesitan que as respostas volvan por ela.

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

Despois reinicia o router ou forza unha reconexión do WAN e repite os tres ping, porque unha ruta que só existe na configuración en execución non sobrevivirá. Unha configuración exportada a un ficheiro de copia de seguridade e restaurada despois é o outro lugar onde isto rompe, xa que a ruta pode faltar na exportación se se engadiu en tempo de execución.

Por último, limita Winbox e a xestión web a enderezos de orixe coñecidos antes de publicar calquera cambio de VPN ou de ruta. Un router que termina túneles é un obxectivo de xestión, e o porto 80 aberto ao mundo é un achado maior que a ruta que acabas de arranxar.