VPN հաճախորդները արգելափակվում են Windows-ի հանրային անվտանգության պատի պրոֆիլով

Ձեր թունելը բարձրացված է, դարպասը պատասխանում է ping-ին, իսկ ֆայլերի համօգտագործումը դեռ ժամանակի սպառում է տալիս։ Այդ համակցությունը հազվադեպ է երթուղավորման խնդիր: Windows-ը VPN ադապտերի ենթացանցը դրել է Հանրային պրոֆիլում, և յուրաքանչյուր թույլատրող կանոն, որը գրվել է Մասնավոր կամ Դոմեն պրոֆիլի համար, երբեք չի կիրառվել։ Ես սա հանդիպել եմ ինչպես նոթբուքերի վրա, որոնք առանց խնդրի հասնում են գրասենյակ, այնպես էլ RRAS սերվերների վրա, որոնք սպասարկում են մյուս բոլոր հաճախորդներին, և վերանորոգումը կարճ է, հենց որ անվանեք ներգրավված պրոֆիլը։ Ահա այն հերթականությունը, որով աշխատում եմ, այն ստուգմամբ, որը ձեզ ասում է՝ երբ կանգնել հաջորդ քայլից առաջ։

Պարզեք, թե որ պրոֆիլով է երթևեկությունն իրականում ժամանում

Windows-ի անվտանգության պատը չունի մեկ գլոբալ ռեժիմ։ Յուրաքանչյուր միացված ինտերֆեյս կրում է կատեգորիա, և մուտքային փաթեթները զտվում են այն ինտերֆեյսի կատեգորիայով, որով ժամանում են, ուստի թունելում գտնվող հաճախորդի հասանելիությունը որոշում է VPN ադապտերի պրոֆիլը, ոչ թե կողքի Wi-Fi կամ Ethernet ադապտերը։ Կարդացեք երկու փաստերն էլ՝ նախքան որևէ բան փոխելը:

Get-NetConnectionProfile | Select-Object Name, InterfaceAlias, NetworkCategory, IPv4Connectivity
Get-NetFirewallProfile -Name Public | Select-Object Name, Enabled, DefaultInboundAction

OpenVPN-ի կամ WireGuard-ի ստանդարտ տեղադրման դեպքում VPN ադապտերը հայտնվում է որպես չճանաչված ցանց և ընկնում Հանրային պրոֆիլ, ինչը լռելյայն է ցանկացած ցանցի համար, որը Windows-ը չի կարող դասակարգել: ոչ մի դոմենի կարգավորիչ չի պատասխանել դրա միջով, և ոչ մի դարպասի պրոֆիլ չի համապատասխանել։ Ինտերֆեյսի անունը այստեղ նշանակություն չունի, ուստի ադապտերը «VPN» կամ «Corp» անվանելը ոչինչ չի փոխում։ DomainAuthenticated-ը պահանջում է դոմենին միացված մեքենա , որը այդ ինտերֆեյսով իսկապես կարողանում է հասնել դոմենի կարգավորիչին, միայն մեկ ենթացանց կրող բաժանված թունելը չի բավարարի այդ պահանջը։

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

Հաստատեք զտումը, ոչ թե երթուղավորումը, նախքան կանոնները խմբագրելը

Ping-ը թույլ թեստ է։ ICMP-ն կարող է անցնել, մինչ ծառայության պորտը մերժվում է, և հոսթը կարող է պատասխանել LAN-ից՝ միաժամանակ մերժելով նույն հարցումը թունելով։ Փորձարկեք այն պորտը, որն անհրաժեշտ է հաճախորդին, հաճախորդից:

Test-NetConnection 10.8.0.1 -Port 445
Test-NetConnection 10.8.0.1 -Port 3389 -InformationLevel Detailed

Եթե պորտի թեստը ձախողվի, բաժանեք երկու շերտերը։ Թունելի կամ երթուղու անսարքությունը սովորաբար դրսևորվում է որպես դարպասի հասցեից ընդհանրապես պատասխան չգալը, մինչդեռ անվտանգության պատի մերժումը ցույց է տալիս պատասխանող դարպաս և չպատասխանող ծառայության պորտ։ RRAS-ով լողավազանը հրապարակող Windows սերվերի դեպքում կատարեք նույն թեստը հաճախորդից և կարդացեք սերվերի սեփական պրոֆիլը: RAS ինտերֆեյսը կարող է լինել կատեգորիայում, որի մուտքային կանոնները երբեք չեն հիշատակում հաճախորդների միջակայքը, և հենց դրա համար է, որ մեքենան սպասարկում է իր LAN-ը և մերժում թունելի յուրաքանչյուր հաճախորդի։

Երբ արդյունքը դեռ երկիմաստ է, գրանցեք ներգրավված պրոֆիլի մերժումները և կարդացեք դրանք:

