Server PPTP în spatele unui router de acasă: repară mai întâi 1723 și GRE

PPTP în spatele unui router de acasă eșuează în două moduri fără legătură, iar confundarea lor costă o seară întreagă. O defecțiune este o lipsă în redirecționare: routerul lasă TCP 1723 să treacă și aruncă protocolul IP 47, așa că clientul rămâne blocat la eroarea 619. Cealaltă este o problemă de dimensiune: tunelul urcă, se autentifică și apoi îngheață când trebuie să treacă un pachet de dimensiune completă. Să afli care dintre ele este la tine este primul pas real; restul compară ce poate routerul tău să exprime, nu care marcă este mai bună.

Două transporturi, și doar unul are port

PPTP se împarte în două transporturi: o conexiune de control pe TCP 1723 și cadre PPP înfășurate în GRE extins, adică protocolul IP 47. GRE nu are număr de port, deci o regulă scrisă ca redirecționare a portului 1723 nu îl poate acoperi, oricum ar numi interfața web câmpul. Un router de acasă oferă de obicei o căsuță numită passthrough PPTP în locul unei reguli de protocol, iar căsuța face două lucruri: lasă protocolul 47 să treacă prin firewall și învață NAT-ul să urmărească fluxul GRE. Pe un router Linux aceste sarcini sunt module separate și reguli separate, de aceea un passthrough pe jumătate configurat produce totuși un canal de control funcțional. Află care jumătate există înainte de a schimba ceva.

Firewall-ul serverului însuși trebuie să permită și el protocolul 47 de la adresa routerului. Un firewall de host care acceptă doar 1723/tcp reproduce eroarea 619 din interiorul LAN-ului, ceea ce face ca o redirecționare stricată și o regulă de host stricată să arate identic.

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'

Dacă modulele lipsesc, încarcă-le cu sudo modprobe nf_conntrack_proto_gre nf_nat_proto_gre și fă încărcarea permanentă, fiindcă o repornire care uită ajutorul transformă un tunel funcțional din nou în eroarea 619. Regula de redirecționare trebuie să accepte protocolul 47 doar spre adresa serverului, nu tot LAN-ul. Definiția din RFC 2637 separă calea de control de cea de date, de aceea niciun singur ecran de redirecționare a porturilor nu descrie PPTP complet.

Căsuță de passthrough sau regulă de protocol explicită

O căsuță de passthrough care doar deschide firewall-ul este mai aproape de corect decât un ALG care rescrie identificatorii de apel. Jumătatea de firewall este previzibilă, fiindcă protocolul 47 este fie acceptat, fie aruncat, iar contoarele spun care. Jumătatea de rescriere este locul unde producătorii diferă, fiindcă identificatorii de apel ai PPTP sunt pentru fiecare tunel, iar un NAT care îi editează trebuie să urmărească fiecare apel pe care îl atinge. Când un client se conectează și doi nu, ALG-ul este primul suspect.

O regulă NAT de destinație pentru 1723 are și ea o problemă de proprietate. Dacă o regulă veche încă trimite 1723 către un host care a oprit serverul, pachetele ajung pe un port închis, iar serviciul PPTP al routerului încetează să răspundă, ceea ce se citește ca o defecțiune a firewall-ului, dar în realitate este o țintă învechită. Citește regula și destinația ei înainte de a adăuga una nouă. Pe routerele care termină ele însele PPTP, regula WAN concurează cu serviciul încorporat, așa că alege un singur proprietar pentru 1723 și protocolul 47.

Doi clienți în spatele aceluiași NAT sunt cazul care separă o redirecționare simplă de una isteață. Redirecționarea protocolului 47 fără rescrierea identificatorilor de apel se comportă de obicei mai bine decât un ajutor care încearcă să îi corecteze.

Măsoară tunelul înainte de a da vina pe router

PPTP micșorează încărcătura utilă, iar micșorarea este aritmetică, nu mister. Fiecare pachet al tunelului poartă un antet IP exterior, un antet GRE extins, un antet PPP și, cu criptare, un antet MPPE. Când calea nu poate transporta cadrul rezultat, pachetele mici trec, autentificarea se încheie, iar sesiunea se oprește prima dată când un transfer de fișier sau un handshake TLS trimite un pachet de dimensiune completă.

Calculează numărul în loc să îl ghicești. GRE extins costă 8 octeți, PPP costă 4, MPPE costă 4, iar antetul IP exterior costă 20, deci tunelul mănâncă 36 de octeți înainte de orice încărcătură. Pe un WAN PPPoE care se termină la 1492, cel mai mare PPP MTU care încape este 1492 minus 36, adică 1456. Setează mtu și mru la acea valoare în opțiunile PPP și testează din nou cu un ping fără fragmentare.

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

Ping-ul măsoară calea, nu tunelul: 1464 de octeți de încărcătură plus 28 de octeți de antete IP și ICMP umplu exact un cadru de 1492 de octeți. Dacă acel ping eșuează, scade numărul până trece și scade 36 din rezultat. Un MTU al tunelului setat peste limita căii produce înghețarea fără nicio linie de jurnal care să menționeze dimensiunea.

PPTP, L2TP/IPsec sau OpenVPN pe același router

Același router poate transporta oricare dintre cele trei tuneluri obișnuite, iar diferența este ce trebuie să exprime. PPTP are nevoie de două reguli în două straturi diferite. L2TP peste IPsec are nevoie de UDP 500 și 4500 pentru schimbul de chei și, dacă NAT-T nu îl transportă, de protocolul 50 pentru încărcătură. OpenVPN are nevoie de un singur port UDP și de niciun ajutor.

Coloana L2TP nu este automat mai prietenoasă decât GRE. ESP este protocolul IP 50 și nici el nu are port, așa că un router care are dificultăți cu protocolul 47 poate avea dificultăți cu protocolul 50 din același motiv. NAT-T există ca să înfășoare ESP în UDP 4500, iar când ambele capete îl susțin, regula protocolului 50 devine inutilă. Aceasta este o proprietate a capetelor, nu a căsuței PPTP a routerului. Confirmă ce encapsulare a negociat de fapt clientul înainte de a scrie reguli pentru ambele.

OpenVPN este opțiunea cu cele mai puține piese mobile pe partea routerului. Un port UDP, o redirecționare, niciun ajutor de urmărire a conexiunilor și nicio rescriere a identificatorilor de apel. Schimbul este un client care trebuie instalat în locul unui apelant încorporat, iar asta este adesea singurul motiv pentru care PPTP rămâne în discuție.

Ce să repari și ce să înlocuiești

Repararea redirecționării și a MTU-ului îți dă un tunel care funcționează, nu unul pe care ar trebui să îl păstrezi. Autentificarea MSCHAPv2 a PPTP este atacabilă de ani de zile, iar un tunel funcțional transportă date de autentificare care pot fi recuperate offline. Dacă dispozitivul de la distanță poate rula L2TP/IPsec sau OpenVPN, tratează reparația ca o măsură temporară cu o dată.

Decizia se reduce la ce suportă capătul îndepărtat și cât timp trebuie să reziste aranjamentul. Un aparat vechi care vorbește doar PPTP primește reparația; tot ce poate instala un client este migrat.

Înainte de a închide tichetul, confirmă că clientul supraviețuiește unui transfer mare și nu doar unei autentificări, și că routerul își păstrează regula protocolului 47 după o repornire. Un tunel care trece o copie de fișier și moare după următoarea actualizare de firmware nu a fost niciodată terminat.