Ինչու է RDP-ն սառչում, երբ հեռավոր համակարգիչը միանում է VPN-ին

Դուք RDP-ի պատուհանի ներսում եք, աշխատասեղանը էկրանին է, և սեղմում եք Connect այն VPN-հաճախորդում, որը աշխատում է այդ հեռավոր մեքենայում։ Մի քանի վայրկյան անց պատուհանը սառչում է, ապա փակվում։ Թունելը բարձրացավ, հենց դա է գրանցելու VPN-ի մատյանը, և դա է ամբողջ միջադեպի ամենաանօգուտ փաստը։ Սեսիան մահացավ, որովհետև այն մեքենան, որի հետ խոսում էիք, փոխել է ձեզ պատասխանելու եղանակը, ուստի ստուգեք վերադարձի ուղին նախքան թունելին դիպչելը։

Նշեք այն վերջնակետը, որն իրականում օգտագործում է ձեր սեսիան

RDP-հաճախորդում մուտքագրված հասցեն պարտադիր չէ, որ լինի այն հասցեն, որին պատասխանում է հեռավոր համակարգիչը։ NAT-ը, RD Gateway-ը կամ հոսթի առջևի բեռնվածքի հավասարակշռիչը կարող են վերաշարադրել այն, և վերադարձի ուղին որոշվում է այն աղբյուրի հասցեով, որը հեռավոր մեքենան տեսնում է հաստատված կապի վրա։ Այստեղ սխալվելը ձեզ ուղարկում է փնտրելու ուղի, որը երբեք չի մասնակցել։

Հեռավոր համակարգչում, մինչև VPN-ը միացած չէ, թվարկեք հաստատված սեսիաները և կարդացեք զուգընկերի հասցեն աղյուսակից։ Ապա գրեք այն այդ մեքենայից դուրս ինչ-որ տեղ, որովհետև սեսիան ընկնելուց հետո չեք կարողանա կարդալ այն։

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

Վերաբերվեք այդ հասցեին որպես այն բանի, ինչը պետք է մնա հասանելի։ Եթե դա մասնավոր հասցե է կառավարման VLAN-ում, թունելը պետք է այդ ուղին հանգիստ թողնի։ Եթե դա հանրային հասցե է, պատասխանը պետք է դուրս գա այն նույն ինտերֆեյսով, որը հարցումը ներս բերեց։

Կարդացեք այն երթուղին, որը պատասխանում է այդ վերջնակետին

Windows-ը յուրաքանչյուր նպատակակետի համար ընտրում է ինտերֆեյս, և Find-NetRoute ցույց է տալիս այն որոշումը, որը նա կկայացներ հիմա։ Գործարկեք այն զուգընկերի հասցեի վրա նախքան միանալը, ապա կրկին թունելը բարձրացրած, և համեմատեք ինտերֆեյսի ինդեքսը և հաջորդ թռիչքը երկու պատասխաններում։ Ինտերֆեյսի փոփոխությունը ամբողջ սխալն է մեկ տող արտածման մեջ։

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

Լրիվ թունելի պրոֆիլը տեղադրում է լռելյայն երթուղի թունելի միջով, ինչպես Windows-ի VPN երթուղավորման ուղեցույցը նկարագրում է, ուստի յուրաքանչյուր պատասխան այժմ դուրս է գալիս VPN-ով և կախված է նրանից, թե արդյոք հակառակ կողմը երթուղավորում է հետ դեպի ձեր հաճախորդ։ Բաժանված թունելի պրոֆիլը լռելյայն ավելի ապահով է, բայց ոչ իմուն, որովհետև զուգընկերի հասցեն ծածկող կոնկրետ երթուղին դեռ կարող է հաղթել ֆիզիկական լռելյայն երթուղուն։ Ամեն դեպքում հարցը նույնն է՝ թունելը բարձրանալուց հետո զուգընկերի հասցեն դեռ լուծվում է այն ինտերֆեյսի վրա, որը սեսիան ներս բերեց։

