PPTP se conectează și apoi se blochează în spatele Linux NAT: ajutorul GRE

Cineva redirecționează 1723, clientul ajunge la server, începe autentificarea și apoi totul se oprește fără eroare. Concluzia naturală este o parolă greșită, așa că parola este tastată din nou de trei ori. Redirecționarea era în regulă și credențialele erau în regulă. Ce s-a stricat este un al doilea protocol pe care redirecționarea nu l-a acoperit niciodată, și o valoare implicită a nucleului care a încetat în tăcere să mai ajute cu el.

Redirecționarea nu a fost niciodată problema

O regulă de redirecționare a portului descrie trafic TCP sau UDP. Nu poate descrie o încărcătură care trece la alt protocol IP la mijlocul unei sesiuni, iar PPTP face exact asta.

De aceea conexiunea pare sănătoasă până în momentul în care se blochează. Partea pe care o regulă de port o poate guverna a reușit, iar partea pe care nu o poate guverna este partea care a eșuat.

TCP pentru control, GRE pentru date

Apelul este negociat prin TCP 1723. Odată stabilit, încărcătura trece în GRE, protocolul IP 47, care nu poartă niciun număr de port. O regulă bazată pe porturi nu are cu ce să se potrivească.

Ce transportă GRE este un identificator de apel în antetul său, iar traducătorul NAT trebuie să rescrie acel câmp consecvent în ambele direcții, altfel cele două jumătăți ale sesiunii încetează să mai fie de acord. O direcție rescrisă și cealaltă nu produce o sesiune care se autentifică și apoi aruncă fiecare pachet de date. Exact aceasta este forma simptomului: succes, apoi tăcere.

GRE gol fără PPTP nu are nevoie de o astfel de rescriere, de aceea un tunel GRE simplu poate funcționa printr-un router care eșuează pentru un client PPTP pe aceeași cale.

Patru module și un sysctl care le-a oprit

Două module se ocupă de încadrare, nf_conntrack_proto_gre și nf_nat_proto_gre. Alte două se ocupă de identificatorul de apel, nf_conntrack_pptp și nf_nat_pptp. Încărcarea ultimului le atrage pe celelalte prin dependențe, așa că o listă de module ar trebui să le arate pe toate patru.

Instrucțiunile mai vechi folosesc un prefix ip_ din epoca 2.6. Acele comenzi pot părea că rulează fără să încarce nimic, așa că verificați lista încărcată în locul stării de ieșire.

Faptul că sunt încărcate nu mai este suficient. Din Linux 4.7 sysctl net.netfilter.nf_conntrack_helper este 0 implicit, ceea ce dezactivează atribuirea automată a ajutorului pentru fluxurile noi. Un router poate avea toate modulele și totuși să nu traducă nimic. Verificați valoarea efectivă înainte de a privi din nou lista de module.

Fie reactivați atribuirea automată la nivel global, fie atașați ajutorul la fluxurile care au nevoie de el și lăsați restul în pace:

iptables -t raw -A PREROUTING -p tcp --dport 1723 -j CT --helper pptp

A doua opțiune este de preferat. Limitează comportamentul la traficul PPTP în loc să reactiveze atribuirea automată pe tot routerul.

Deschiderea unui protocol care nu are porturi

O regulă de firewall care permite 1723 nu spune nimic despre protocolul 47. În firewalld, permiteți protocolul în zona orientată spre client. În iptables simplu, acceptați protocolul gre în lanțul de intrare.

Apoi capturați pe ambele părți. Pachetele care pleacă de la client fără să sosească răspunsuri înseamnă că calea de întoarcere este filtrată, iar aceasta este o defecțiune diferită de o credențială respinsă.

După conectare, limita de dimensiune

GRE inserează un antet, iar PPP din interior adaugă mai mult, așa că o legătură funcțională raportează o MTU mult sub 1500. Răspunsurile mici se încarcă și cele mari se blochează, ceea ce pare o a doua problemă fără legătură care apare în momentul în care prima este rezolvată.

Citiți MTU pe adaptorul PPP al clientului și puneți-l în acord cu calculul propriu al routerului în loc să coborâți numerele până când ceva funcționează. Pachetele de dimensiune completă care pleacă și nu se întorc indică acea limită, nu traducerea.

Repararea căii îl readuce pe utilizator la lucru, și nu face din PPTP o alegere bună. MS-CHAPv2 și RC4 sunt demult învechite, așa că tratați încărcarea modulelor ca o corectare temporară și planificați trecerea la un protocol întreținut.