Il PPTP di MikroTik cade? Sistemate la rotta verso il server

Un client PPTP su RouterOS si connette, sposta un po’ di traffico e poi muore, e il registro sembra un problema di credenziali o del server. Di solito non è né l’uno né l’altro. Il tunnel trasporta i propri pacchetti perché la rotta verso il server coincide anche con la rotta installata dal tunnel. L’altra estremità smette di sentire il router, e la sessione muore mentre l’interfaccia continua a dichiararsi attiva.

La correzione è una rotta, o un’impostazione, che tiene il server raggiungibile sul WAN fisico. Quale delle due dipende da se il router deve essere un gateway di tunnel completo.

Il sintomo: si connette, sposta traffico, muore

Lo schema si ripete a ogni riconnessione, ed è il primo indizio utile. Una password rifiutata fallisce prima che l’interfaccia salga, una configurazione errata del firewall di solito blocca una direzione, e un ciclo di routing lascia che l’interfaccia si stabilisca e poi la strozza. Guardate i contatori: il tunnel mostra una raffica di pacchetti iniziali e poi nulla, mentre l’interfaccia WAN continua a trasmettere copie incapsulate. È un router che rimanda la propria uscita dentro se stesso.

PPTP rende tutto ciò facile da innescare perché il trasporto è semplice IP verso l’indirizzo del server, non un tunnel il cui estremo remoto sta in un’altra sottorete. Qualunque cosa reindirizzi quell’indirizzo reindirizza anche il trasporto.

Perché il tunnel inghiotte i propri pacchetti

Quando il client si connette, installa una rotta il cui gateway è l’interfaccia del tunnel. Se il profilo installa anche una rotta predefinita, allora ogni destinazione senza una corrispondenza più specifica, compreso l’indirizzo pubblico del server, finisce nel tunnel. Il router incapsula il pacchetto, indirizza il pacchetto esterno al server e cerca di nuovo la rotta: stessa destinazione, stesso default, stesso tunnel. A seconda della versione, quella ricorsione viene scartata, messa in coda o mandata in ciclo finché l’altra estremità non si arrende e chiude la sessione.

I produttori di apparati aggiungono spesso automaticamente una rotta host per il proprio server, proprio per evitarlo. RouterOS non lo presuppone, quindi l’operatore deve esprimere l’eccezione o evitare la rotta predefinita fin dall’inizio.

Fissate l’indirizzo del server sul WAN

Aggiungete la rotta più stretta possibile: una /32 per l’indirizzo pubblico del server, con il gateway del provider come prossimo salto, sull’interfaccia che raggiunge internet. Una /32 batte qualsiasi predefinita per lunghezza del prefisso, e una distanza più bassa vince se esiste già un’altra rotta per lo stesso prefisso. Poi riconnettetevi e confermate che la rotta è attiva e non solo presente nell’elenco.

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

Se il gateway del provider è appreso via DHCP, usate l’indirizzo di gateway installato da DHCP, oppure legate la rotta all’interfaccia se la versione lo supporta. Un gateway scritto a mano che cambia al lease successivo è un guasto differito. Controllate l’indirizzo dopo una riconnessione del WAN, perché è lì che compare un gateway obsoleto e il tunnel ricomincia a cadere.

Oppure impedite al tunnel di rivendicare la predefinita

Una filiale che ha bisogno di una sola LAN remota dovrebbe tenere il profilo PPTP del tutto lontano dalla rotta predefinita. Disattivate quell’opzione nel profilo del client e aggiungete invece una rotta specifica per il prefisso remoto attraverso l’interfaccia del tunnel. Il traffico ordinario resta sul WAN, il trasporto del tunnel mantiene il suo percorso naturale, e la tabella di routing diventa più facile da spiegare. Questo è il progetto migliore per una filiale che ha bisogno di una sottorete, non per un router che dovrebbe essere l’uscita del sito.

Il tunnel completo ha i suoi requisiti: routing basato su policy per sorgenti selezionate, un piano per il traffico di ritorno e una decisione su cosa succede quando il tunnel cade. Nulla di tutto ciò è risolto dalla rotta host, che tiene in vita solo il trasporto.

Verificate a strati, poi chiudete il buco di gestione

Provate a strati: fate ping all’indirizzo pubblico del server prima di connettervi, fate ping al gateway remoto dopo la connessione, poi fate ping a un host della LAN remota. Aggiungete masquerade sull’interfaccia del tunnel se gli host dietro il router hanno bisogno che le risposte tornino attraverso di essa.

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

Poi riavviate il router o forzate una riconnessione del WAN e ripetete i tre ping, perché una rotta che esiste solo nella configurazione in esecuzione non sopravvive. Una configurazione esportata in un file di backup e ripristinata più tardi è l’altro punto in cui questo si rompe, dato che la rotta può mancare nell’esportazione se è stata aggiunta a runtime.

Infine, limitate Winbox e la gestione web a indirizzi di origine noti prima di pubblicare qualsiasi modifica di VPN o di rotta. Un router che termina tunnel è un obiettivo di gestione, e la porta 80 aperta al mondo è una scoperta più grave della rotta che avete appena sistemato.