Pam mae RDP yn rhewi pan fo’r cyfrifiadur o bell yn cysylltu â VPN

Rydych chi y tu mewn i ffenestr RDP, mae’r bwrdd gwaith ar y sgrin, ac rydych chi’n pwyso Connect yng nghleient VPN sy’n rhedeg ar y peiriant pell hwnnw. Eiliadau’n ddiweddarach mae’r ffenestr yn rhewi ac yna’n cau. Cododd y twnnel, sef yn union yr hyn y bydd log y VPN yn ei gofnodi, a dyna’r ffaith leiaf defnyddiol yn y digwyddiad cyfan. Bu farw’r sesiwn oherwydd bod y peiriant yr oeddech yn siarad ag ef wedi newid y ffordd y mae’n ateb, felly archwiliwch y llwybr dychwelyd cyn cyffwrdd â’r twnnel.

Cofnodwch y pen draw y mae eich sesiwn yn ei ddefnyddio mewn gwirionedd

Nid yw’r cyfeiriad a deipiwyd i’ch cleient RDP o reidrwydd yr un y mae’r cyfrifiadur pell yn ateb arno. Gall NAT, RD Gateway, neu falansydd llwyth o flaen y gwesteiwr ei ailysgrifennu, a’r cyfeiriad ffynhonnell y mae’r peiriant pell yn ei weld ar y cysylltiad sefydledig sy’n diffinio’r llwybr dychwelyd. Os gwnewch gamgymeriad yma, byddwch yn chwilio am lwybr na chymerodd ran erioed.

Ar y cyfrifiadur pell, cyn i’r VPN gysylltu, rhestrwch y sesiynau sefydledig a darllenwch gyfeiriad y cyfoed o’r tabl. Yna’i ysgrifennu rywle y tu allan i’r peiriant hwnnw, oherwydd ni fyddwch yn gallu ei ddarllen ar ôl i’r sesiwn ddod i lawr.

Get-NetTCPConnection -LocalPort 3389 -State Established |
  Select-Object LocalAddress, RemoteAddress, RemotePort

Trinnwch y cyfeiriad hwnnw fel y peth y mae’n rhaid iddo aros yn gyrhaeddadwy. Os yw’n gyfeiriad preifat ar VLAN rheoli, rhaid i’r twnnel adael y llwybr hwnnw’n llonydd. Os yw’n gyfeiriad cyhoeddus, rhaid i’r ateb fynd allan drwy’r un rhyngwyneb ag a ddaeth â’r cais i mewn.

Darllenwch y llwybr sy’n ateb y pen draw hwnnw

Mae Windows yn dewis rhyngwyneb ar gyfer pob cyrchfan, ac mae Find-NetRoute yn dangos y penderfyniad y byddai’n ei wneud nawr. Rhedwch ef yn erbyn cyfeiriad y cyfoed cyn cysylltu, yna eto gyda’r twnnel i fyny, a chymharwch fyrneg y rhyngwyneb a’r naid nesaf yn y ddau ateb. Newid rhyngwyneb yw’r gwall cyfan mewn un llinell allbwn.

Find-NetRoute -RemoteIPAddress 203.0.113.24
Get-NetRoute -DestinationPrefix 0.0.0.0/0 | Sort-Object RouteMetric
Get-VpnConnection -Name "Work VPN" | Select-Object SplitTunneling, Routes

Mae proffil twnnel llawn yn gosod llwybr diofyn drwy’r twnnel, fel y mae canllaw Windows ar gyfer llwybro VPN yn ei ddisgrifio, felly bellach mae pob ateb yn gadael drwy’r VPN ac yn dibynnu ar y tu arall yn llwybro’n ôl at eich cleient. Mae proffil twnnel hollt yn fwy diogel yn ddiofyn ond nid yw’n imiwn, oherwydd gall llwybr penodol sy’n cwmpasu cyfeiriad y cyfoed guro’r llwybr diofyn corfforol o hyd. Beth bynnag, mae’r cwestiwn yr un peth: ar ôl i’r twnnel godi, a yw cyfeiriad y cyfoed yn datrys o hyd i’r rhyngwyneb a ddaeth â’r sesiwn i mewn?

