Servidor PPTP detrás dun router doméstico: arranxa primeiro o 1723 e o GRE

PPTP detrás dun router doméstico falla de dúas maneiras non relacionadas, e confundilas custa unha tarde enteira. Un fallo é un oco no reenvío: o router deixa pasar TCP 1723 e descarta o protocolo IP 47, así que o cliente queda colgado no erro 619. O outro é un problema de tamaño: o túnel sobe, autentícase e despois conxélase cando ten que cruzar un paquete de tamaño completo. Averiguar cal dos dous tes é o primeiro paso real; o resto compara que pode expresar o teu router, non que marca é mellor.

Dous transportes, e só un ten porto

PPTP divídese en dous transportes: unha conexión de control en TCP 1723 e tramas PPP envoltas en GRE mellorado, que é o protocolo IP 47. GRE non ten número de porto, así que unha regra escrita como reenvío do porto 1723 non pode cubrilo, por moito que a interface web nomee o campo. Un router doméstico adoita ofrecer unha caixa chamada paso PPTP no canto dunha regra de protocolo, e esa caixa fai dous traballos: permite o protocolo 47 a través da devasa e ensina ao NAT a seguir o fluxo GRE. Nun router Linux esos traballos son módulos separados e regras separadas, e por iso un paso a medio configurar segue producindo unha canle de control operativa. Descubre que metade está presente antes de cambiar nada.

A devasa do propio servidor tamén debe permitir o protocolo 47 desde o enderezo do router. Unha devasa do hóspede que só acepta 1723/tcp reproduce o erro 619 desde dentro da LAN, o que fai que un reenvío roto e unha regra de hóspede rota parezan idénticos.

sudo iptables -S FORWARD | grep -i gre
sudo nft list ruleset | grep -i gre
lsmod | grep -E 'nf_conntrack_proto_gre|nf_nat_proto_gre'

Se faltan os módulos, cárgaos con sudo modprobe nf_conntrack_proto_gre nf_nat_proto_gre e fai que a carga sexa permanente, porque un reinicio que esquece o axudante converte un túnel operativo no erro 619 outra vez. A regra de reenvío só precisa aceptar o protocolo 47 cara ao enderezo do servidor, non toda a LAN. A definición de RFC 2637 separa a canle de control e a de datos, e por iso ningunha pantalla de reenvío de porto describe PPTP por completo.

Caixa de paso ou unha regra de protocolo explícita

Unha caixa de paso que só abre a devasa está máis preto do correcto que un ALG que reescribe identificadores de chamada. A metade da devasa é previsible, xa que ou se acepta o protocolo 47 ou se descarta, e os contadores din cal. A metade da reescritura é onde os fabricantes difiren, porque os identificadores de chamada de PPTP son por túnel e un NAT que os edita ten que seguir cada chamada que toca. Cando un cliente conecta e dous non, o ALG é o primeiro sospeitoso.

Unha regra de NAT de destino para o 1723 tamén ten un problema de propiedade. Se unha regra vella segue enviando o 1723 a un hóspede que deixou de executar o servidor, os paquetes caen nun porto pechado e o propio servizo PPTP do router deixa de responder, o que se le como un fallo da devasa pero en realidade é un destino obsoleto. Le a regra e o seu destino antes de engadir unha segunda. Nos routers que terminan PPTP eles mesmos, a regra WAN compite co servizo integrado, así que escolle un só propietario para o 1723 e o protocolo 47.

Dous clientes detrás do mesmo NAT son o caso que separa un reenvío simple dun enxeñoso. Reenviar o protocolo 47 sen reescribir os identificadores de chamada adoita comportarse mellor que un axudante que intenta arranxalos.

Mide o túnel antes de culpar o router

PPTP reduce a carga útil, e esa redución é aritmética, non misterio. Cada paquete do túnel leva unha cabeceira IP exterior, unha cabeceira GRE mellorada, unha cabeceira PPP e, con cifrado, unha cabeceira MPPE. Cando o camiño non pode levar a trama resultante, os paquetes pequenos pasan, o inicio de sesión complétase e a sesión detense a primeira vez que unha transferencia de ficheiros ou un salto de man TLS envía un paquete de tamaño completo.

Calcula o número en lugar de adiviñalo. O GRE mellorado custa 8 bytes, PPP custa 4, MPPE custa 4 e a cabeceira IP exterior custa 20, así que o túnel come 36 bytes antes de calquera carga. Nunha WAN PPPoE que remata en 1492, o PPP MTU máis grande que cabe é 1492 menos 36, é dicir 1456. Fixa mtu e mru nese valor nas opcións PPP e proba de novo cun ping sen fragmentación.

ping -M do -s 1464 198.51.100.7
grep -E '^(mtu|mru)' /etc/ppp/options.pptpd

O ping mide o camiño, non o túnel: 1464 bytes de carga máis 28 bytes de cabeceiras IP e ICMP enchen exactamente unha trama de 1492 bytes. Se ese ping falla, baixa o número ata que pase e resta 36 do resultado. Un MTU de túnel posto por riba do límite do camiño produce a conxelación sen unha soa liña de rexistro que mencione o tamaño.

PPTP, L2TP/IPsec ou OpenVPN no mesmo router

O mesmo router pode levar calquera dos tres túneles habituais, e a diferenza é que ten que expresar. PPTP necesita dúas regras en dúas capas distintas. L2TP sobre IPsec necesita UDP 500 e 4500 para o intercambio de claves e, salvo que NAT-T o leve, o protocolo 50 para a carga. OpenVPN necesita un só porto UDP e ningún axudante.

A columna de L2TP non é automaticamente máis amable que a de GRE. ESP é o protocolo IP 50 e tampouco ten porto, así que un router que ten problemas co protocolo 47 pode telos co protocolo 50 polo mesmo motivo. NAT-T existe para envolver ESP dentro de UDP 4500, e cando ambos os extremos o admiten a regra do protocolo 50 vólvese innecesaria. Iso é unha propiedade dos extremos, non da caixa PPTP do router. Confirma que encapsulación negociou realmente o cliente antes de escribir regras para ambos.

OpenVPN é a opción con menos pezas móbiles no lado do router. Un porto UDP, un reenvío, ningún axudante de seguimento de conexións e ningunha reescritura de identificadores de chamada. O intercambio é un cliente que hai que instalar en lugar dun marcador integrado, e a miúdo é a única razón pola que PPTP segue na conversa.

Que reparar e que substituír

Arranxar o reenvío e o MTU dache un túnel que funciona, non un que debas conservar. A autenticación MSCHAPv2 de PPTP é atacable desde hai anos, e un túnel operativo move credenciais que se poden recuperar sen conexión. Se o dispositivo remoto pode executar L2TP/IPsec ou OpenVPN, trata a reparación como unha medida temporal con data.

A decisión redúcese a que admite o extremo afastado e canto ten que durar o arranxo. Un aparello antigo que só fala PPTP recibe a reparación; todo o que poida instalar un cliente migra.

Antes de pechar o tícket, confirma que o cliente sobrevive a unha transferencia grande e non só a un inicio de sesión, e que o router segue mantendo a súa regra do protocolo 47 tras un reinicio. Un túnel que pasa unha copia de ficheiro e morre tras a seguinte actualización de firmware nunca estivo rematado.