Kulang ang PPTP passthrough: ayusin ang error 807 ng VPN sa Windows

Ang pag-forward ng TCP 1723 ay madalas na naglilinis lamang ng unang bahagi ng PPTP at iniiwan ang natitira na sira, kaya nagbabalik pa rin ang Windows ng error 807 sa pagtatangka. Ang susunod na kutob ay magdagdag ng tuntunin para sa port 47, at iyon ang hakbang na nagsasayang ng isang hapon: ang GRE ay isang protocol number sa header ng IP, hindi isang port na maipapares ng forwarding table. Hanggang hindi pinapasa ng router ang protocol 47 at ikinakabit ito sa parehong tawag, hindi makakapagsimula ang tunnel. Hinihiwalay ng mga seksyon sa ibaba ang dalawang channel, pagkatapos ay sinusubok ang mga ito nang isa-isa.

Walang hilera ang port table para sa protocol number

Gumagamit ang PPTP ng dalawang pag-uusap na nabigo sa magkaibang paraan. Ang nasa TCP 1723 ay nagsisimula ng tawag, nagpapasa ng impormasyon ng link at pinupunit ito kapag nag-disconnect ang gumagamit. Ang panig ng payload ay tumatakbo sa loob ng GRE, na tinatatakan ng header ng IP ng protocol number 47, at sa loob ng tunnel na iyon ay nakikipag-usap ang PPP sa link habang sinusuri ng MS-CHAPv2 ang mga kredensyal.

Dahil walang transport header ang GRE, wala itong inilalantad na port, kaya ang tuntuning isinulat para sa mga port ay walang maipapares. Ang router na nag-forward ng 1723 ay gumagawa ng mapping para sa TCP session na iyon at humihinto doon. Tinatawag ng firmware na humahawak sa ikalawang kalahati ang tampok na ito na PPTP passthrough o PPTP ALG, at may firmware na hindi nag-aalok ng alinman at hindi man lang binabanggit ang puwang. Ang label sa checkbox ay mas mababa ang halaga kaysa sa kung nakikilala man lang ang protocol 47.

Ano ang iniuulat ng Windows kapag namatay ang data path

Sinasabi ng error 807 na hindi makumpleto ang koneksyon, na sa praktika ay nangangahulugang nakarating ang tawag sa server at hindi umangat ang data channel. Ito ay hatol sa transport, hindi sa account. Ang error 691 ang tumutukoy sa mga kredensyal o sa hindi pagtutugma ng authentication protocol, kaya dinadala ka nito sa ibang lugar nang lubusan.

Trabahuin ang transport bago hawakan ang password. Ang pagpapalit ng kredensyal para habulin ang 807 ay iniiwan ang tunay na depekto sa puwesto at ginagawang mas mahirap basahin ang susunod na pagtatangka.

Bakit sinisira ng ikalawang client ang gumaganang tunnel

Dahil walang port na makapagtatangi sa kanila, hindi maihihiwalay ng NAT device ang dalawang PPTP client tulad ng paghihiwalay nito sa dalawang HTTPS session. Maraming consumer device ang nagpapahintulot lamang ng isang PPTP call at sinusubaybayan ito sa pamamagitan ng source address. Ang laptop na gumana nang mag-isa ay tumitigil sa pagkumpleto kapag may ikalawang makina na tumatawag, at mula sa panig ng client ang kabiguan ay mukhang random. Ang pattern na iyon ay pag-aari ng firmware, at walang pagbabago ng profile ang makakabago nito.

Panoorin ang talahanayan ng koneksyon habang tumatawag ang dalawang client. Kung tanging ang unang host ang may hawak ng mapping, naabot na ng router ang hangganan ng sinusuportahan nito at walang setting sa panig ng client ang makakagalaw nito.

Patunayan kung aling kalahati ang nabigo

Tiyakin na dumarating ang TCP 1723 bago baguhin ang anuman sa router, dahil ang sagot na iyon ang magpapasya kung aling kalahati ang sinusubok mo. Patakbuhin ang mga ito mula sa Windows client laban sa sarili mong pangalan ng server. Ang una ay nagpi-print kung sumagot ang port, at ang pangalawa ay tumatawag nang walang dialog, na ginagawang maihahambing ang mga paulit-ulit na pagtatangka.

Test-NetConnection vpn.example.com -Port 1723
rasdial "Work VPN"

Ang totoong resulta sa pagsubok ng port ay nangangahulugang bukas ang control channel at ang GRE ang natitirang pinaghihinalaan. Ang maling resulta ay nangangahulugang sira ang routing, isang filter o ang forward, at walang pagbabago sa GRE ang makakapagligtas niyon. Ang panig ng data ay dapat bantayan kung saan ito makikita, sa dulo ng server o sa router.

tcpdump -ni any proto 47

Ang katumbas sa Wireshark ay ang display filter ip proto 47, na mas madaling ibigay sa taong hindi komportable sa shell. Ang GRE na dumarating na walang lumalabas na sagot ay nangangahulugang kailangang ayusin ang return path.

Ano ang tunay na nag-aayos ng error

Kung saan inilalantad ng router ang setting, paganahin ang PPTP passthrough, o hayagang payagan ang protocol 47 sa firmware na tumatanggap ng mga tuntunin. Sa RouterOS ang forward rule ay direktang tumutugma sa protocol, na hindi kailanman magagawa ng port-based forward. Karaniwang itinatago ng consumer firmware ang parehong desisyon sa likod ng checkbox, kung minsan sa ilalim ng security settings kaysa sa ilalim ng port forwarding. Kung wala ang gayong kontrol, wala sa client ang makakabayad nito.

/ip firewall filter add chain=forward protocol=gre action=accept
/ip firewall filter print where protocol=gre

Ang pagpapalit ng PPTP ay ang iba pang opsyon at madalas ang mas mura. Ang router na mismo ang nagtatapos ng VPN ay umiiwas sa double NAT para sa mga papasok na client, at ang protocol na hinahawakan na ng port-based NAT ay hindi na kailangan ng passthrough: OpenVPN sa UDP, SSTP sa TCP 443, o L2TP/IPsec na may NAT-T na nagbabalot ng ESP sa UDP 4500. Ang PPTP ay umaasa rin sa MS-CHAPv2, na ang mga dokumentadong kahinaan ay ginagawa itong masamang pagpipilian para sa bagong deployment kahit matapos mawala ang error.

Isulat kung aling tuntunin ang gumawa ng pagkakaiba, dahil ang parehong site ay makakatagpo ng parehong hangganan kapag humingi ng access ang ikalawang gumagamit. Ang pag-aayos sa antas ng protocol ay nabibilang sa mga tala ng network, kung saan titingin ang susunod na inhinyero.