آیا فایروال VPN را مسدود می‌کند؟ بررسی گام‌به‌گام
پایان مهلت مقصر را نام نمی‌برد. شنونده، مسیر و گزارش امنیتی را به ترتیب بررسی کنید و تنها زمانی یک قاعده را تغییر دهید که شواهد به آن اشاره کند.
یک پایان مهلت VPN ثابت می‌کند که هیچ پاسخ قابل استفاده‌ای نرسیده است و درباره چرایی هیچ چیزی را ثابت نمی‌کند. ممکن است پروفایل پورت اشتباه را ذکر کند، سرور خاموش باشد، یا درخواست بدون مسیر بازگشت کارا برسد. هر یک از این‌ها ردپای متفاوتی بر جای می‌گذارد و همان ردپا می‌گوید کدام قاعده را لمس کنید. چهار مرحله زیر را به ترتیب انجام دهید. به‌محض اینکه یکی از آن‌ها نشانه را توضیح داد، متوقف شوید.
گام 1: سرور و انتقال را تأیید کنید
نام سرور، انتقال و پورت را از پروفایل فعلی اپراتور بخوانید، نه از یک ویرایش محلی. پورتی که روی لپ‌تاپ شما تغییر کرده نمی‌تواند روی سرور عمومی شنونده بسازد و این ناسازگاری همان پایان مهلتی را می‌دهد که یک مسدودسازی می‌دهد. اگر پروفایل یک انتقال جایگزین پشتیبانی‌شده ارائه می‌دهد، آن را به‌عنوان جایگزین یادداشت کنید نه به‌عنوان راه‌حل. نام را تفکیک کنید و پاسخ را با نشانی‌ای که اپراتور منتشر کرده مقایسه کنید.
یک رکورد DNS کهنه مشتری را به میزبانی می‌فرستد که هرگز پاسخ نداده است. این هم نقص دیگری است که وانمود به فیلتر می‌کند و رد کردن آن یک پرس‌وجو هزینه دارد.
هر دو مقدار را در تیکت بنویسید. هر مقایسه بعدی از آن‌ها استفاده می‌کند و تیکت بدون آن‌ها بررسی را از نو آغاز می‌کند.
گام 2: مسیر را با یک مقایسه کنترل‌شده اثبات کنید
دستگاه و پروفایل را بدون تغییر بگذارید و شبکه دسترسی مطمئن دیگری را امتحان کنید. اگر تونل آنجا بالا بیاید، تفاوت در مسیر اصلی یا سیاست آن است. اگر دستگاه تأییدشده دومی روی شبکه اصلی کار کند، تفاوت در دستگاه اول است. یکی از این دو مقایسه تقریباً همیشه تعیین‌کننده است.
ابتدا هر ورود مشروع به شبکه را کامل کنید، زیرا دروازه اسیر تا کامل نشود مانند مسدودسازی به نظر می‌رسد.
پورتی را که واقعاً استفاده می‌کنید آزمایش کنید و نتیجه TCP را اطلاعاتی فقط درباره TCP بدانید.
Resolve-DnsName vpn.corp.example
tracert -h 8 -w 500 vpn.corp.example
Test-NetConnection vpn.corp.example -Port 443 -InformationLevel Detailedیک دست‌دادن TCP موفق روی پورت 443 می‌گوید شنونده‌ای آنجا پاسخ داده است. درباره شنونده UDP روی 51820 و درباره کامل شدن مذاکره هیچ نمی‌گوید.
گام 3: رویدادهای امنیتی لحظه شکست را بخوانید
رویدادهای فایروال قوی‌ترین شواهد موجودند و هشداری دارند که ارزش دارد نخست گفته شود. ثبت رویداد در بسیاری از پروفایل‌های پیش‌فرض خاموش است، پس پیش از خواندن گزارش خالی به‌عنوان دلیل بی‌گناهی بررسی کنید که پروفایل مربوطه افت‌ها را ثبت می‌کند یا نه. وقتی ثبت روشن است، رویداد قاعده، جهت و نشانی‌ها را ذکر می‌کند و این دقیقاً همان چیزی است که تغییر قاعده لازم دارد. قواعد برنامه و قواعد پورت اشیای جداگانه‌اند و سیاست مدیریت‌شده می‌تواند تنظیم محلی را نادیده بگیرد. تأیید کنید که یک قاعده واقعاً کدام مشتری و کدام سرویس را پوشش می‌دهد.
وضعیت پروفایل و رویدادهای اخیر را از ماشینی که شکست خورده جمع کنید، نه از میزبان همسایه.
زمان رویداد را با زمان تلاش آزمایشی خود مقایسه کنید، زیرا نام قاعده یکسان با زمان مهر متفاوت یک تصادف است.
Get-NetFirewallProfile | Select-Object Name, Enabled, DefaultInboundAction, LogBlocked
Get-NetFirewallRule -Enabled True -Direction Outbound | Where-Object DisplayName -match 'VPN'
Get-WinEvent -LogName 'Microsoft-Windows-Windows Firewall With Advanced Security/Firewall' -MaxEvents 20روی سروری که مدیریت می‌کنید بپرسید آیا درخواست اصلاً به شنونده رسیده است. بسته‌ای که بدون پاسخ برسد مشکل ارسال یا مسیر بازگشت است. درخواستی که هرگز ظاهر نمی‌شود مشکل فیلتر یا نشانی‌دهی است.
گام 4: پس از بالا آمدن تونل، ارسال را آزمایش کنید
فایروال می‌تواند نشست را اجازه دهد و همچنان هر چیزی را که نشست می‌خواهد به آن برسد رد کند. sysctlهای ارسال، قواعد NAT و مسیرهای بازگشت همه پس از احراز هویت قرار دارند و یک استثنای گسترده برای پورت VPN هیچ‌یک را درست نمی‌کند. یک مقصد داخلی و یک مقصد اینترنتی را جداگانه آزمایش کنید، زیرا معمولاً به دلایل متفاوت شکست می‌خورند. اگر نام‌های داخلی شکست بخورند اما نشانی‌ها کار کنند، پیش از هر قاعده‌ای به DNS هل‌داده نگاه کنید.
سه بررسی زیر را روی سرور اجرا کنید، در حالی که مشتری متصل است و درخواست شکست‌خورده را می‌آزماید.
شمارنده‌های روی واسط تونل نکته اصلی‌اند، زیرا نشان می‌دهند بسته‌ها وارد شده‌اند و آیا چیزی خارج شده است.
sysctl net.ipv4.ip_forward
nft list ruleset | grep -n -E 'forward|masquerade'
tcpdump -ni tun0 -c 10وقتی بسته‌ها به تونل می‌رسند و چیزی به سمت مقصد خارج نمی‌شود، مظنون ارسال یا NAT است. وقتی هیچ چیزی نمی‌رسد، نشست بالاست اما مشتری نمی‌فرستد و جای نگاه کردن جدول مسیر مشتری است.
اصلاح را بررسی کنید و آنچه کمکی نکرد حذف کنید
پس از یک تصحیح تأییدشده، دقیقاً همان آزمایشی را که شکست خورد تکرار کنید و نتیجه را در برابر همان پروفایل و دستگاه ثبت کنید. سپس هر استثنای موقتی را که نتیجه را تغییر نداد حذف کنید، زیرا استثناهای بی‌استفاده انباشته می‌شوند و هر یک تصمیمی است که هیچ‌کس به یاد ندارد گرفته است. آنچه می‌ماند را باریک نگه دارید: یک مقصد، یک پورت، یک جهت، یک مالک.
همان سه فرمان را دوباره اجرا کنید و آن‌ها را با خروجی‌هایی که پیش از تغییر ذخیره کرده‌اید مقایسه کنید.
Test-NetConnection vpn.corp.example -Port 443 -InformationLevel Detailed
tracert -h 8 -w 500 vpn.corp.example
Get-NetFirewallRule -Enabled True | Where-Object DisplayName -match 'VPN' | Select-Object DisplayName, Actionوقتی شبکه مقایسه کار می‌کند، شبکه اصلی همچنان شکست می‌خورد و رویدادها خالی می‌مانند، مظنون باقی‌مانده مسیر است نه میزبان. آن را به‌عنوان یک گزاره مشخص با هر دو نتیجه مقایسه پیوست‌شده به مالک شبکه بسپارید. اینجا جای بهتری برای توقف است تا یک پروفایل فایروال غیرفعال.