PPTP-bediener agter 'n tuisdirigent: herstel eers 1723 en GRE

PPTP agter 'n tuisdirigent misluk op twee onverwante maniere, en om hulle te verwar mors 'n aand. Een fout is 'n deurgewing-gaping: die dirigeerder laat TCP 1723 deur en laat IP-protokol 47 val, so die kliënt hang by fout 619. Die ander is 'n grote-probleem: die tonnel kom op, verifieer, en vries dan wanneer 'n volgrootte pakket moet deur. Om uit te werk watter een jy het, is die eerste werklike stap; die res vergelyk wat jou dirigeerder kan uitdruk, nie watter handelsmerk beter is nie.

Twee vervoerlae, en net een van hulle het 'n poort

PPTP splits in twee vervoerlae: 'n beheerverbinding op TCP 1723, en PPP-raampies verpak in verbeterde GRE, wat IP-protokol 47 is. GRE het geen poortnommer nie, so 'n reël wat as deurstuur-poort 1723 geskryf is, kan dit nie dek nie, maak nie saak hoe die webkoppelvlak die veld bewoord nie. 'n Verbruikersdirigeerder bied gewoonlik 'n kontroleblokkie met die naam PPTP-deurlaat in plaas van 'n protokolreël, en daardie blokkie doen twee take: dit laat protokol 47 deur die brandmuur, en dit leer NAT hoe om die GRE-vloei te volg. Op 'n Linux-dirigeerder is daardie take aparte modules en aparte reëls, wat is waarom 'n half-opgestelde deurlaat steeds 'n werkende beheerkanaal lewer. Vind uit watter helfte teenwoordig is voordat jy iets verander.

Die bediener se eie brandmuur moet ook protokol 47 vanaf die dirigeerder-adres toelaat. 'n Gasheer-brandmuur wat net 1723/tcp aanvaar, herhaal fout 619 van binne die LAN, wat 'n stukkende deurgewing en 'n stukkende gasheer-reël identies laat lyk.

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'

As die modules ontbreek, laai hulle met sudo modprobe nf_conntrack_proto_gre nf_nat_proto_gre en maak die las blywend, want 'n herbegin wat die helper vergeet, verander 'n werkende tonnel terug in fout 619. Die deurgewing-reël hoef net protokol 47 na die bediener-adres te aanvaar, nie die hele LAN nie. Die RFC 2637-definisie skei die beheer- en datapaaie, wat is waarom geen enkele poortdeurstuur-skerm PPTP volledig beskryf nie.

Deurlaat-kontroleblokkie of 'n eksplisiete protokolreël

'n Deurlaat-kontroleblokkie wat net die brandmuur oopmaak, is nader aan korrek as 'n ALG wat oproep-identifiseerders herskryf. Die brandmuur-helfte is voorspelbaar, want of protokol 47 word aanvaar of dit word laat val, en die tellers sê watter een. Die herskryf-helfte is waar verskaffers verskil, want PPTP se oproep-identifiseerders is per tonnel en 'n NAT wat hulle redigeer, moet elke oproep volg wat hy raak. Wanneer een kliënt verbind en twee nie, is die ALG die eerste verdagte.

'n Bestemming-NAT-reël vir 1723 het ook 'n eienaarskap-probleem. As 'n verouderde reël 1723 nog na 'n gasheer stuur wat die bediener gestop het, beland pakkette op 'n geslote poort en die dirigeerder se eie PPTP-diens hou op antwoord, wat soos 'n brandmuur-fout lees maar eintlik 'n verouderde teiken is. Lees die reël en sy bestemming voordat jy 'n tweede byvoeg. Op dirigeerders wat self PPTP termineer, kompeteer die WAN-reël met die ingeboude diens, so kies een eienaar vir 1723 en protokol 47.

Twee kliënte agter dieselfde NAT is die geval wat 'n gewone deurgewing van 'n slim een skei. Om protokol 47 deur te stuur sonder om oproep-identifiseerders te herskryf, werk gewoonlik beter as 'n helper wat probeer om hulle reg te maak.

Meet die tonnel voordat jy die dirigeerder blameer

