PPTP kļūda 800 pret 812 un savienojuma pārtraukumi pēc minūtes

Kļūda 800, kļūda 812 un PPTP tunelis, kas mirst pēc minūtes, ir trīs atšķirīgi bojājumi. Sasaistiet katru simptomu ar slāni, kas patiešām sabojājās.

Trīs kļūdas ziņojumi no viena PPTP klienta parasti apraksta trīs dažādus bojājumus. Kļūda 800 nozīmē, ka tunelis nekad neizveidojās, kļūda 812 nozīmē, ka serveris noraidīja autentifikācijas metodi, un pārtraukums pēc minūtes ir keepalive taimeris, kas nolemj, ka vesels partneris ir aizgājis. Katrs posms sabrūk sava iemesla dēļ, tāpēc katram vajadzīga sava pārbaude.

Kļūda 800 nozīmē, ka tunelis nekad neizveidojās

Windows parāda kļūdu 800, kad tas vispār nevar izveidot tuneli, un teksts par nesasniedzamu serveri vai nepiemērotiem drošības parametriem ir kopsavilkums, nevis diagnoze. PPTP no tīkla vajag divas atsevišķas lietas, pirms tiek pārbaudīti jebkādi akreditācijas dati. TCP 1723 pārvadā vadības kanālu, un IP protokols 47, GRE, pārvadā iekapsulēto kravu.

Pārbaudiet šo ārējo ceļu ārpus sava LAN, jo savienojums, kas darbojas birojā, neko nepierāda par malu:

$ 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

Ja 1723 atbild un uztveršana paliek tukša, kamēr klients mēģina savienoties, ceļš nomet 47 protokolu. Maršrutētājs, kurā 1723 ir pāradresēts, bet PPTP caurlaide izslēgta, rada tieši šādu ainu: TCP rokasspiediens pabeidzas, pēc tam GRE paketes pazūd, tāpēc bojājums izskatās kā akreditācijas datu problēma, lai gan pieteikšanās mēģinājums nav veikts.

Novirziet pāradresāciju uz servera pašreizējo LAN adresi, ieslēdziet PPTP caurlaidi tur, kur maršrutētājs to piedāvā, un mēģiniet vēlreiz no tā paša ārējā punkta. Kad GRE tiek filtrēts augstāk un to nevarat mainīt, SSTP virs TCP 443 vai L2TP/IPsec virs UDP 500 un 4500 ir labākas izredzes nekā jebkura izmaiņa Windows pusē.

Kļūda 812 ir servera atteikums jūsu autentifikācijas metodei

Kļūda 812 atgriežas pēc tam, kad tunelis ir uzcelts, tāpēc tā šķiet paroles problēma. Serveris noraida savienojumam saskaņoto autentifikācijas metodi, ne vienmēr pašu paroli. Klientā atveriet VPN ierakstu, pārejiet uz drošības cilni, iestatiet tipu uz Point-to-Point Tunneling Protocol, izvēlieties skaidru protokolu sarakstu un atzīmējiet Microsoft CHAP 2 versiju.

Pašreizējo iestatījumu varat nolasīt, neklikšķinot dialogā:

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

Serveris, kas prasa MS-CHAP v2, noraida klientu, kas atstāts uz PAP vai automātisku tipu, kas vienojas par kaut ko vājāku, un kļūda pienāk pirms jebkuras lietotāja paroles novērtēšanas. Konta formāts ir otra tā paša atteikuma puse. Vienā gadījumā Windows nosūtīja Microsoft konta identitāti formā MicrosoftAccount\[email protected], kamēr serveris gribēja vietējo vai domēna kontu. Ievadot SERVERNAME\username, Windows tika pateikts, kuru kontu krātuvi izmantot, un kļūda pazuda. Ievadiet vārdu ar roku, tā vietā lai saglabāti akreditācijas dati atkārtotu iepriekšējo formātu.

Pārtraukumi pēc minūtes ir keepalive lēmums

Kad tunelis savienojas, palaiž nedaudz trafika un pēc tam atvienojas, paskatieties uz servera LCP atbalss uzvedību, pirms aiztiekat klientu. Dēmons periodiski lūdz partnerim apstiprināt, ka tas vēl ir tur. Ja noteiktā budžetā pienāk pārāk maz atbilžu, sesija tiek sagrauta, lai gan lietotājam vēl ir strādājošs savienojums.

Linux pptpd serverī šīs vērtības mīt /etc/ppp/options.pptpd, un parastais labojums ir paplašināt budžetu, nevis saīsināt intervālu:

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

Trīsdesmit garām palaistas atbildes piecu sekunžu intervālā piedod īsu klupienu, nevis pasludina partneri aizgājušu. Samazinot skaitu līdz vienam vai diviem, parastais džiters tulkotā ceļā pārvēršas atvienošanā aptuveni katru minūti. Ja jūsu serveris ir Windows RRAS, nevis pptpd, skatieties PPP sesijas noildzi un atvienošanas politiku dīkstāvē. Tie mīt citur, un neesoša pppd faila rediģēšana neko nemainīs.

Pārklājošie apakštīkli salauž datu ceļu

PPTP tunelis var tīri autentificēties un tomēr nekur nenokļūt, ja abas vietas izmanto vienu un to pašu privāto diapazonu, piemēram, 192.168.1.0/24 birojā un mājās. Klients nevar pateikt, uz kuru resursdatoru attiecas dotā adrese, un dažas stekas atsakās vispār instalēt maršrutu, nevis izvēlēties vienu.

Uzskatiet to par projektēšanas defektu un pārnumurējiet vienu pusi, vai dodiet klientam tīši tulkotu piekļuves diapazonu. PPTP klienta atkļūdošana nevar salabot adrešu telpu, kas pastāv divreiz, un simptoms turpinās izskatīties kā nejaušs pārtraukums.

Sāciet ar posmu, kas sabruka: GRE 800 gadījumā, metode un konta virkne 812 gadījumā, atbalss iestatījumi tunelim, kas mirst pēc grafika.

Saistītie raksti