Eșecurile de scriere GRE pe pptpd nu sunt o problemă de parolă

Eșec de scriere GRE în jurnal, iar primul instinct este să resetați parola utilizatorului. Acel instinct este aproape întotdeauna greșit. Aceste mesaje descriu calea datelor, nu verificarea acreditărilor: clientul s-ar putea să se fi autentificat cu succes și apoi să fi rămas blocat în etapa în care se înregistrează în rețea. Două mesaje diferite indică două defecțiuni diferite, iar niciuna nu se rezolvă cu o parolă nouă.

Două mesaje, două defecțiuni diferite

Un eșec de citire înseamnă că pachetele GRE nu ajung niciodată la demon sau sunt aruncate la intrare. Conexiunea de control poate părea perfect sănătoasă în timp ce nimic nu traversează calea datelor. Autentificarea este singurul lucru care a funcționat în mod dovedit.

Un eșec de scriere înseamnă de obicei că sesiunea a negociat ceva ce nucleul sau clientul nu pot folosi. Canalul de control s-a încheiat, iar opțiunile convenite în acel schimb nu corespund cu ceea ce punctele finale pot face de fapt. Este o neînțelegere de configurare, nu un eveniment de autentificare.

Citiți care dintre cele două apare înainte de a schimba ceva. Ele vă duc la straturi diferite, iar tratarea lor ca un singur simptom este motivul pentru care același server este corectat de două ori din motive fără legătură. Linia din jurnal este singura diagnosticare gratuită pe care o primiți.

Protocolul 47 nu este portul 47

PPTP folosește TCP 1723 pentru a stabili apelul și GRE pentru a transporta încărcătura utilă. GRE este protocolul IP 47, nu un număr de port, așa că o regulă de firewall care deschide portul 47 nu permite nimic util.

Un router pe cale are nevoie de o funcție passthrough PPTP sau de o permisiune GRE explicită. Fără ea, strângerea de mână TCP se încheie și tunelul nu transportă niciodată un pachet, ceea ce produce exact eșecul de citire de mai sus. Regulile pentru portul 47 într-un firewall sunt cea mai des irosită după-amiază din acest protocol.

Urmăriți ambele direcții simultan pe server în loc să ghiciți care parte aruncă traficul: tcpdump -ni any port 1723 or proto gre.

Dacă 1723 arată stabilirea apelului în timp ce GRE rămâne tăcut, blocarea este deasupra gazdei. Dacă GRE ajunge și demonul încă eșuează, problema este locală, iar opțiunile sunt următorul loc de verificat.

Permiteți GRE acolo unde gazda redirecționează cu adevărat

Inserarea unei reguli forward pentru GRE este un test rezonabil pe o gazdă care redirecționează trafic de tunel și nu este o politică. O regulă de test care acceptă totul dintr-un protocol este o diagnosticare, nu un proiect. Lăsați-o suficient de mult pentru a învăța ceva, apoi înlocuiți-o cu o regulă limitată.

Adăugați o regulă input pentru pachetele adresate serverului însuși, deoarece lanțul forward nu le vede. Apoi priviți contoarele regulii înainte și după o încercare de conectare, ceea ce vă spune dacă pachetele ajung.

Faceți regula persistentă prin serviciul de firewall al distribuției în loc să o rulați din nou după fiecare repornire. Pe o gazdă nftables, potriviți ip protocol gre atât în lanțul input, cât și în cel forward.

Confirmați că modulul ppp_generic este și el încărcat și verificați dacă urmărirea conexiunilor aruncă direcția de retur. Ambele produc eșecuri care par o problemă de firewall și nu sunt. Un modul de nucleu lipsă arată exact ca un protocol blocat până când verificați.

Potriviți opțiunile cu clientul pe care îl aveți cu adevărat

Corectarea din celălalt raport se află în /etc/ppp/pptpd-options, unde rețeta refuză PAP, CHAP și MSCHAP, comentează liniile require corespunzătoare și păstrează MPPE cu stare. Acea rețetă a fost scrisă pentru un amestec de clienți, iar copierea orbească strică cazul obișnuit. Citiți liniile de refuz ca o afirmație despre ce clienți avea autorul, nu ca o recomandare.

Un client Windows are de obicei nevoie de MS-CHAPv2 cu MPPE-128. Păstrați aceste cerințe și eliminați doar opțiunile pe care clientul chiar nu le poate negocia.

# keep encryption; drop only what this client cannot negotiate
refuse-pap
refuse-chap
refuse-mschap
mppe-stateful
require-mschap-v2
require-mppe-128

Dezactivarea criptării pentru ca o conexiune să reușească este o degradare, nu o reparare. Testați o astfel de variantă pe o legătură de laborator, apoi restabiliți criptarea înainte ca serviciul să întâlnească clienți reali. Conexiunea care funcționează nesigur este mai rea decât cea care eșuează cinstit.

Citiți numărul de eroare al clientului

Codul numeric al clientului restrânge etapa mai repede decât jurnalul serverului. Citiți-l înainte de a citi orice altceva. 691 înseamnă că acreditările au fost refuzate, 721 înseamnă că serverul nu a răspuns niciodată, iar 619 înseamnă că conexiunea a căzut. Două minute cu numărul economisesc o oră cu configurația.

Comparați acel cod cu jurnalul serverului înainte de a edita ceva și retestați cu același client după fiecare modificare. Altfel o a doua defecțiune se ascunde în spatele primei și corectarea pare ineficientă.

Când autentificarea reușește și niciun trafic nu se mișcă, GRE rămâne suspectul. Acesta este momentul să reveniți la captură, nu la depozitul de acreditări.