Os nad yw, mae’r cywiriad yn perthyn i’r proffil neu i lwybr eithriad penodol a gymeradwywyd gan berchennog polisi’r VPN. Golygu’r tabl llwybro â llaw ar westieiwr cynhyrchu yn ystod digwyddiad yw’r ffordd y mae gwaith dros dro yn troi’n ffurfweddiad heb ei ddogfennu.

Gwylwch y newid ym mhroffil y mur gwal

Mae rhyngwyneb newydd yn cael ei ddosbarthu pan ymddengys, a’r dosbarthiad sy’n penderfynu pa broffil mur gwal y bernir ei draffig yn ei erbyn. Gall addasydd twnnel sy’n glanio yn y categori Public atal RDP sy’n dod i mewn yn dawel er bod y tabl llwybro’n edrych yn berffaith. Dyma’r ail fodd methu, ac mae’n cynhyrchu symptom gwahanol: mae’r llwybr yn iawn, mae’r pecynnau’n cyrraedd, ac mae’r gwesteiwr yn gwrthod y cysylltiad.

Get-NetConnectionProfile
Get-NetFirewallProfile | Select-Object Name, Enabled
Get-NetFirewallRule -DisplayGroup "Remote Desktop" | Select-Object Name, Enabled, Profile

Cymharwch y proffil sy’n gysylltiedig â rhyngwyneb y twnnel â’r proffiliau y mae rheolau Remote Desktop wedi’u cwmpasu iddynt. Nid yw rheol a alluogir ar gyfer Domain a Private yn unig yn gwneud dim i ryngwyneb a ddosbarthwyd fel Public, ac nid oes unrhyw gywiriad llwybr yn newid hynny. Mae rhai cleientiaid VPN hefyd yn cyfyngu mynediad i’r isrwydwaith lleol yn ôl eu cynllun, sy’n cynhyrchu’r un siâp methiant o reol wahanol.

Profwch y trosglwyddiad o rywle y gallwch adfer ohono

Gwnewch y dilyniant cyfan o gonsol all-gyfrwng neu ail lwybr rheoli, yn y drefn hon: cadarnhewch y sesiwn bresennol, cysylltwch y VPN, agorwch sesiwn newydd, yna datgysylltwch y VPN ac agor un arall. Mae pob cam yn profi trosglwyddiad gwahanol, a’r cyntaf i fethu sy’n dweud wrthych pa reol sy’n gyfrifol.

Trefnwch y gwrthdroad cyn dechrau, er enghraifft tasg a drefnwyd sy’n rhedeg rasdial "Work VPN" /disconnect ar ôl cyfwng penodol. Mae hynny’n troi sesiwn a gollwyd yn ymyrraeth pum munud yn lle ymweliad â’r safle, a dyna’r yswiriant rhataf yn y weithdrefn gyfan.

Ewch yn ôl i mewn pan fo’r sesiwn eisoes wedi mynd

Os yw’r gwesteiwr eisoes yn anghyrhaeddadwy, stopiwch geisio cysylltiadau RDP newydd o’r un cleient a defnyddiwch y sianel adfer sydd eisoes gan yr amgylchedd: RD Gateway, consol hypervisor, neu ryngwyneb rheoli all-gyfrwng. Gofynnwch i’r person sydd â mynediad at y consol redeg yr un gorchmynion Find-NetRoute a Get-NetConnectionProfile, fel bod y dystiolaeth yn goroesi’r adferiad.

Yna penderfynwch y trefniant parhaol yn hytrach na’r un cyflymaf. Naill ai mae’r llwybr rheoli’n cael ei gadw’n benodol gan broffil y VPN, neu mae rheolaeth yn symud i sianel nad yw’n dibynnu ar lwybr diofyn y gwesteiwr. Mae’r ddau yn gynaliadwy; nid yw llwybr gwesteiwr gyda phorth bychan a ddyfalwyd. Ysgrifennwch pa un a ddewisoch, a chofnodwch gyfeiriad y cyfoed a oedd yn gorfod goroesi.