Եթե ոչ, ուղղումը պատկանում է պրոֆիլին կամ VPN-քաղաքականության սեփականատիրոջ կողմից հաստատված բացահայտ բացառության երթուղուն։ Երթուղային աղյուսակը ձեռքով խմբագրելը արտադրական հոսթի վրա միջադեպի ժամանակ հենց այն ճանապարհն է, որով ժամանակավոր լուծումը դառնում է չփաստաթղթավորված կոնֆիգուրացիա։

Հետևեք բրենդմաուերի պրոֆիլի փոփոխությանը

Նոր ինտերֆեյսը դասակարգվում է հայտնվելիս, և դասակարգումը որոշում է, թե որ բրենդմաուերի պրոֆիլի համաձայն է գնահատվում նրա տրաֆիկը։ Public կատեգորիայում հայտնված թունելային ադապտերը կարող է լուռ կանգնեցնել ներգնա RDP-ն, նույնիսկ երբ երթուղային աղյուսակը կատարյալ է թվում։ Սա ձախողման երկրորդ ռեժիմն է, և այն տալիս է այլ ախտանիշ՝ երթուղին ճիշտ է, փաթեթները հասնում են, և հոսթը մերժում է կապը։

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

Համեմատեք թունելի ինտերֆեյսին կապված պրոֆիլը այն պրոֆիլների հետ, որոնց ուղղված են Remote Desktop-ի կանոնները։ Միայն Domain-ի և Private-ի համար միացված կանոնը ոչինչ չի անում Public դասակարգված ինտերֆեյսի համար, և ոչ մի երթուղու ուղղում դա չի փոխում։ Որոշ VPN-հաճախորդներ նաև նախագծով սահմանափակում են տեղական ենթացանցի հասանելիությունը, ինչը առաջացնում է ձախողման նույն ձևը մեկ այլ մեխանիզմից։

Փորձարկեք անցումը մի տեղից, որտեղից կարող եք վերականգնվել

Կատարեք ամբողջ հաջորդականությունը արտաքին կոնսոլից կամ երկրորդ կառավարման ուղուց, այս կարգով՝ հաստատեք գոյություն ունեցող սեսիան, միացրեք VPN-ը, բացեք նոր սեսիա, ապա անջատեք VPN-ը և բացեք ևս մեկը։ Յուրաքանչյուր քայլ փորձարկում է այլ անցում, և առաջին ձախողվածը ձեզ ասում է, թե որ մեխանիզմն է պատասխանատու։

Պլանավորեք հետ շրջումը նախքան սկսելը, օրինակ պլանավորված առաջադրանք, որը rasdial "Work VPN" /disconnect գործարկում է որոշակի ընդմիջումից հետո։ Դա կորցրած սեսիան վերածում է հինգ րոպեանոց ընդհատման՝ տեղում այցելության փոխարեն, և դա ամբողջ ընթացակարգի ամենաէժան ապահովագրությունն է։

Վերադարձեք ներս, երբ սեսիան արդեն գնացել է

Եթե հոսթն արդեն անհասանելի է, դադարեցրեք նույն հաճախորդից նոր RDP կապեր փորձելը և օգտագործեք վերականգնման այն ուղին, որ միջավայրն արդեն ունի՝ RD Gateway, հիպերվիզորի կոնսոլ կամ արտաքին կառավարման ինտերֆեյս։ Խնդրեք կոնսոլի հասանելիություն ունեցող անձին գործարկել նույն հրամանները Find-NetRoute և Get-NetConnectionProfile, որպեսզի ապացույցները վերապրեն վերականգնումը։

Ապա որոշեք մշտական կարգավորումը, ոչ թե ամենաարագը։ Կամ կառավարման ուղին բացահայտ պահպանվում է VPN-պրոֆիլով, կամ կառավարումը տեղափոխվում է մի ուղի, որը կախված չէ հոսթի լռելյայն երթուղուց։ Երկուսն էլ պաշտպանելի են. հոսթի երթուղին գուշակված դարպասով՝ ոչ։ Գրեք, թե որն եք ընտրել, և գրանցեք զուգընկերի այն հասցեն, որը պետք է դիմանար։