Eroarea PPTP 800 față de 812 și căderi după un minut

Eroarea 800, eroarea 812 și un tunel PPTP care moare după un minut sunt trei defecte diferite. Asociază fiecare simptom stratului care a eșuat de fapt.

Trei mesaje de eroare de la un singur client PPTP descriu de obicei trei defecte diferite. Eroarea 800 înseamnă că tunelul nu s-a format niciodată, eroarea 812 înseamnă că serverul a respins metoda de autentificare, iar o cădere după un minut este un temporizator keepalive care decide că un partener sănătos a dispărut. Fiecare etapă eșuează din propria cauză, așa că fiecare are nevoie de propria verificare.

Eroarea 800 înseamnă că tunelul nu s-a format niciodată

Windows afișează eroarea 800 când nu poate construi tunelul deloc, iar textul despre un server inaccesibil sau parametri de securitate nepotriviți este un rezumat, nu un diagnostic. PPTP are nevoie de două lucruri separate de la rețea înainte de a fi examinată orice acreditare. TCP 1723 transportă canalul de control, iar protocolul IP 47, GRE, transportă încărcătura încapsulată.

Testează acea cale exterioară din afara propriului LAN, pentru că o conexiune care funcționează în birou nu demonstrează nimic despre margine:

$ nc -vz vpn.example.net 1723
Connection to vpn.example.net 1723 port [tcp/*] succeeded!
$ sudo tcpdump -ni eth0 proto gre
tcpdump: listening on eth0, link-type EN10MB

Dacă 1723 răspunde și captura rămâne goală în timp ce clientul încearcă să se conecteze, calea aruncă protocolul 47. Un router cu 1723 redirecționat dar passthrough PPTP oprit produce exact acel model: strângerea de mână TCP se termină, apoi pachetele GRE dispar, așa că defectul arată ca o problemă de acreditări deși nu s-a încercat nicio autentificare.

Îndreaptă redirecționarea către adresa LAN actuală a serverului, activează passthrough PPTP unde routerul îl oferă și încearcă din nou din același punct exterior. Când GRE este filtrat mai sus și nu poți schimba asta, SSTP peste TCP 443 sau L2TP/IPsec peste UDP 500 și 4500 are șanse mai bune decât orice modificare pe care o poți face pe partea Windows.

Eroarea 812 este serverul care îți respinge metoda de autentificare

Eroarea 812 revine după ce tunelul este sus, de aceea pare o problemă de parolă. Serverul respinge metoda de autentificare negociată pentru conexiune, nu neapărat parola în sine. Pe client, deschide intrarea VPN, mergi la fila de securitate, setează tipul la Point-to-Point Tunneling Protocol, alege lista explicită de protocoale și bifează Microsoft CHAP versiunea 2.

Poți citi setarea actuală fără să dai clic prin dialog:

$ Get-VpnConnection -Name "Office" | Select-Object -ExpandProperty AuthenticationMethod
MsChapv2

Un server care cere MS-CHAP v2 respinge un client lăsat pe PAP sau pe un tip automat care negociază ceva mai slab, iar eroarea apare înainte de a fi evaluată vreo parolă de utilizator. Formatul contului este cealaltă jumătate a aceleiași respingeri. Într-un caz, Windows a trimis o identitate de cont Microsoft de forma MicrosoftAccount\[email protected] în timp ce serverul voia un cont local sau de domeniu. Tastarea SERVERNAME\username i-a spus lui Windows ce depozit de conturi să consulte și a eliminat eroarea. Introdu numele manual în loc să lași o acreditare salvată să repete un format anterior.

Căderile după un minut sunt o decizie keepalive

Când tunelul se conectează, lasă să treacă puțin trafic și apoi se deconectează, uită-te la comportamentul de ecou LCP al serverului înainte de a atinge clientul. Daemonul cere periodic partenerului să confirme că este încă acolo. Dacă sosesc prea puține răspunsuri în bugetul configurat, sesiunea este demolată chiar dacă utilizatorul mai are o legătură funcțională.

Pe un server Linux pptpd acele valori stau în /etc/ppp/options.pptpd, iar reparația obișnuită este să lărgești bugetul, nu să scurtezi intervalul:

# /etc/ppp/options.pptpd
lcp-echo-failure 30
lcp-echo-interval 5
# then
sudo systemctl restart pptpd

Treizeci de ratări la un interval de cinci secunde iartă o scurtă blocare în loc să declare partenerul dispărut. Reducerea numărului la unu sau doi transformă jitterul obișnuit pe o cale tradusă în deconectare cam o dată pe minut. Dacă serverul tău este Windows RRAS și nu pptpd, uită-te în schimb la timpul de expirare al sesiunii PPP și la politica de deconectare la inactivitate. Acelea stau în altă parte, iar editarea unui fișier pppd care nu există nu va schimba nimic.

Subrețelele suprapuse rup calea de date

Un tunel PPTP se poate autentifica curat și totuși nu ajunge nicăieri când ambele locații folosesc același interval privat, de exemplu 192.168.1.0/24 la birou și acasă. Clientul nu poate spune cărui gazdă i se referă o anumită adresă, iar unele stive refuză cu totul să instaleze ruta în loc să aleagă una.

Tratează asta ca pe un defect de proiectare și renumerotează o parte, sau dă clientului un interval de acces tradus intenționat. Depanarea clientului PPTP nu poate repara un spațiu de adrese care există de două ori, iar simptomul va continua să pară o cădere aleatorie.

Începe cu etapa care a eșuat: GRE pentru 800, metoda și șirul de cont pentru 812, setările de ecou pentru un tunel care moare conform programului.

Articole similare