PPTP viga 800 versus 812 ja ühenduse katkemine minuti pärast

Viga 800, viga 812 ja minuti pärast surev PPTP tunnel on kolm eraldi riket. Sobita iga sümptom kihiga, mis tegelikult ebaõnnestus.

Ühe PPTP kliendi kolm veateadet kirjeldavad tavaliselt kolme erinevat riket. Viga 800 tähendab, et tunnelit ei tekkinudki, viga 812 tähendab, et server keeldus autentimismeetodist, ja katkemine minuti pärast on keepalive-taimer, mis otsustab, et terve partner on kadunud. Iga etapp ebaõnnestub omal põhjusel, seega vajab igaüks oma kontrolli.

Viga 800 tähendab, et tunnelit ei tekkinudki

Windows näitab viga 800, kui see ei suuda tunnelit üldse ehitada, ja tekst kättesaamatu serveri või sobimatute turvaparameetrite kohta on kokkuvõte, mitte diagnoos. PPTP vajab võrgust kahte eraldi asja enne, kui ükskõik millist volitust kontrollitakse. TCP 1723 kannab juhtkanalit ja IP-protokoll 47, GRE, kannab kapseldatud lasti.

Testi seda välimist teed väljastpoolt oma kohtvõrku, sest kontoris töötav ühendus ei tõesta serva kohta midagi:

$ 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

Kui 1723 vastab ja jäädvustus jääb tühjaks, samal ajal kui klient üritab ühenduda, viskab tee protokolli 47 kõrvale. Ruuter, millel 1723 on edasi suunatud, kuid PPTP läbipääs välja lülitatud, annab täpselt sellise mustri: TCP käepigistus lõpeb, seejärel GRE paketid kaovad, nii et rike näeb välja nagu volituste probleem, kuigi sisselogimist ei üritatudki.

Suuna edasisaatmine serveri praegusele LAN-aadressile, lülita PPTP läbipääs sisse seal, kus ruuter seda pakub, ja proovi uuesti samast välisest punktist. Kui GRE filtreeritakse ülalpool ja sa ei saa seda muuta, on SSTP üle TCP 443 või L2TP/IPsec üle UDP 500 ja 4500 parema väljavaatega kui ükskõik milline muudatus Windowsi poolel.

Viga 812 on serveri keeldumine sinu autentimismeetodist

Viga 812 tuleb tagasi pärast seda, kui tunnel on püsti, seepärast tundub see parooliprobleemina. Server keeldub ühenduse jaoks läbi räägitud autentimismeetodist, mitte tingimata paroolist endast. Kliendis ava VPN-kirje, mine turvalisuse vahekaardile, määra tüübiks Point-to-Point Tunneling Protocol, vali selgesõnaline protokollide loend ja märgi Microsoft CHAP versioon 2.

Saad praeguse sätte lugeda dialoogi läbi klõpsamata:

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

Server, mis nõuab MS-CHAP v2, keeldub kliendist, mis on jäetud PAP-i või automaatsele tüübile, mis räägib läbi nõrgema, ja viga saabub enne, kui hinnatakse ükskõik millist kasutaja parooli. Konto vorming on sama keeldumise teine pool. Ühel juhul saatis Windows Microsofti konto identiteedi kujul MicrosoftAccount\[email protected], samal ajal kui server tahtis kohalikku või domeenikontot. SERVERNAME\username sisestamine ütles Windowsile, millist kontohoidlat küsida, ja kõrvaldas vea. Sisesta nimi käsitsi, selle asemel et lasta salvestatud volitusel eelmist vormingut korrata.

Katkemised minuti pärast on keepalive otsus

Kui tunnel ühendub, laseb veidi liiklust läbi ja katkeb seejärel, vaata serveri LCP kaja käitumist enne kliendi puudutamist. Deemon palub partneril perioodiliselt kinnitada, et see on veel kohal. Kui seatud eelarve sees saabub liiga vähe vastuseid, lammutatakse seanss, kuigi kasutajal on veel töötav link.

Linuxi pptpd serveris elavad need väärtused failis /etc/ppp/options.pptpd, ja tavaline parandus on eelarvet laiendada, mitte intervalli lühendada:

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

Kolmkümmend möödalasku viie sekundi intervalliga annavad andeks lühikese tõrke, selle asemel et partner kadunuks kuulutada. Arvu vähendamine ühe või kaheni muudab tõlgitud teel tavalise värina umbes iga minutiseks katkestuseks. Kui sinu server on Windows RRAS, mitte pptpd, vaata selle asemel PPP seansi ajalõppu ja jõudeoleku katkestamise poliitikat. Need elavad mujal, ja pppd faili, mida pole olemas, muutmine ei muuda midagi.

Kattuvad alamvõrgud lõhuvad andmetee

PPTP tunnel saab puhtalt autentida ja ikkagi mitte kuhugi jõuda, kui mõlemad saidid kasutavad sama privaatset vahemikku, näiteks 192.168.1.0/24 kontoris ja kodus. Klient ei saa öelda, millist hosti antud aadress tähistab, ja mõned virnad keelduvad marsruuti üldse paigaldamast, selle asemel et üks valida.

Käsitle seda projekteerimisveana ja nummerda üks pool ümber, või anna kliendile teadlikult tõlgitud juurdepääsuvahemik. PPTP kliendi silumine ei saa parandada aadressiruumi, mis eksisteerib kaks korda, ja sümptom jääb näima juhusliku katkemisena.

Alusta etapist, mis ebaõnnestus: GRE 800 jaoks, meetod ja kontostring 812 jaoks, kajaseaded tunnelile, mis sureb graafiku järgi.

Seotud artiklid