PPTP error 800 kumpara sa 812 at pagputol pagkalipas ng isang minuto

Tatlong mensahe ng error mula sa isang PPTP client ay karaniwang naglalarawan ng tatlong magkakaibang sira. Ang error 800 ay nangangahulugang hindi kailanman nabuo ang tunnel, ang error 812 ay nangangahulugang tinanggihan ng server ang paraan ng pagpapatotoo, at ang pagputol pagkalipas ng isang minuto ay isang keepalive timer na nagpapasyang wala na ang isang malusog na kapares. Bawat yugto ay nabibigo sa sarili nitong dahilan, kaya bawat isa ay kailangan ng sarili nitong pagsusuri.

Ang error 800 ay nangangahulugang hindi kailanman nabuo ang tunnel

Nagpapalabas ang Windows ng error 800 kapag hindi nito kayang buuin ang tunnel, at ang teksto tungkol sa hindi maabot na server o hindi angkop na mga parameter ng seguridad ay buod at hindi pagsusuri. Kailangan ng PPTP ng dalawang magkahiwalay na bagay mula sa network bago suriin ang anumang kredensyal. Dinadala ng TCP 1723 ang control channel, at ang IP protocol 47, ang GRE, ay nagdadala ng naka-encapsulate na payload.

Subukan ang panlabas na landas na iyon mula sa labas ng sarili mong LAN, dahil ang koneksyong gumagana sa opisina ay walang pinapatunayan tungkol sa gilid:

$ 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

Kung sumasagot ang 1723 at nananatiling walang laman ang capture habang sinusubukan ng client na kumonekta, ibinabagsak ng landas ang protocol 47. Ang router na may 1723 na naka-forward pero patay ang PPTP passthrough ay gumagawa ng eksaktong ganoong pattern: natatapos ang TCP handshake, pagkatapos ay nawawala ang mga GRE packet, kaya ang kabiguan ay mukhang problema sa kredensyal kahit walang sinubukang pag-login.

Ituro ang forwarding sa kasalukuyang LAN address ng server, buksan ang PPTP passthrough kung saan inaalok ito ng router, at subukang muli mula sa parehong panlabas na punto. Kapag nasasala ang GRE sa itaas at hindi mo ito mababago, ang SSTP sa TCP 443 o L2TP/IPsec sa UDP 500 at 4500 ay may mas magandang tsansa kaysa sa anumang pagbabagong magagawa mo sa panig ng Windows.

Ang error 812 ay ang server na tumatanggi sa iyong paraan ng pagpapatotoo

Bumabalik ang error 812 pagkatapos ng tunnel ay nakaangat, kaya pakiramdam nito ay problema sa password. Tinatanggihan ng server ang paraan ng pagpapatotoo na napagkasunduan para sa koneksyon, hindi kinakailangan ang password mismo. Sa client, buksan ang entry ng VPN, pumunta sa tab ng seguridad, itakda ang uri sa Point-to-Point Tunneling Protocol, piliin ang tahasang listahan ng protocol at lagyan ng tsek ang Microsoft CHAP bersyon 2.

Mababasa mo ang kasalukuyang setting nang hindi pumipindot sa dialog:

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

Ang server na nangangailangan ng MS-CHAP v2 ay tumatanggi sa client na naiwan sa PAP o sa tampok na awtomatikong uri na nakikipagkasundo ng mas mahinang bagay, at ang error ay dumarating bago suriin ang anumang password ng gumagamit. Ang format ng account ay ang kabilang kalahati ng parehong pagtanggi. Sa isang kaso nagpadala ang Windows ng pagkakakilanlang account ng Microsoft sa anyong MicrosoftAccount\[email protected] samantalang gusto ng server ng lokal o domain account. Ang pag-type ng SERVERNAME\username ay nagsabi sa Windows kung aling tindahan ng account ang kukunsultahin at tinanggal ang error. I-type ang pangalan nang manu-mano sa halip na hayaang ulitin ng naka-save na kredensyal ang dating format.

Ang pagputol pagkalipas ng isang minuto ay desisyon ng keepalive

Kapag kumonekta ang tunnel, nagpapadaan ng kaunting trapiko at pagkatapos ay humihiwalay, tingnan ang pag-uugali ng LCP echo ng server bago hawakan ang client. Pana-panahong hinihiling ng daemon sa kapares na kumpirmahin na naroon pa rin ito. Kung napakakaunting tugon ang dumarating sa loob ng naka-configure na badyet, ibinabagsak ang session kahit may gumaganang link pa ang gumagamit.

Sa isang Linux pptpd na server, ang mga halagang iyon ay naninirahan sa /etc/ppp/options.pptpd, at ang karaniwang pag-aayos ay palawakin ang badyet sa halip na paikliin ang agwat:

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

Tatlumpung palya sa agwat na limang segundo ay nagpapatawad ng maikling paghinto sa halip na ideklarang wala na ang kapares. Ang pagbaba ng bilang sa isa o dalawa ay ginagawang pagkawala ng koneksyon ang ordinaryong jitter sa isang isinaling landas halos bawat minuto. Kung ang server mo ay Windows RRAS at hindi pptpd, tingnan sa halip ang timeout ng PPP session at ang patakaran sa paghiwalay kapag walang aktibidad. Doon sila naninirahan sa ibang lugar, at ang pag-edit ng pppd file na wala naman ay walang mababago.

Ang magkakapatong na subnet ay sumisira sa landas ng data

Maaaring malinis na magpatotoo ang isang PPTP tunnel at gayon pa man ay walang maabot kapag parehong site ay gumagamit ng parehong pribadong saklaw, halimbawa 192.168.1.0/24 sa opisina at sa bahay. Hindi masasabi ng client kung aling host ang tinutukoy ng isang partikular na address, at ang ilang stack ay tumatangging i-install ang ruta sa halip na pumili ng isa.

Ituring iyon na depekto sa disenyo at muling bilangin ang isang panig, o bigyan ang client ng sadyang isinaling saklaw ng access. Ang pag-debug ng PPTP client ay hindi kayang ayusin ang espasyo ng address na umiiral nang dalawang beses, at ang sintomas ay magpapatuloy na mukhang random na pagputol.

Magsimula sa yugtong nabigo: GRE para sa 800, ang paraan at string ng account para sa 812, mga setting ng echo para sa tunnel na namamatay ayon sa iskedyul.