PPTP-eraro 800 kontraŭ 812 kaj ŝiroj post unu minuto

Tri erarmesaĝoj de unu PPTP-kliento kutime priskribas tri malsamajn difektojn. Eraro 800 signifas, ke la tunelo neniam formiĝis, eraro 812 signifas, ke la servilo rifuzis la aŭtentikigan metodon, kaj ŝiro post unu minuto estas keepalive-tempigilo, kiu decidas, ke sana kunulo foriris. Ĉiu stadio fiaskas pro sia propra kaŭzo, do ĉiu bezonas sian propran kontrolon.

Eraro 800 signifas, ke la tunelo neniam formiĝis

Windows montras eraron 800, kiam ĝi tute ne povas konstrui la tunelon, kaj la teksto pri neatingebla servilo aŭ netaŭgaj sekurecaj parametroj estas resumo, ne diagnozo. PPTP bezonas du apartajn aferojn de la reto antaŭ ol ekzameni iun ajn akreditilon. TCP 1723 portas la stirkanalon, kaj IP-protokolo 47, GRE, portas la enkapsuligitan utilŝarĝon.

Testu tiun eksteran vojon de ekster via propra LAN, ĉar konekto, kiu funkcias en la oficejo, pruvas nenion pri la rando:

$ 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

Se 1723 respondas kaj la kaptaĵo restas malplena dum la kliento provas konekti, la vojo faligas protokolon 47. Enkursigilo kun plusendita 1723 sed malŝaltita PPTP-passthrough produktas ĝuste tiun ŝablonon: la TCP-manpremo finiĝas, poste la GRE-paketoj malaperas, do la fiasko aspektas kiel akreditila problemo kvankam neniu ensaluto estis provita.

Direktu la plusendadon al la nuna LAN-adreso de la servilo, ŝaltu PPTP-passthrough kie la enkursigilo ofertas ĝin, kaj reprovu el la sama ekstera punkto. Kiam GRE estas filtrita pli supre kaj vi ne povas tion ŝanĝi, SSTP super TCP 443 aŭ L2TP/IPsec super UDP 500 kaj 4500 havas pli bonan ŝancon ol iu ajn ŝanĝo, kiun vi povas fari ĉe la Windows-flanko.

Eraro 812 estas la rifuzo de via aŭtentikiga metodo fare de la servilo

Eraro 812 revenas post kiam la tunelo staras, tial ĝi sentiĝas kiel pasvorta problemo. La servilo rifuzas la aŭtentikigan metodon interkonsentitan por la konekto, ne nepre la pasvorton mem. Ĉe la kliento malfermu la VPN-eron, iru al la sekureca langeto, agordu la tipon al Point-to-Point Tunneling Protocol, elektu la eksplicitan protokololiston kaj marku Microsoft CHAP version 2.

Vi povas legi la nunan agordon sen klaki tra la dialogo:

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

Servilo, kiu postulas MS-CHAP v2, rifuzas klienton lasitan sur PAP aŭ sur aŭtomata tipo, kiu interkonsentas ion pli malfortan, kaj la eraro alvenas antaŭ ol taksi iun ajn uzantopasvorton. La konta formato estas la alia duono de la sama rifuzo. En unu kazo Windows sendis Microsoft-kontan identecon de la formo MicrosoftAccount\[email protected] dum la servilo volis lokan aŭ domajnan konton. Tajpi SERVERNAME\username diris al Windows kiun kontan konservejon konsulti kaj forigis la eraron. Enigu la nomon permane anstataŭ lasi konservitan akreditilon ripeti antaŭan formaton.

Ŝiroj post unu minuto estas keepalive-decidaĵo

Kiam la tunelo konektas, pasigas iom da trafiko kaj poste malkonektas, rigardu la LCP-eĥan konduton de la servilo antaŭ ol tuŝi la klienton. La demono periode petas la kunulon konfirmi, ke ĝi ankoraŭ estas tie. Se tro malmultaj respondoj alvenas ene de la agordita buĝeto, la sesio malkonstruiĝas kvankam la uzanto ankoraŭ havas funkciantan ligilon.

Sur Linux-servilo pptpd tiuj valoroj loĝas en /etc/ppp/options.pptpd, kaj la kutima riparo estas larĝigi la buĝeton anstataŭ mallongigi la intervalon:

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

Tridek maltrafaĵoj ĉe intervalo de kvin sekundoj pardonas mallongan halton anstataŭ deklari la kunulon foririnta. Malpliigi la nombron al unu aŭ du igas ordinaran ĵiteron sur tradukita vojo malkonekto proksimume ĉiun minuton. Se via servilo estas Windows RRAS anstataŭ pptpd, rigardu anstataŭe la PPP-sesian tempolimon kaj la politikon pri malkonekto dum neaktiveco. Tiuj loĝas aliloke, kaj redakti pppd-dosieron, kiu ne ekzistas, ŝanĝos nenion.

Interkovrantaj subretoj rompas la datan vojon

PPTP-tunelo povas aŭtentikiĝi pure kaj tamen atingi nenion, kiam ambaŭ ejoj uzas la saman privatan gamon, ekzemple 192.168.1.0/24 en la oficejo kaj hejme. La kliento ne povas diri, al kiu gastiganto rilatas donita adreso, kaj kelkaj stakoj rifuzas entute instali la itineron anstataŭ elekti unu.

Traktu tion kiel projektan difekton kaj renumerigu unu flankon, aŭ donu al la kliento intence tradukitan alirgamon. Senŝeligi la PPTP-klienton ne povas ripari adresan spacon, kiu ekzistas dufoje, kaj la simptomo daŭre aspektos kiel hazarda ŝiro.

Komencu per la stadio, kiu fiaskis: GRE por 800, la metodo kaj konta ĉeno por 812, eĥaj agordoj por tunelo, kiu mortas laŭ horaro.