Set-NetFirewallProfile -Name Public -LogBlocked True `
  -LogFileName "$env:systemroot\system32\LogFiles\Firewall\pfirewall.log"

DROP-ով հաճախորդի հասցեն ու պորտը նշող գրառումները վճռորոշ են և նաև ասում են, թե որ կանոնն էր բացակայում։ Մատյան, որում ոչինչ չկա, մինչ հաճախորդի SYN-ը երբեք չի հայտնվում, ցույց է տալիս հոսթից վերև, ուստի վերադարձեք թունելին, NAT կանոնին կամ լողավազանի երթուղուն՝ նախքան անվտանգության պատի մեկ այլ օբյեկտի դիպչելը։

Սահմանափակեք մեկ մուտքային կանոն հաճախորդների լողավազանով

Վերանորոգումը մեկ մուտքային թույլատրող կանոն է, որի հեռավոր հասցեն լողավազանն է, ոչ թե ամբողջ աշխարհը։ Բարձրացված նստաշրջանից:

New-NetFirewallRule -DisplayName "VPN clients - SMB 445" `
  -Direction Inbound -Action Allow -Protocol TCP -LocalPort 445 `
  -RemoteAddress 10.8.0.0/24 -Profile Public

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

Պրոֆիլի ընտրությունը այն տեղն է, որտեղ նույն սխալը գործվում է հակառակ ուղղությամբ։ -Profile Public բավարար է, երբ ադապտերը Հանրային է և մնում է Հանրային։ -Profile Any արդարացված է, երբ ծառայությունը պետք է աշխատի անկախ այն բանից, թե ինչպես է Windows-ը դասակարգում ադապտերը, բայց միայն այնքան ժամանակ, քանի դեռ հեռավոր շրջանակը մնում է։ Այն, ինչ երբեք արդարացված չէ, դա -RemoteAddress Any Հանրային պրոֆիլում: այդ կանոնը նոթբուքի հետ մտնում է յուրաքանչյուր սրճարանի և հյուրանոցի ցանց, որին այն միանում է, և պորտը բացում է բոլորի համար, ովքեր կիսում են այդ ենթացանցը։

Գրանցեք լողավազանը կանոնի կողքին։ -RemoteAddress 10.8.0.0/24 լուռ դադարում է համապատասխանել այն օրը, երբ VPN լողավազանը վերահամարակալվում է, և անսարքությունը ճիշտ նույն տեսքն ունի, ինչ սկզբնական սխալը, դրա համար էլ արժե երկրորդ կեսօր։ Անվանեք կանոնները ծառայության և աղբյուրի միջակայքի անունով, պահեք դրանք միասին -Group-ի հետ, և վերընթերցեք դրանք ամեն անգամ, երբ լողավազանի սահմանումը փոխվում է։ Կանոնների գույքագրումը, որը կարող եք ստուգել մեկ էկրանով, ավելի լավն է, քան ճիշտ կանոնը, որը ոչ ոք չի գտնում։

Փոխեք կատեգորիան միայն այն դեպքում, երբ կատեգորիան է որոշումը

Ինտերֆեյսը Մասնավորի վերածելը նույնպես աշխատում է, և դա սխալ լռելյայն է։ Մասնավոր պրոֆիլը կրում է ներկառուցված թույլատրող կանոնների երկար ցանկ՝ ընդգրկելով ֆայլերի և տպիչների համօգտագործում, ցանցի հայտնաբերում, հեռավոր աշխատասեղան և ավելին՝ կախված բազային գծից, ուստի VPN ադապտերի վերադասակարգումը միանգամից միացնում է դրանք բոլորին թունելի յուրաքանչյուր հաճախորդի համար։ Մեկ սահմանափակ կանոն մեկ ծառայություն է տալիս մեկ միջակայքի։ Նոթբուքում, որը միանում է նաև անվստահելի ցանցերին, այդ տարբերությունը կոսմետիկ չէ։

Կան դեպքեր, երբ դասակարգումն իսկապես սխալ է: մշտապես միացված կամ կայքերի միջև թունելը, որը կրում է գրասենյակի ենթացանց, վստահելի ենթակառուցվածք է, և այդ ադապտերը Մասնավոր նշելը օրինական նախագծային ընտրություն է՝ արված մեկ անգամ քաղաքականությամբ, ոչ թե յուրաքանչյուր տոմսով։ Երբ դա անում եք, արեք բացահայտ:

Set-NetConnectionProfile -InterfaceAlias "OpenVPN TAP-Windows6" -NetworkCategory Private

Կառավարվող սարքում նախ ստուգեք՝ արդյոք կարգավորումը պատկանում է խմբային քաղաքականությանը կամ MDM բազային գծին։ Եթե պատկանում է, տեղական փոփոխությունը չեղարկվում է հաջորդ թարմացման ժամանակ, և gpresult /h կնշի այն քաղաքականությունը, որը պատկանում է դրան, ուղղեք այն այնտեղ, ոչ թե վերջնակետում։

Ստուգեք երկու ծայրերից և հետք թողեք

Ստուգեք այն հոսքը, որը հայտնել է օգտատերը, հաճախորդից, փոփոխությունից հետո:

Test-NetConnection 10.8.0.1 -Port 445
Get-NetFirewallRule -DisplayName "VPN clients - SMB 445" | Get-NetFirewallAddressFilter | Select-Object RemoteAddress
Get-NetFirewallRule -DisplayName "VPN clients - SMB 445" | Get-NetFirewallPortFilter | Select-Object Protocol, LocalPort

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

Նախքան այն ավարտված համարելը:

• Կանոնում նշված պրոֆիլը այն ինտերֆեյսի պրոֆիլն է, որով ժամանում է երթևեկությունը։
• Հեռավոր շրջանակը VPN լողավազանն է, և այդ լողավազանը համապատասխանում է այն բանին, ինչ սերվերն իրականում տրամադրում է։
• Ձեր ավելացրած ոչ մի կանոն չի օգտագործում -RemoteAddress Any Հանրային պրոֆիլում։
• Ոչինչ չի անջատվել, որպեսզի թեստը անցնի, և կատեգորիայի յուրաքանչյուր փոփոխություն գրանցում է, թե ով է հաստատել այն։