PPTP-server bakom en hemrouter: åtgärda 1723 och GRE först
Kör PPTP bakom en hemrouter: TCP 1723, IP-protokoll 47, genomströmningsrutan och MTU-aritmetiken, plus när L2TP eller OpenVPN är det bättre bytet.
PPTP bakom en hemrouter misslyckas på två oberoende sätt, och att blanda ihop dem kostar en hel kväll. Det ena felet är en lucka i vidarebefordran: routern släpper igenom TCP 1723 och kastar IP-protokoll 47, så klienten hänger på fel 619. Det andra är ett storleksproblem: tunneln kommer upp, autentiserar och fryser sedan när ett paket i full storlek måste passera. Att ta reda på vilket av dem du har är det första riktiga steget; resten jämför vad din router kan uttrycka, inte vilket märke som är bättre.
Två transportvägar, och bara en av dem har en port
PPTP delar sig i två transportvägar: en kontrollanslutning på TCP 1723 och PPP-ramar paketerade i utökad GRE, vilket är IP-protokoll 47. GRE har inget portnummer, så en regel skriven som vidarebefordran av port 1723 kan inte täcka den, hur webbgränssnittet än namnger fältet. En hemrouter erbjuder vanligtvis en ruta som heter PPTP-genomströmning i stället för en protokollregel, och den rutan gör två saker: den släpper igenom protokoll 47 genom brandväggen och den lär NAT att följa GRE-flödet. På en Linux-router är dessa uppgifter separata moduler och separata regler, och därför ger en halvkonfigurerad genomströmning fortfarande en fungerande kontrollkanal. Ta reda på vilken halva som finns innan du ändrar något.
Serverns egen brandvägg måste också tillåta protokoll 47 från routerns adress. En värdbrandvägg som bara accepterar 1723/tcp återskapar fel 619 inifrån LAN, vilket gör att en trasig vidarebefordran och en trasig värdregel ser identiska ut.
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'
Om modulerna saknas, ladda dem med sudo modprobe nf_conntrack_proto_gre nf_nat_proto_gre och gör laddningen beständig, eftersom en omstart som glömmer hjälparen gör en fungerande tunnel till fel 619 igen. Vidarebefordringsregeln behöver bara tillåta protokoll 47 mot serverns adress, inte hela LAN. Definitionen i RFC 2637 skiljer kontroll- och datavägen, och därför beskriver ingen enskild skärm för portvidarebefordran PPTP fullt ut.
Genomströmningsruta eller en uttrycklig protokollregel
En genomströmningsruta som bara öppnar brandväggen är närmare det rätta än en ALG som skriver om anrops-ID:n. Brandväggshalvan är förutsägbar, eftersom protokoll 47 antingen accepteras eller kastas, och räknarna visar vilket. Omskrivningshalvan är där tillverkarna skiljer sig, eftersom PPTP:s anrops-ID:n är per tunnel och en NAT som redigerar dem måste följa varje anrop den rör. När en klient ansluter och två inte, är ALG:n den första misstänkta.
En destinations-NAT-regel för 1723 har också ett ägarproblem. Om en gammal regel fortfarande skickar 1723 till en värd som slutade köra servern, landar paketen på en stängd port och routerns egen PPTP-tjänst slutar svara, vilket läses som ett brandväggsfel men egentligen är ett inaktuellt mål. Läs regeln och dess destination innan du lägger till en andra. På routrar som själva avslutar PPTP konkurrerar WAN-regeln med den inbyggda tjänsten, så välj en ägare för 1723 och protokoll 47.
Två klienter bakom samma NAT är fallet som skiljer en enkel vidarebefordran från en smart. Att vidarebefordra protokoll 47 utan att skriva om anrops-ID:n beter sig oftast bättre än en hjälpare som försöker rätta dem.
Mät tunneln innan du skyller på routern
PPTP krymper den användbara nyttolasten, och krympningen är aritmetik, inte mystik. Varje tunnelpaket bär ett yttre IP-huvud, ett utökat GRE-huvud, ett PPP-huvud och, med kryptering, ett MPPE-huvud. När vägen inte kan bära den resulterande ramen går små paket igenom, inloggningen fullbordas, och sessionen stannar första gången en filöverföring eller ett TLS-handskakning skickar ett paket i full storlek.
Räkna ut talet i stället för att gissa. Utökad GRE kostar 8 byte, PPP kostar 4, MPPE kostar 4, och det yttre IP-huvudet kostar 20, så tunneln äter 36 byte före någon nyttolast. På ett PPPoE-WAN som slutar på 1492 är den största PPP-MTU som får plats 1492 minus 36, alltså 1456. Ställ in mtu och mru på det värdet i PPP-inställningarna och testa igen med en ping utan fragmentering.
ping -M do -s 1464 198.51.100.7
grep -E '^(mtu|mru)' /etc/ppp/options.pptpd
Pingen mäter vägen, inte tunneln: 1464 byte nyttolast plus 28 byte IP- och ICMP-huvuden fyller exakt en ram på 1492 byte. Om den pingen misslyckas, sänk talet tills den går igenom och dra av 36 från resultatet. En tunnel-MTU satt över vägens gräns ger frysningen utan en enda logglinje som nämner storlek.
PPTP, L2TP/IPsec eller OpenVPN på samma router
Samma router kan bära vilken som helst av de tre vanliga tunnelerna, och skillnaden är vad den måste uttrycka. PPTP behöver två regler i två olika lager. L2TP över IPsec behöver UDP 500 och 4500 för nyckelutbytet och, om inte NAT-T bär det, protokoll 50 för nyttolasten. OpenVPN behöver en UDP-port och ingen hjälpare alls.
| Tunnel | What the router must allow | Practical note |
|---|---|---|
| PPTP | TCP 1723 and IP protocol 47 | Two transports, two rules |
| L2TP/IPsec | UDP 500, UDP 4500, protocol 50 without NAT-T | ESP has no port either |
| OpenVPN | UDP 1194 or a chosen TCP port | Single rule, no helper |
L2TP-kolumnen är inte automatiskt vänligare än GRE. ESP är IP-protokoll 50 och har inte heller någon port, så en router som har svårt med protokoll 47 kan ha svårt med protokoll 50 av samma skäl. NAT-T finns för att packa in ESP i UDP 4500, och när båda ändarna stöder det blir protokoll-50-regeln onödig. Det är en egenskap hos ändpunkterna, inte hos routerns PPTP-ruta. Bekräfta vilken inkapsling klienten faktiskt förhandlade fram innan du skriver regler för båda.
OpenVPN är alternativet med minst rörliga delar på routersidan. En UDP-port, en vidarebefordran, ingen anslutningsspårningshjälpare och ingen omskrivning av anrops-ID:n. Bytet är en klient som måste installeras i stället för en inbyggd uppringare, och det är ofta den enda anledningen till att PPTP stannar i samtalet.
Vad som ska repareras och vad som ska bytas ut
Att rätta vidarebefordran och MTU:n ger dig en tunnel som fungerar, inte en du borde behålla. PPTP:s MSCHAPv2-autentisering har varit angripbar i åratal, och en fungerande tunnel flyttar autentiseringsuppgifter som kan återställas offline. Om fjärrenheten kan köra L2TP/IPsec eller OpenVPN, behandla reparationen som en tillfällig åtgärd med ett datum.
Beslutet beror på vad den andra änden stöder och hur länge arrangemanget måste hålla. En gammal apparat som bara talar PPTP får reparationen; allt som kan installera en klient migreras.
Innan du stänger ärendet, bekräfta att klienten överlever en stor överföring och inte bara en inloggning, och att routern fortfarande håller sin protokoll-47-regel efter en omstart. En tunnel som klarar en filkopia och dör efter nästa firmwareuppdatering blev aldrig färdig.