Ping-ը աշխատում է միայն մեկ ուղղությամբ. ինչու Windows-ը գցում է սերվերի արձագանքը

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

Երկու ուղղություն, երկու տարբեր որոշում

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

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

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

Հետևեք փաթեթին, մինչև այն անհետանա

Հաստատեք հասցեները նախքան որևէ բան փոխելը՝ օգտագործեք այն թունելի հասցեն, որն իրականում ունի հաճախորդը, և ստուգեք, որ սերվերը երթուղավորում է դրան, այլ ոչ թե հաճախորդի հետևում գտնվող LAN հասցեին։ Երկու ձախողումները սերվերի հրամանի տողից նույն տեսքն ունեն, որովհետև երկուսն էլ ավարտվում են ժամանակի սպառմամբ։ Թե որտեղ է մահանում փաթեթը, միակ փաստն է, որ որոշում է, թե ինչ փոխել։

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

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

Սահմանափակեք մեկ կանոն՝ ICMP-ն բացելու փոխարեն

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

Get-NetConnectionProfile
Get-NetAdapter | Where-Object Status -eq 'Up'
New-NetFirewallRule -DisplayName "VPN server echo" -Direction Inbound -Protocol ICMPv4 -IcmpType 8 -RemoteAddress 10.63.0.1 -InterfaceAlias "Office VPN" -Profile Private -Action Allow -WhatIf

ICMPv4 տիպ 8-ը արձագանքի հարցումն է՝ միակ հաղորդագրությունը, որին սերվերը պետք է պատասխան ստանա։ Սահմանափակեք այն սերվերի թունելի հասցեով և թունելի ինտերֆեյսով, և թողեք պրոֆիլը այնպիսին, ինչպիսին ադապտերն իրականում է։ Ցանցը վերանվանելը, որպեսզի այն համապատասխանի օրինակին, առանձին փոփոխություն է՝ իր իսկ հետևանքներով։

Ինչը կանոնը չի ծածկում

IPv6-ի արձագանքը այլ արձանագրություն է՝ այլ հաղորդագրության տիպով, ուստի ICMPv4-ի կանոնը դրա մասին ոչինչ չի ասում, և երկու ընտանիքներն էլ կրող թունելին անհրաժեշտ է իր սեփական կանոնը մյուսի համար։ Այս կանոնը նաև ոչ մի այլ բան չի բացում՝ RDP-ն, ֆայլերի փոխանակումը և մնացած բոլոր ծառայությունները դեռ կախված են իրենց սեփական քաղաքականությունից։ Սա է ամբողջ իմաստը՝ սահմանափակել մեկ նեղ կանոն լայն ICMP թույլտվություն միացնելու փոխարեն։ Լայն թույլտվությունը հեշտ լուծումն է և ամենաերկար ապրողը, որովհետև հետո ոչ ոք չի նկատում այն։

Կառավարվող սարքում կանոնը կարող է փոխարինվել քաղաքականության հաջորդ թարմացման ժամանակ, ուստի համարժեք փոփոխությունը պետք է անի քաղաքականության սեփականատերը, այլ ոչ թե տեղական ադմինիստրատորը։ Մտադրությունը գրեք տոմսում հրամանի հետ միասին, որովհետև թարմացումը կջնջի հրամանը և պահանջը կթողնի անփոփոխ։ Երկուսը նույն արտեֆակտը չեն, և միայն մեկն է վերապրում։

Կարդացեք արդյունքը ճիշտ ուղղությամբ

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

Get-NetFirewallRule -DisplayName "VPN server echo" | Get-NetFirewallAddressFilter
ping 10.63.4.17
ping -6 fd00:63::17

Ուժի մեջ մտած կանոնը տպելը ավելի օգտակար է, քան այն ստեղծած հրամանին վստահելը, որովհետև նախադիտումը և կիրառված կանոնը տարբեր վիճակներ են։ Եթե հասցեների զտիչը ցույց է տալիս նախատեսած աղբյուրը, և բացառված աղբյուրը դեռ ժամանակ է սպառում, ապա կանոնն անում է ճիշտ այն, ինչ ասում է նրա շրջանակը։ Հաճախորդից սկսված հաջող ping-ը երբեք չէր ցուցադրի դա, և այդ պատճառով յուրաքանչյուր փորձարկման ուղղությունը տեղ ունի արձանագրության մեջ՝ իր արդյունքի կողքին։ Պահեք երկու ուղղություններն էլ տոմսում, այլապես հաջորդ ընթերցողը կկրկնի այն փորձարկումը, որը չի կարող ձախողվել։