پینگ فقط در یک جهت کار می‌کند: چرا Windows بازتاب سرور را دور می‌ریزد

کلاینت شما به سرور پینگ می‌زند، سرور نمی‌تواند به کلاینت پینگ بزند، و تونل در هر دو جمله آشکارا بسته‌ها را حمل می‌کند. آنچه تفاوت دارد مسیر نیست، بلکه نخستین بسته هر آزمون است: یکی پاسخ به جریانی است که Windows از پیش دنبال می‌کند، دیگری درخواست ورودی تازه‌ای است که هیچ قاعده‌ای آن را نپذیرفته. همین تفاوت بیشتر گزارش‌های پینگ یک‌طرفه را توضیح می‌دهد و مستقیماً به قاعده‌ای اشاره می‌کند که باید بنویسید. دو آزمون در جهت‌های مخالف این حالت‌ها را در حدود یک دقیقه از هم جدا می‌کنند.

دو جهت، دو تصمیم متفاوت

وقتی کلاینت درخواست بازتاب را می‌فرستد، دیوار آتش Windows یک اتصال خروجی می‌بیند که به اجازه دادنش تصمیم گرفته است. پاسخ درون همان جریان برقرارشده برمی‌گردد، پس موتور حالت‌دار آن را می‌پذیرد بی‌آنکه هیچ قاعده ورودی برای ICMP را بپرسد. معنای عملی فیلتر کردن حالت‌دار همین است، و قاعده‌ای که هیچ‌کس ننوشته در میان نیست. بنابراین موفقیت کلاینت هیچ چیزی درباره سیاست ورودی نمی‌گوید.

وقتی سرور درخواست را نخست می‌فرستد، هیچ حالتی با آن مطابقت ندارد. Windows بسته را اتصال ورودی تازه‌ای می‌داند و از سیاست ورودی می‌پرسد، که به‌طور پیش‌فرض هیچ ترتیبی برای درخواست‌های بازتاب از منابع دلبخواه ندارد.

پس موفقیت کلاینت ثابت کرد که ICMP خروجی و مسیر بازگشت کار می‌کنند. هرگز تصمیم ورودی را نمی‌آزمود، و نتیجه طبیعی، یعنی سالم بودن دیوار آتش، معقول و نادرست است. به همین دلیل این خطا در تیکت‌هایی که از پیش شاهد را دارند تکرار می‌شود.

بسته را تا ناپدید شدن دنبال کنید

پیش از تغییر هر چیزی نشانی‌ها را تأیید کنید: نشانی تونلی را به کار ببرید که کلاینت واقعاً دارد، و بررسی کنید که سرور به همان مسیر می‌دهد و نه به نشانی LAN پشت کلاینت. دو شکست از خط فرمان سرور یکسان به نظر می‌رسند، چون هر دو به پایان مهلت ختم می‌شوند. اینکه بسته کجا می‌میرد تنها واقعیتی است که تعیین می‌کند چه چیزی را تغییر دهید.

اگر درخواست به رابط تونل برسد و چیزی خارج نشود، دیوار آتش محلی دلیل احتمالی است. اگر هرگز به رابط نرسد، پاسخ در بالادست است: یک مسیر روی سرور، یک سیاست خروجی، یا تحویل همتای خود VPN.

هنگامی که سرور پینگ می‌زند، روی رابط تونل کلاینت ثبت بگیرید. دیدن رسیدن درخواست بدون پاسخی در کنارش همان شاهدی است که نوشتن یک قاعده 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. اجازه گسترده همان راه‌حل آسان و ماندگارترین است، چون پس از آن هیچ‌کس متوجهش نمی‌شود.

روی دستگاهی مدیریت‌شده ممکن است قاعده در تازه‌سازی بعدی سیاست جایگزین شود، پس مالک سیاست باید تغییر معادل را انجام دهد نه یک مدیر محلی. قصد را همراه با دستور در تیکت بنویسید، چون تازه‌سازی دستور را پاک می‌کند و الزام را دست‌نخورده باقی می‌گذارد. این دو یک مصنوع نیستند، و تنها یکی از آنها می‌ماند.

نتیجه را در جهت درست بخوانید

پس از اعمال قاعده، از سرور پینگ بزنید و تأیید کنید که پاسخی به کلاینت می‌رسد، سپس از منبعی که باید همچنان بیرون بماند پینگ بزنید و تأیید کنید که نمی‌رسد. اگر تونل یکی را حمل می‌کند، آزمون دسترسی‌پذیری را روی خانواده نشانی دیگر تکرار کنید.

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

چاپ قاعده‌ای که به اجرا درآمده از اعتماد به دستوری که آن را ساخته سودمندتر است، چون پیش‌نمایش و قاعده اعمال‌شده دو حالت متفاوت‌اند. اگر فیلتر نشانی همان منبعی را نشان دهد که در نظر داشتید و منبع استثناشده همچنان به پایان مهلت بخورد، قاعده دقیقاً همان چیزی را می‌کند که دامنه‌اش می‌گوید. پینگ موفق از سمت کلاینت هرگز این را نشان نمی‌داد، و به همین دلیل جهت هر آزمون در سابقه کنار نتیجه‌اش جای دارد. هر دو جهت را در تیکت نگه دارید، وگرنه خواننده بعدی آزمونی را تکرار می‌کند که نمی‌تواند شکست بخورد.