PPTP passthrough haipo: rekebisha hitilafu 807 ya VPN ya Windows

Kuelekeza TCP 1723 mara nyingi husafisha sehemu ya kwanza ya PPTP na kuacha nyingine ikiwa imevunjika, kwa hiyo Windows bado hurudisha hitilafu 807 kwenye jaribio. Msisitizo unaofuata ni kuongeza kanuni ya bandari 47, na hatua hiyo ndiyo inayotumia mchana mzima: GRE ni namba ya itifaki katika kichwa cha IP, si bandari ambayo jedwali la uelekezaji linaweza kuoanisha. Hadi kipanga njia kipitishe itifaki 47 na kuiunganisha na mwito huo huo, handaki haliwezi kuanza. Sehemu zifuatazo hutenganisha njia mbili, kisha kuzijaribu moja baada ya nyingine.

Jedwali la bandari halina mstari wa namba ya itifaki

PPTP hutumia mazungumzo mawili ambayo hushindwa kwa namna tofauti. Lile la TCP 1723 huanzisha mwito, hupitisha taarifa za kiungo na kulivunja mtumiaji anapokata muunganisho. Upande wa mzigo huendeshwa ndani ya GRE, ambayo kichwa cha IP huiweka alama kwa namba ya itifaki 47, na ndani ya handaki hilo PPP hujadili kiungo huku MS-CHAPv2 ikikagua utambulisho.

Kwa kuwa GRE haina kichwa cha usafirishaji, haitoi bandari zozote, kwa hiyo kanuni iliyoandikwa kwa bandari haina cha kuoanisha. Kipanga njia kinachoelekeza 1723 huunda ramani ya kikao hicho cha TCP na kuishia hapo. Firmware inayoshughulikia nusu ya pili huiita kipengele hiki PPTP passthrough au PPTP ALG, na firmware nyingine haitoi kimoja wala kingine na kamwe haitaji pengo hilo. Lebo kwenye kisanduku cha kuchagua ni ya maana ndogo kuliko kama itifaki 47 inatambulika kabisa.

Windows huripoti nini njia ya data inapokufa

Hitilafu 807 inasema muunganisho haukuweza kukamilika, ambayo kwa vitendo inamaanisha mwito ulifika kwenye seva na njia ya data haikupanda. Ni uamuzi kuhusu usafirishaji, si uamuzi kuhusu akaunti. Hitilafu 691 ndiyo inayoelekeza kwenye utambulisho au kutokulingana kwa itifaki ya uthibitishaji, kwa hiyo inakupeleka mahali pengine kabisa.

Fanyia kazi usafirishaji kabla ya kugusa nenosiri. Kubadilisha utambulisho kufuatilia 807 huacha hitilafu halisi mahali pake na kufanya jaribio lifuatalo kuwa gumu kusoma.

Kwa nini mteja wa pili huvunja handaki linalofanya kazi

Bila bandari za kuwatofautisha, kifaa cha NAT hakiwezi kutenganisha wateja wawili wa PPTP kama inavyotenganisha vikao viwili vya HTTPS. Kwa hiyo vifaa vingi vya watumiaji huruhusu mwito mmoja wa PPTP na kuufuatilia kwa anwani ya chanzo. Laptop iliyofanya kazi peke yake huacha kukamilisha mara mashine ya pili inapopiga simu, na kwa upande wa mteja kushindwa huonekana kama bahati nasibu. Mchoro huo ni wa firmware, na hakuna mabadiliko ya wasifu yatakao ubadilisha.

Tazama jedwali la miunganisho wakati wateja wote wawili wanapiga. Ikiwa tu mwenyeji wa kwanza ndiye anayeshikilia ramani, kipanga njia kimefika ukingo wa kile kinachosaidiwa na hakuna mpangilio wa upande wa mteja utakao kisogeza.

Thibitisha ni nusu ipi inashindwa

Thibitisha kwamba TCP 1723 inafika kabla ya kubadilisha chochote kwenye kipanga njia, kwa sababu jibu hilo huamua ni nusu ipi unajaribu. Zifanye kutoka kwa mteja wa Windows dhidi ya jina lako mwenyewe la seva. Ya kwanza huchapisha kama bandari ilijibu, na ya pili hupiga bila mazungumzo, jambo linalofanya majaribio ya kurudia kulinganishika.

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

Matokeo ya kweli kwenye jaribio la bandari yanamaanisha njia ya udhibiti iko wazi na GRE ndiye mtuhumiwa aliyebaki. Matokeo ya uongo yanamaanisha uelekezaji, kichujio au uelekezaji wa mbele umevunjika, na hakuna mabadiliko ya GRE yatakayo okoka. Upande wa data lazima uangaliwe mahali panapoweza kuonekana, upande wa seva au kwenye kipanga njia.

tcpdump -ni any proto 47

Kilinganisho cha Wireshark ni kichujio cha kuonyesha ip proto 47, ambacho ni rahisi kumpa mtu asiye na raha kwenye shell. GRE inayofika bila chochote kutoka kama jibu inamaanisha njia ya kurudi inahitaji kurekebishwa.

Nini kwa kweli hurekebisha hitilafu

Mahali kipanga njia kinapofichua mpangilio, washa PPTP passthrough, au ruhusu itifaki 47 kwa uwazi kwenye firmware inayokubali kanuni. Kwenye RouterOS kanuni ya forward inaoanisha itifaki moja kwa moja, jambo ambalo uelekezaji wa mbele wa msingi wa bandari haungeweza kamwe. Firmware ya watumiaji kwa kawaida huficha uamuzi huo huo nyuma ya kisanduku cha kuchagua, wakati mwingine chini ya mipangilio ya usalama badala ya chini ya uelekezaji wa bandari. Ikiwa udhibiti kama huo haupo, hakuna kitu kwa upande wa mteja kitakachofidia.

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

Kubadilisha PPTP ni chaguo lingine na mara nyingi la bei nafuu. Kipanga njia kinachokamilisha VPN yenyewe huepuka NAT mara mbili kwa wateja wanaoingia, na itifaki ambayo NAT ya msingi wa bandari tayari inashughulikia haihitaji passthrough yoyote: OpenVPN kwa UDP, SSTP kwa TCP 443, au L2TP/IPsec na NAT-T inayofunga ESP ndani ya UDP 4500. PPTP pia hutegemea MS-CHAPv2, ambayo udhaifu wake uliorekodiwa huifanya chaguo mbaya kwa usambazaji mpya hata baada ya hitilafu kuondoka.

Andika ni kanuni ipi iliyofanya tofauti, kwa sababu tovuti hiyo hiyo itakutana na kikomo hicho hicho mtumiaji wa pili anapoomba ufikiaji. Marekebisho ya ngazi ya itifaki yanapaswa kuwa kwenye maelezo ya mtandao, ambapo mhandisi anayefuata ataangalia.