PPTP bag en hjemmerouter fejler på to uafhængige måder, og at blande dem sammen koster en hel aften. Den ene fejl er et hul i videresendelsen: routeren sender TCP 1723 igennem og dropper IP-protokol 47, så klienten hænger på fejl 619. Den anden er et størrelsesproblem: tunnelen kommer op, godkender, og fryser derefter, når en pakke i fuld størrelse skal passere. At finde ud af, hvilken af dem du har, er det første rigtige skridt; resten sammenligner, hvad din router kan udtrykke, ikke hvilket mærke der er bedre.

To transportveje, og kun den ene har en port

PPTP deler sig i to transportveje: en kontrolforbindelse på TCP 1723 og PPP-rammer pakket i forbedret GRE, som er IP-protokol 47. GRE har ikke noget portnummer, så en regel skrevet som videresend port 1723 kan ikke dække den, uanset hvordan webgrænsefladen formulerer feltet. En forbrugerrouter tilbyder normalt et felt med navnet PPTP-gennemløb i stedet for en protokolregel, og det felt gør to ting: det lukker protokol 47 gennem firewalling og lærer NAT at følge GRE-strømmen. På en Linux-router er de opgaver separate moduler og separate regler, og derfor giver et halvt konfigureret gennemløb stadig en fungerende kontrolkanal. Find ud af, hvilken halvdel der er til stede, før du ændrer noget.

Serverens egen firewall skal også tillade protokol 47 fra routerens adresse. En vært-firewall, der kun accepterer 1723/tcp, gengiver fejl 619 indefra LAN'et, hvilket får en brudt videresendelse og en brudt værtregel til at se ens ud.

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'

Hvis modulerne mangler, så indlæs dem med sudo modprobe nf_conntrack_proto_gre nf_nat_proto_gre og gør indlæsningen permanent, fordi en genstart, der glemmer hjælperen, gør en fungerende tunnel til fejl 619 igen. Videresendelsesreglen skal kun acceptere protokol 47 mod serverens adresse, ikke hele LAN'et. Definitionen i RFC 2637 adskiller kontrol- og datastien, og derfor beskriver ingen enkelt portvideresendelsesskærm PPTP fuldt ud.

Gennemløbsfelt eller en udtrykkelig protokolregel

Et gennemløbsfelt, der kun åbner firewalling, er tættere på det rigtige end en ALG, der omskriver opkalds-id'er. Firewall-halvdelen er forudsigelig, fordi protokol 47 enten accepteres eller droppes, og tællerne viser hvilket. Omskrivningshalvdelen er der, hvor leverandører adskiller sig, fordi PPTP-opkalds-id'er er per tunnel, og en NAT, der redigerer dem, skal følge hvert opkald, den rører. Når én klient forbinder og to ikke, er ALG'en den første mistænkte.

En destinations-NAT-regel for 1723 har også et ejerproblem. Hvis en gammel regel stadig sender 1723 til en vært, der stoppede serveren, lander pakkerne på en lukket port, og routerens egen PPTP-tjeneste holder op med at svare, hvilket læses som en firewallfejl, men i virkeligheden er et forældet mål. Læs reglen og dens destination, før du tilføjer en anden. På routere, der selv afslutter PPTP, konkurrerer WAN-reglen med den indbyggede tjeneste, så vælg én ejer til 1723 og protokol 47.

To klienter bag samme NAT er det tilfælde, der skiller en simpel videresendelse fra en smart. At videresende protokol 47 uden at omskrive opkalds-id'er opfører sig normalt bedre end en hjælper, der prøver at rette dem.

Mål tunnelen, før du giver routeren skylden

PPTP krymper den brugbare nyttelast, og krympningen er aritmetik, ikke mystik. Hver tunnelpakke bærer et ydre IP-hoved, et forbedret GRE-hoved, et PPP-hoved og, med kryptering, et MPPE-hoved. Når stien ikke kan bære den resulterende ramme, går små pakker igennem, login fuldføres, og sessionen går i stå første gang, en filoverførsel eller et TLS-håndtryk sender en pakke i fuld størrelse.

Regn tallet ud i stedet for at gætte. Forbedret GRE koster 8 byte, PPP koster 4, MPPE koster 4, og det ydre IP-hoved koster 20, så tunnelen spiser 36 byte, før der er nogen nyttelast. På et PPPoE-WAN, der slutter på 1492, er den største PPP-MTU, der passer, 1492 minus 36, altså 1456. Sæt mtu og mru til den værdi i PPP-indstillingerne, og test igen med en ping uden fragmentering.

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

Pinget måler stien, ikke tunnelen: 1464 byte nyttelast plus 28 byte IP- og ICMP-hoveder fylder præcis en ramme på 1492 byte. Hvis det ping fejler, så sænk tallet, indtil det går igennem, og træk 36 fra resultatet. En tunnel-MTU sat over stiens grænse giver frysningen uden en eneste loglinje, der nævner størrelse.

PPTP, L2TP/IPsec eller OpenVPN på samme router

Den samme router kan bære enhver af de tre almindelige tunneler, og forskellen er, hvad den skal udtrykke. PPTP kræver to regler i to forskellige lag. L2TP over IPsec kræver UDP 500 og 4500 til nøgleudvekslingen og, medmindre NAT-T bærer det, protokol 50 til nyttelasten. OpenVPN kræver én UDP-port og ingen hjælper overhovedet.

TunnelWhat the router must allowPractical note
PPTPTCP 1723 and IP protocol 47Two transports, two rules
L2TP/IPsecUDP 500, UDP 4500, protocol 50 without NAT-TESP has no port either
OpenVPNUDP 1194 or a chosen TCP portSingle rule, no helper

L2TP-kolonnen er ikke automatisk venligere end GRE. ESP er IP-protokol 50 og har heller ingen port, så en router, der har svært ved protokol 47, kan have svært ved protokol 50 af samme grund. NAT-T findes for at pakke ESP ind i UDP 4500, og når begge ender understøtter det, bliver protokol-50-reglen unødvendig. Det er en egenskab ved endepunkterne, ikke ved routerens PPTP-felt. Bekræft, hvilken indkapsling klienten faktisk forhandlede, før du skriver regler for begge.

OpenVPN er muligheden med færrest bevægelige dele på routersiden. Én UDP-port, én videresendelse, ingen forbindelsessporingshjælper og ingen omskrivning af opkalds-id'er. Bytter er en klient, der skal installeres i stedet for en indbygget opkobler, og det er ofte den eneste grund til, at PPTP bliver i samtalen.

Hvad du skal reparere, og hvad du skal udskifte

At rette videresendelsen og MTU'en giver dig en tunnel, der virker, ikke en du bør beholde. PPTP's MSCHAPv2-godkendelse har været angribelig i årevis, og en fungerende tunnel flytter legitimationsoplysninger, der kan gendannes offline. Hvis den fjernede enhed kan køre L2TP/IPsec eller OpenVPN, så behandl reparationen som en midlertidig foranstaltning med en dato på.

Beslutningen handler om, hvad den fjerne ende understøtter, og hvor længe ordningen skal holde. Et ældre apparat, der kun taler PPTP, får reparationen; alt, der kan installere en klient, bliver migreret.

Før du lukker sagen, så bekræft, at klienten overlever en stor overførsel og ikke bare et login, og at routeren stadig holder sin protokol-47-regel efter en genstart. En tunnel, der klarer én filkopi og dør efter den næste firmwareopdatering, blev aldrig færdig.

Relaterede artikler