PPTP conéctase e despois colga tras Linux NAT: o axudante GRE

Alguén reenvía o 1723, o cliente chega ao servidor, comeza a autenticación e entón todo detense sen un erro. A conclusión natural é un contrasinal incorrecto, así que o contrasinal volve escribirse tres veces. O reenvío estaba ben e as credenciais estaban ben. O que se rompeu é un segundo protocolo que o reenvío nunca cubriu, e un valor predeterminado do núcleo que deixou de axudar con el en silencio.

O reenvío nunca foi o problema

Unha regra de reenvío de portos describe tráfico TCP ou UDP. Non pode describir unha carga útil que cambia a outro protocolo IP a metade dunha sesión, e PPTP fai exactamente iso.

Por iso a conexión parece sana ata o momento en que se colga. A parte que unha regra de porto pode gobernar tivo éxito, e a parte que non pode gobernar é a parte que fallou.

TCP para o control, GRE para os datos

A chamada négase sobre TCP 1723. Unha vez establecida, a carga útil pasa a GRE, protocolo IP 47, que non leva ningún número de porto. Unha regra que se basea en portos non ten con que coincidir.

O que GRE si leva é un identificador de chamada na súa cabeceira, e o tradutor NAT ten que reescribir ese campo de forma coherente nas dúas direccións ou as dúas metades da sesión deixan de coincidir. Unha dirección reescrita e a outra non produce unha sesión que se autentica e despois descarta cada paquete de datos. Esa é exactamente a forma do síntoma: éxito, e despois silencio.

GRE espido sen PPTP non necesita esa reescritura, por iso un túnel GRE simple pode funcionar a través dun router que falla para un cliente PPTP na mesma ruta.

Catro módulos e un sysctl que os apagou

Dous módulos encárganse da trama, nf_conntrack_proto_gre e nf_nat_proto_gre. Outros dous encárganse do identificador de chamada, nf_conntrack_pptp e nf_nat_pptp. Cargar o último deles arrastra o resto por dependencias, así que a listaxe de módulos debería mostrar os catro.

As instrucións antigas usan un prefixo ip_ da era 2.6. Eses comandos poden parecer que se executan mentres non cargan nada, así que revise a lista cargada en lugar do estado de saída.

Telo cargados xa non abonda. Desde Linux 4.7 o sysctl net.netfilter.nf_conntrack_helper vale 0 por defecto, o que desactiva a asignación automática de axudantes para os fluxos novos. Un router pode ter todos os módulos e aínda así non traducir nada. Comprobe o valor efectivo antes de volver mirar a lista de módulos.

Ou ben volva activar a asignación automática de forma global, ou ben enlace o axudante aos fluxos que o necesitan e deixe todo o demais en paz:

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

A segunda opción é a preferible. Limita o comportamento ao tráfico PPTP en lugar de reactivar a asignación automática en todo o router.

Abrir un protocolo que non ten portos

Unha regra de cortalumes que permite o 1723 non di nada sobre o protocolo 47. En firewalld, permita o protocolo na zona que mira ao cliente. En iptables simple, acepte o protocolo gre na cadea de entrada.

Despois capture nos dous lados. Os paquetes que saen do cliente sen que cheguen respostas significan que a ruta de volta está filtrada, e iso é un fallo distinto dunha credencial rexeitada.

Despois de conectar, o límite de tamaño

GRE insire unha cabeceira, e PPP dentro engade máis, así que unha ligazón que funciona informa dunha MTU bastante por baixo de 1500. As respostas pequenas cargan e as grandes atócanse, o que parece un segundo problema non relacionado que aparece xusto cando se resolve o primeiro.

Lea a MTU no adaptador PPP do cliente e concíliena co cálculo propio do router en lugar de baixar os números ata que algo funcione. Os paquetes de tamaño completo que saen sen que volva nada apuntan a ese límite e non á tradución.

Reparar a ruta devolve o usuario ao traballo, e non fai de PPTP unha boa elección. MS-CHAPv2 e RC4 están desaconsellados desde hai moito, así que trate a carga do módulo como unha corrección temporal e planifique o paso a un protocolo mantido.