PPTP connecta i després es penja darrere Linux NAT: l’ajudant GRE

Algú reenvia el 1723, el client arriba al servidor, comença l’autenticació i llavors tot s’atura sense cap error. La conclusió natural és una contrasenya incorrecta, així que la contrasenya es torna a escriure tres vegades. El reenviament estava bé i les credencials estaven bé. El que es va trencar és un segon protocol que el reenviament mai no cobria, i un valor per defecte del nucli que va deixar d’ajudar-hi en silenci.

El reenviament mai no va ser el problema

Una regla de reenviament de port descriu trànsit TCP o UDP. No pot descriure una càrrega útil que canvia a un altre protocol IP a mitja sessió, i PPTP fa exactament això.

Per això la connexió sembla sana fins al moment que es penja. La part que una regla de port pot governar va tenir èxit, i la part que no pot governar és la part que va fallar.

TCP per al control, GRE per a les dades

La trucada es negocia sobre TCP 1723. Un cop aixecada, la càrrega passa a GRE, protocol IP 47, que no porta cap número de port. Una regla que es basa en ports no té res amb què comparar.

El que GRE sí que porta és un identificador de trucada a la seva capçalera, i el traductor NAT ha de reescriure aquest camp de manera coherent en les dues direccions o les dues meitats de la sessió deixen d’estar d’acord. Una direcció reescrita i l’altra no produeix una sessió que s’autentica i després descarta cada paquet de dades. Aquesta és exactament la forma del símptoma: èxit, i després silenci.

GRE nu sense PPTP no necessita aquesta reescriptura, i per això un túnel GRE simple pot funcionar a través d’un encaminador que falla per a un client PPTP al mateix camí.

Quatre mòduls i un sysctl que els va apagar

Dos mòduls s’encarreguen de l’emmarçament, nf_conntrack_proto_gre i nf_nat_proto_gre. Dos més s’encarreguen de l’identificador de trucada, nf_conntrack_pptp i nf_nat_pptp. Carregar l’últim d’aquests arrossega la resta per dependències, així que el llistat de mòduls hauria de mostrar els quatre.

Les instruccions antigues fan servir un prefix ip_ de l’època del 2.6. Aquestes ordres poden semblar que s’executen mentre no carreguen res, així que comproveu la llista carregada en lloc de l’estat de sortida.

Tenir-los carregats ja no és suficient. Des de Linux 4.7 el sysctl net.netfilter.nf_conntrack_helper val 0 per defecte, cosa que desactiva l’assignació automàtica d’ajudants per als fluxos nous. Un encaminador pot tenir tots els mòduls i tot i així no traduir res. Comproveu el valor efectiu abans de tornar a mirar la llista de mòduls.

O bé torneu a activar l’assignació automàtica globalment, o bé enganxeu l’ajudant als fluxos que el necessiten i deixeu la resta en pau:

iptables -t raw -A PREROUTING -p tcp --dport 1723 -j CT --helper pptp

La segona opció és la preferible. Limita el comportament al trànsit PPTP en lloc de reactivar l’assignació automàtica a tot l’encaminador.

Obrir un protocol que no té ports

Una regla de tallafoc que permet el 1723 no diu res sobre el protocol 47. A firewalld, permeteu el protocol a la zona que mira al client. A iptables simple, accepteu el protocol gre a la cadena d’entrada.

Després captureu als dos costats. Paquets que surten del client sense respostes que arribin volen dir que el camí de tornada està filtrat, i això és una avaria diferent d’una credencial rebutjada.

Després de connectar, el límit de mida

GRE insereix una capçalera, i PPP a dins n’afegeix més, així que un enllaç que funciona informa d’una MTU força per sota de 1500. Les respostes petites es carreguen i les grans es bloquegen, cosa que sembla un segon problema no relacionat que apareix just quan se soluciona el primer.

Llegiu la MTU a l’adaptador PPP del client i conciliueu-la amb el càlcul propi de l’encaminador en lloc d’anar baixant números fins que alguna cosa funcioni. Els paquets de mida completa que surten sense que torni res apunten a aquest límit, no a la traducció.

Reparar el camí posa l’usuari a treballar, i no fa que PPTP sigui una bona opció. MS-CHAPv2 i RC4 fa temps que estan desaconsellats, així que tracteu la càrrega del mòdul com una solució temporal i planifiqueu un pas a un protocol mantingut.