PPTP klaida 800 ir 812 bei ryšio nutrūkimas po minutės

Klaida 800, klaida 812 ir po minutės mirštantis PPTP tunelis yra trys skirtingi gedimai. Susiekite kiekvieną simptomą su sluoksniu, kuris iš tikrųjų sugedo.

Trys vieno PPTP kliento klaidų pranešimai paprastai aprašo tris skirtingus gedimus. Klaida 800 reiškia, kad tunelis niekada nesusiformavo, klaida 812 reiškia, kad serveris atmetė autentifikavimo metodą, o nutrūkimas po minutės yra keepalive laikmatis, nusprendžiantis, kad sveikas partneris dingo. Kiekvienas etapas žlunga dėl savo priežasties, todėl kiekvienam reikia savo patikros.

Klaida 800 reiškia, kad tunelis niekada nesusiformavo

Windows rodo klaidą 800, kai apskritai negali sukurti tunelio, o tekstas apie nepasiekiamą serverį ar netinkamus saugos parametrus yra santrauka, o ne diagnozė. PPTP reikia dviejų atskirų dalykų iš tinklo, kol tikrinami bet kokie prisijungimo duomenys. TCP 1723 neša valdymo kanalą, o IP protokolas 47, GRE, neša inkapsuliuotą naudingąją apkrovą.

Išbandykite tą išorinį kelią už savo LAN ribų, nes biure veikiantis ryšys nieko neįrodo apie kraštą:

$ 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

Jei 1723 atsako, o fiksavimas lieka tuščias, kol klientas bando jungtis, kelias meta protokolą 47. Maršrutizatorius, kuriame 1723 peradresuotas, bet PPTP pralaidumas išjungtas, duoda būtent tokį vaizdą: TCP rankos paspaudimas baigiasi, tada GRE paketai dingsta, todėl gedimas atrodo kaip prisijungimo duomenų problema, nors prisijungimo bandymo nebuvo.

Nukreipkite peradresavimą į dabartinį serverio LAN adresą, įjunkite PPTP pralaidumą ten, kur maršrutizatorius jį siūlo, ir bandykite iš naujo iš to paties išorinio taško. Kai GRE filtruojamas aukščiau ir to pakeisti negalite, SSTP per TCP 443 arba L2TP/IPsec per UDP 500 ir 4500 turi daugiau šansų nei bet koks pakeitimas Windows pusėje.

Klaida 812 yra serverio atmetimas jūsų autentifikavimo metodo

Klaida 812 grįžta po to, kai tunelis pakeltas, todėl atrodo kaip slaptažodžio problema. Serveris atmeta ryšiui suderintą autentifikavimo metodą, o ne būtinai patį slaptažodį. Kliente atidarykite VPN įrašą, eikite į saugos skirtuką, nustatykite tipą į Point-to-Point Tunneling Protocol, pasirinkite aiškų protokolų sąrašą ir pažymėkite Microsoft CHAP 2 versiją.

Dabartinį nustatymą galite perskaityti nespausdami dialogo:

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

Serveris, reikalaujantis MS-CHAP v2, atmeta klientą, paliktą su PAP arba automatiniu tipu, kuris derasi dėl kažko silpnesnio, o klaida ateina prieš įvertinant bet kokį naudotojo slaptažodį. Paskyros formatas yra antroji to paties atmetimo pusė. Vienu atveju Windows nusiuntė Microsoft paskyros tapatybę, kurios forma MicrosoftAccount\[email protected], nors serveris norėjo vietinės ar domeno paskyros. Įvedus SERVERNAME\username Windows buvo pasakyta, į kurią paskyrų saugyklą kreiptis, ir klaida dingo. Įveskite vardą ranka, o ne leiskite išsaugotiems prisijungimo duomenims kartoti ankstesnio formato.

Nutrūkimai po minutės yra keepalive sprendimas

Kai tunelis prisijungia, praleidžia šiek tiek srauto ir tada atsijungia, pažiūrėkite į serverio LCP aido elgseną prieš liedami klientą. Demonas periodiškai prašo partnerio patvirtinti, kad jis dar ten. Jei per nustatytą biudžetą ateina per mažai atsakymų, sesija nugriaunama, nors naudotojas dar turi veikiančią jungtį.

Linux pptpd serveryje tos reikšmės gyvena /etc/ppp/options.pptpd, o įprastas taisymas yra išplėsti biudžetą, o ne sutrumpinti intervalą:

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

Trisdešimt praleidimų penkių sekundžių intervalu atleidžia trumpą strigimą, o ne paskelbia partnerį dingusį. Sumažinus skaičių iki vieno ar dviejų, įprastas drebėjimas išverstame kelyje maždaug kas minutę virsta atsijungimu. Jei jūsų serveris yra Windows RRAS, o ne pptpd, žiūrėkite PPP sesijos laiko limitą ir atsijungimo neveiklumo metu politiką. Jos gyvena kitur, o neegzistuojančio pppd failo redagavimas nieko nepakeis.

Persidengiantys potinkliai sulaužo duomenų kelią

PPTP tunelis gali švariai autentifikuotis ir vis tiek nieko nepasiekti, kai abi vietos naudoja tą patį privatų diapazoną, pavyzdžiui, 192.168.1.0/24 biure ir namuose. Klientas negali pasakyti, kurį hostą reiškia duotas adresas, o kai kurie stekai visiškai atsisako įdiegti maršrutą, o ne pasirinkti vieną.

Traktuokite tai kaip projektavimo trūkumą ir pernumeruokite vieną pusę, arba duokite klientui tyčia išverstą prieigos diapazoną. PPTP kliento derinimas negali pataisyti adresų erdvės, kuri egzistuoja du kartus, o simptomas ir toliau atrodys kaip atsitiktinis nutrūkimas.

Pradėkite nuo etapo, kuris žlugo: GRE 800 atveju, metodas ir paskyros eilutė 812 atveju, aido nustatymai tuneliui, kuris miršta pagal grafiką.

Susiję straipsniai