PPTP krimp die bruikbare loonvrag, en die krimping is rekenkunde eerder as raaisel. Elke tonnelpakket dra 'n buitenste IP-opskrif, 'n verbeterde GRE-opskrif, 'n PPP-opskrif en, met enkripsie, 'n MPPE-opskrif. Wanneer die pad nie die resulterende raam kan dra nie, gaan klein pakkette deur, die aanmelding voltooi, en die sessie staak die eerste keer wanneer 'n lêeroordrag of 'n TLS-handdruk 'n volgrootte pakket stuur.

Werk die getal uit in plaas daarvan om te raai. Verbeterde GRE kos 8 grepe, PPP kos 4, MPPE kos 4, en die buitenste IP-opskrif kos 20, so die tonnel eet 36 grepe voordat enige loonvrag begin. Op 'n PPPoE-WAN wat op 1492 eindig, is die grootste PPP-MTU wat pas 1492 minus 36, dit is 1456. Stel mtu en mru op daardie waarde in die PPP-opsies en toets weer met 'n nie-fragmenteerende ping.

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

Die ping meet die pad, nie die tonnel nie: 1464 grepe loonvrag plus 28 grepe IP- en ICMP-opskrifte vul 'n raam van 1492 grepe presies. As daardie ping misluk, verlaag die getal totdat dit deurkom en trek 36 van die resultaat af. 'n Tonnel-MTU wat bo die padlimiet gestel is, lewer die vriesing sonder enige logreël wat grootte noem.

PPTP, L2TP/IPsec of OpenVPN op dieselfde dirigeerder

Dieselfde dirigeerder kan enige van die drie algemene tonnele dra, en die verskil is wat hy moet uitdruk. PPTP het twee reëls in twee verskillende lae nodig. L2TP oor IPsec het UDP 500 en 4500 vir die sleuteluitruiling nodig en, tensy NAT-T dit dra, protokol 50 vir die loonvrag. OpenVPN het een UDP-poort en glad geen helper nodig nie.

Die L2TP-kolom is nie outomaties vriendeliker as GRE nie. ESP is IP-protokol 50 en het ook geen poort nie, so 'n dirigeerder wat met protokol 47 sukkel, kan om dieselfde rede met protokol 50 sukkel. NAT-T bestaan om ESP binne UDP 4500 te verpak, en wanneer albei kante dit ondersteun, word die protokol-50-reël onnodig. Dit is 'n eienskap van die eindpunte, nie van die dirigeerder se PPTP-kontroleblokkie nie. Bevestig watter inkapseling die kliënt werklik beding het voordat jy reëls vir albei skryf.

OpenVPN is die opsie met die minste bewegende dele aan die dirigeerder-kant. Een UDP-poort, een deurgewing, geen verbindingvolg-helper en geen herskrywing van oproep-identifiseerders nie. Die ruil is 'n kliënt wat geïnstalleer moet word eerder as 'n ingeboude kieser, wat dikwels die enigste rede is waarom PPTP in die gesprek bly.

Wat om te herstel en wat om te vervang

Om die deurgewing en die MTU reg te maak, gee jou 'n tonnel wat werk, nie een wat jy moet hou nie. PPTP se MSCHAPv2-verifikasie is al jare aanvalbaar, en 'n werkende tonnel beweeg geloofsbriewe wat aanlyn teruggewin kan word. As die afgeleë toestel L2TP/IPsec of OpenVPN kan hardloop, hanteer die herstel as 'n tydelike maatreël met 'n datum daarop.

Die besluit kom neer op wat die ver kant ondersteun en hoe lank die reëling moet hou. 'n Erfenistoestel wat net PPTP praat, kry die herstel; enigiets wat 'n kliënt kan installeer, word gemigreer.

Voordat jy die kaartjie sluit, bevestig dat die kliënt 'n groot oordrag oorleef eerder as 'n aanmelding, en dat die dirigeerder steeds sy protokol-47-reël hou ná 'n herbegin. 'n Tonnel wat een lêerkopie slaag en sterf ná die volgende firmware-opdatering, was nooit klaar nie.