Pasio PPTP ar goll: trwsio gwall 807 VPN Windows

Yn aml mae anfon TCP 1723 ymlaen yn agor rhan gyntaf PPTP ac yn gadael y gweddill wedi torri, felly mae Windows yn dal i ddychwelyd gwall 807 ar yr ymgais. Y redfa nesaf yw ychwanegu rheol ar gyfer porth 47, a dyna’r cam sy’n gwastraffu prynhawn: rhif protocol yn y pennawd IP yw GRE, nid porth y gall tabl anfon ei gyfateb. Nes bod y llwybrydd yn pasio protocol 47 ac yn ei rwymo i’r un alwad, ni all y twnnel ddechrau. Mae’r adrannau isod yn gwahanu’r ddwy sianel, ac yna’n eu profi un ar y tro.

Nid oes rhes mewn tabl porthau ar gyfer rhif protocol

Mae PPTP yn defnyddio dwy sgwrs sy’n methu mewn ffyrdd gwahanol. Mae’r un ar TCP 1723 yn dechrau’r alwad, yn trosglwyddo gwybodaeth y ddolen ac yn ei therfynu pan fydd y defnyddiwr yn datgysylltu. Mae ochr y llwyth yn rhedeg y tu mewn i GRE, y mae’r pennawd IP yn ei labelu â rhif protocol 47, ac o fewn y twnnel hwnnw mae PPP yn trafod y ddolen tra bod MS-CHAPv2 yn gwirio’r manylion mewngofnodi.

Gan nad yw GRE yn cario pennawd cludiant, nid yw’n datgelu unrhyw borthladdoedd, felly nid oes gan reol a ysgrifennwyd ar gyfer porthladdoedd unrhyw beth i’w gyfateb. Mae llwybrydd sy’n anfon 1723 ymlaen yn creu mapio ar gyfer y sesiwn TCP honno ac yn stopio yno. Mae cadarnwedd sy’n trin yr ail hanner yn galw’r nodwedd yn basio PPTP neu’n PPTP ALG, ac mae rhai cadarnweddau’n cynnig y naill na’r llall ac yn peidio â sôn am y bwlch. Mae’r label ar y blwch ticio yn llai pwysig na ph’un a yw protocol 47 yn cael ei adnabod o gwbl.

Beth mae Windows yn ei adrodd pan fydd y llwybr data yn marw

Mae gwall 807 yn dweud na ellid cwblhau’r cysylltiad, sydd yn ymarferol yn golygu bod yr alwad wedi cyrraedd y gweinydd ac na chododd y sianel ddata. Barn ar gludiant yw hwn, nid barn ar y cyfrif. Gwall 691 yw’r un sy’n cyfeirio at fanylion mewngofnodi neu at gamgymharu protocol dilysu, felly mae’n eich anfon i rywle hollol arall.

Gweithiwch ar y cludiant cyn cyffwrdd â’r cyfrinair. Mae newid manylion mewngofnodi i erlid 807 yn gadael y gwall go iawn yn ei le ac yn gwneud yr ymgais nesaf yn anoddach i’w darllen.

Pam mae ail gleient yn torri twnnel sy’n gweithio

Gan nad oes porthladdoedd i’w gwahaniaethu, ni all dyfais NAT wahanu dau gleient PPTP fel y mae’n gwahanu dwy sesiwn HTTPS. Felly mae llawer o ddyfeisiau defnyddwyr yn caniatáu un alwad PPTP ac yn ei thracio drwy gyfeiriad y ffynhonnell. Mae gliniadur a weithiai ar ei ben ei hun yn rhoi’r gorau i gwblhau unwaith y bydd ail beiriant yn deialu, ac o ochr y cleient mae’r methiant yn edrych yn hap. Mae’r patrwm hwnnw’n perthyn i’r gadarnwedd, ac ni fydd unrhyw newid proffil yn ei newid.

Gwyliwch y tabl cysylltiadau tra bo’r ddau gleient yn deialu. Os mai dim ond y gwesteiwr cyntaf byth sy’n dal mapio, mae’r llwybrydd wedi cyrraedd terfyn yr hyn a gefnogir ac ni fydd unrhyw osodiad ar ochr y cleient yn ei symud.

Profwch pa hanner sy’n methu

Cadarnhewch fod TCP 1723 yn cyrraedd cyn newid unrhyw beth ar y llwybrydd, oherwydd mae’r ateb hwnnw’n penderfynu pa hanner rydych yn ei brofi. Rhedegwch y rhain o’r cleient Windows yn erbyn eich enw gweinydd eich hun. Mae’r cyntaf yn argraffu a atebodd y porthladd, ac mae’r ail yn deialu heb ddeialog, sy’n gwneud ymgeisiau ailadroddus yn gymharadwy.

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

Mae canlyniad gwir ar brawf y porthladd yn golygu bod y sianel reoli ar agor a mai GRE yw’r un sy’n aros dan amheuaeth. Mae canlyniad ffug yn golygu bod y llwybro, hidlydd neu’r anfon ymlaen wedi torri, ac ni fydd unrhyw newid GRE yn achub y rheini. Rhaid gwylio ochr y data lle gellir ei gweld, ar y gweinydd neu ar y llwybrydd.

tcpdump -ni any proto 47

Y cyfatebol yn Wireshark yw’r hidlydd arddangos ip proto 47, sy’n haws ei roi i rywun nad yw’n gyffyrddus ar linell orchymyn. Mae GRE yn cyrraedd heb ddim yn gadael mewn ateb yn golygu bod angen trwsio’r llwybr dychwelyd.

Beth sy’n trwsio’r gwall mewn gwirionedd

Lle mae’r llwybrydd yn dangos y gosodiad, galluogwch basio PPTP, neu caniatáu protocol 47 yn benodol ar gadarnwedd sy’n derbyn rheolau. Ar RouterOS mae’r rheol anfon ymlaen yn cyfateb y protocol yn uniongyrchol, rhywbeth na allai anfon ymlaen ar sail porthladdoedd ei wneud byth. Mae cadarnwedd defnyddwyr fel arfer yn cuddio’r un penderfyniad y tu ôl i flwch ticio, weithiau o dan osodiadau diogelwch yn hytrach nag o dan anfon porthladdoedd ymlaen. Os nad oes rheolaeth o’r fath, ni fydd dim ar y cleient yn ei wneud yn iawn.

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

Mae disodli PPTP yn opsiwn arall ac yn aml yn rhatach. Mae llwybrydd sy’n terfynu’r VPN ei hun yn osgoi NAT dwbl ar gyfer cleientiaid sy’n dod i mewn, ac nid oes angen pasio o gwbl ar brotocol y mae NAT ar sail porthladdoedd eisoes yn ei drin: OpenVPN dros UDP, SSTP dros TCP 443, neu L2TP/IPsec gyda NAT-T yn lapio ESP yn UDP 4500. Mae PPTP hefyd yn dibynnu ar MS-CHAPv2, ac mae ei wendidau dogfennedig yn ei wneud yn ddewis gwael ar gyfer defnydd newydd hyd yn oed ar ôl i’r gwall glirio.

Nodwch pa reol a wnaeth y gwahaniaeth, oherwydd bydd yr un safle yn cyfarfod yr un terfyn pan fydd yr ail ddefnyddiwr yn gofyn am fynediad. Mae trwsio ar lefel protocol yn perthyn i nodiadau’r rhwydwaith, lle bydd y peiriannydd nesaf yn edrych.