Yhden PPTP-asiakkaan kolme virheilmoitusta kuvaavat yleensä kolmea eri vikaa. Virhe 800 tarkoittaa, ettei tunnelia koskaan muodostunut, virhe 812 tarkoittaa, että palvelin hylkäsi todennusmenetelmän, ja minuutin jälkeen katkeaminen on keepalive-ajastin, joka päättää terveen vertaisen kadonneen. Jokainen vaihe epäonnistuu omasta syystään, joten jokainen tarvitsee oman tarkistuksensa.

Virhe 800 tarkoittaa, ettei tunnelia koskaan muodostunut

Windows näyttää virheen 800, kun se ei pysty rakentamaan tunnelia lainkaan, ja teksti saavuttamattomasta palvelimesta tai sopimattomista suojausparametreista on yhteenveto eikä diagnoosi. PPTP tarvitsee verkosta kaksi erillistä asiaa ennen kuin mitään tunnusta tutkitaan. TCP 1723 kuljettaa ohjauskanavaa ja IP-protokolla 47, GRE, kuljettaa kapseloidun hyötykuorman.

Testaa tätä ulkoista polkua oman lähiverkkosi ulkopuolelta, sillä toimistossa toimiva yhteys ei todista reunasta mitään:

$ 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

Jos 1723 vastaa ja kaappaus jää tyhjäksi asiakkaan yrittäessä yhdistää, polku pudottaa protokollan 47. Reititin, jossa 1723 on edelleenohjattu mutta PPTP-läpivienti pois päältä, tuottaa juuri tuon kuvion: TCP-kättely valmistuu, sitten GRE-paketit katoavat, joten vika näyttää tunnusongelmalta, vaikka kirjautumista ei yritettykään.

Kohdista edelleenohjaus palvelimen nykyiseen lähiverkko-osoitteeseen, ota PPTP-läpivienti käyttöön siellä missä reititin tarjoaa sen, ja yritä uudelleen samasta ulkoisesta pisteestä. Kun GRE suodatetaan ylempänä eikä sitä voi muuttaa, SSTP TCP:n 443 yli tai L2TP/IPsec UDP:n 500 ja 4500 yli on paremmassa asemassa kuin mikään Windowsin puolella tehtävä muutos.

Virhe 812 on palvelimen kieltäytyminen todennusmenetelmästäsi

Virhe 812 palaa sen jälkeen kun tunneli on pystyssä, siksi se tuntuu salasanaongelmalta. Palvelin hylkää yhteydelle neuvotellun todennusmenetelmän, ei välttämättä itse salasanaa. Avaa asiakkaassa VPN-merkintä, siirry suojausvälilehteen, aseta tyypiksi Point-to-Point Tunneling Protocol, valitse nimenomainen protokollaluettelo ja rastita Microsoft CHAP versio 2.

Voit lukea nykyisen asetuksen klikkaamatta valikon läpi:

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

Palvelin, joka vaatii MS-CHAP v2:n, hylkää asiakkaan, joka on jätetty PAP:n tai automaattiseen tyyppiin, joka neuvottelee jotain heikompaa, ja virhe saapuu ennen kuin yhtään käyttäjän salasanaa arvioidaan. Tilin muoto on saman hylkäyksen toinen puoli. Yhdessä tapauksessa Windows lähetti Microsoft-tilin identiteetin muodossa MicrosoftAccount\[email protected], kun palvelin halusi paikallisen tai toimialueen tilin. SERVERNAME\username kirjoittaminen kertoi Windowsille, mitä tilitietovarastoa kysyä, ja poisti virheen. Kirjoita nimi käsin sen sijaan, että annat tallennetun tunnuksen toistaa aiempaa muotoa.

Minuutin jälkeen katkeamiset ovat keepalive-päätös

Kun tunneli yhdistää, päästää hieman liikennettä läpi ja katkaisee sitten, katso palvelimen LCP-kaikua ennen kuin kosket asiakkaaseen. Daemon pyytää vertaista säännöllisesti vahvistamaan, että se on yhä paikalla. Jos määritetyn budjetin sisällä saapuu liian vähän vastauksia, istunto puretaan, vaikka käyttäjällä on vielä toimiva linkki.

Linuxin pptpd-palvelimella nuo arvot ovat tiedostossa /etc/ppp/options.pptpd, ja tavallinen korjaus on laajentaa budjettia eikä lyhentää väliä:

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

Kolmekymmentä ohitusta viiden sekunnin välillä antavat anteeksi lyhyen pysähdyksen sen sijaan, että vertainen julistettaisiin kadonneeksi. Määrän pudottaminen yhteen tai kahteen tekee käännetyllä polulla tavallisesta jitteristä noin minuutin välein tapahtuvan katkeamisen. Jos palvelimesi on Windows RRAS eikä pptpd, katso sen sijaan PPP-istunnon aikakatkaisua ja joutokäynnin katkaisukäytäntöä. Ne ovat toisaalla, eikä olemattoman pppd-tiedoston muokkaaminen muuta mitään.

Päällekkäiset aliverkot rikkovat datapolun

PPTP-tunneli voi todennusmielessä onnistua ja silti olla saavuttamatta mitään, kun molemmat sivustot käyttävät samaa yksityistä aluetta, esimerkiksi 192.168.1.0/24 toimistossa ja kotona. Asiakas ei voi kertoa, mihin isäntään tietty osoite viittaa, ja jotkin pinot kieltäytyvät asentamasta reittiä kokonaan sen sijaan, että valitsisivat yhden.

Käsittele sitä suunnitteluvirheenä ja numeroi toinen puoli uudelleen tai anna asiakkaalle tarkoituksella käännetty käyttöalue. PPTP-asiakkaan virheenkorjaus ei voi korjata osoiteavaruutta, joka on olemassa kahdesti, ja oire näyttää edelleen satunnaiselta katkeamiselta.

Aloita vaiheesta, joka petti: GRE virheelle 800, menetelmä ja tilimerkkijono virheelle 812, kaikuasetukset tunnelille, joka kuolee aikataulun mukaan.

Aiheeseen liittyvät artikkelit