کلید قطع اضطراری پس از قطع اتصال VPN هم ترافیک را مسدود می‌کند

تونل رفته است، نماد شبکه عادی به نظر می‌رسد و هیچ چیز بارگذاری نمی‌شود. VPN را قطع کرده‌اید، یا حذفش کرده‌اید، یا دستگاه را دوباره راه‌اندازی کرده‌اید، و مسدودسازی‌ای که قرار بود هنگام قطع شدن از شما محافظت کند هنوز سرپا است. پنجره کلاینت نمی‌تواند این را توضیح دهد، چون کلاینت چیزی نیست که شما را مسدود می‌کند: تصمیم به نام شما در هسته نوشته شده و چیزی برای برداشتن آن باقی نمانده است. در Windows آن وضعیت در بستر فیلترکردن Windows قرار دارد؛ در Linux مجموعه‌ای از قواعد در iptables یا nftables است، اغلب با یک عکس لحظه‌ای که هنگام راه‌اندازی دوباره اجرا می‌شود. آنچه در ادامه می‌آید ترتیبی است که من به کار می‌برم: وضعیت را بخوانید، تنگ‌ترین شیء‌ای را که خرابی را توضیح می‌دهد حذف کنید و سپس هر چیزی را که مدام آن را برمی‌گرداند پیدا کنید.

کلید قطع اضطراری وضعیت هسته است، نه یک تنظیم

کلاینت‌های رومیزی مسدودسازی را با افزودن فیلترهایی پیاده می‌کنند که ترافیک بیرون تونل را رد می‌کنند. در Windows این‌ها فیلترهای WFP در لایه‌های تغییرمسیر اتصال و انتقال هستند و برخی از آن‌ها پایدارند: در انبار خط‌مشی Base Filtering Engine ثبت می‌شوند و هنگام راه‌اندازی دستگاه، پیش از اجرای هر نرم‌افزار VPN، بازیابی می‌شوند. کلاینت‌ها در زمان پاک‌سازی متفاوت‌اند. بعضی فیلترها را هنگام قطع اتصال برمی‌دارند، بعضی فقط هنگام خروج پاک، و بعضی فقط وقتی کلید قطع اضطراری اول خاموش شود. در حالی که مسدودسازی فعال است حذف کنید، یا فرایند را بکشید، و فیلترها می‌مانند.

معادل Linux یک قاعده drop یا reject در مسیر خروج است، گاهی یک قاعده ارسال، گاهی خط‌مشی زنجیره‌ای تغییرکرده. آن قواعد از فرایندی که آن‌ها را افزوده بیشتر عمر می‌کنند چون وضعیت هسته‌اند: کلاینت را بکشید، وادار به کرش کنید یا برق را قطع کنید، و هسته به انداختن بسته‌ها ادامه می‌دهد بی‌آنکه چیزی برای بازگرداندن آن بماند. یک بسته پایداری لایه دومی از دوام می‌افزاید: از مجموعه قواعد کنونی عکس لحظه‌ای می‌گیرد و آن را هنگام راه‌اندازی بازیابی می‌کند، پس شروع بعدی با مسدودسازی از پیش نصب‌شده آغاز می‌شود.

پیش از حذف هر چیزی وضعیت WFP را بخوانید

Windows ابزارهای لازم را همراه دارد. یک اعلان با دسترسی بالا اجرا کنید و وضعیت بستر را تخلیه کنید؛ خروجی در پوشه کاری به‌صورت wfpstate.xml ذخیره می‌شود.

netsh wfp show state
netsh wfp show filters
Get-Service bfe

در XML نام فروشنده رفته، یک کنش Block و لایه را جست‌وجو کنید. فیلترهای روی تغییرمسیر اتصال و انتقال همان‌هایی هستند که ترافیک عادی را می‌شکنند؛ فیلتری روی لایه پذیرش دریافت معمولاً علت شما نیست. اگر Base Filtering Engine اصلاً اجرا نمی‌شود، جای دیگری را بگردید، چون هیچ چیز دیگری نمی‌تواند آن فیلترها را اعمال کند.

نمای معمول دیوار آتش را هم بررسی کنید، چون بیشتر مردم فقط یکی از آن دو را می‌بینند:

netsh advfirewall show allprofiles
Get-NetFirewallProfile | Select-Object Name,Enabled,DefaultInboundAction

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

قواعد Linux را در همان نگارشی بخوانید که با آن حذف می‌کنید

iptables -S قواعد را به همان شکلی چاپ می‌کند که برای افزودنشان به کار می‌رود، و این خروجی را مستقیماً برای حذف قابل استفاده دوباره می‌کند. iptables -L -v -n شمارنده‌های بسته را می‌افزاید، و آن شمارنده‌ها می‌گویند آیا یک قاعده واقعاً با درخواست‌های ناموفق شما مطابقت دارد یا فقط در زنجیره نشسته است.

sudo iptables -S
sudo ip6tables -S
sudo iptables -t nat -S

خط‌مشی‌های زنجیره را بخوانید، نه فقط قواعد را: -P OUTPUT DROP ترافیک را حتی وقتی هیچ قاعده‌ای مطابقت ندارد مسدود می‌کند. IPv6 را جداگانه بررسی کنید، چون کلاینتی که هر دو خانواده را نصب می‌کند ممکن است پس از رفتن قواعد IPv4، مسدودسازی IPv6 را در جای خود بگذارد، و آنگاه نشانه به این بستگی دارد که برنامه کدام خانواده را ترجیح دهد. هر جا nftables به کار می‌رود، nft list ruleset را هم اجرا کنید؛ دو ابزار از طریق یک لایه سازگاری همزیستی می‌کنند و یک فهرست لزوماً هر قاعده‌ای را که می‌تواند بسته‌ای را بیندازد نشان نمی‌دهد.

تنگ‌ترین شیء‌ای را که خرابی را توضیح می‌دهد حذف کنید

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

Get-ScheduledTask | Where-Object TaskName -like '*vpn*'
Get-Service | Where-Object DisplayName -like '*vpn*'

فیلترهای پایدار آخرین راه‌اند. زیر HKLM\SYSTEM\CurrentControlSet\Services\BFE\Parameters\Policy\Persistent\Filter قرار دارند، برای هر فیلتر یک مقدار با کلید GUID. اول کلید را صادر کنید، GUIDهایی را که برمی‌دارید ثبت کنید، فقط مقادیری را که به کلاینت رفته تعلق دارند حذف کنید، سپس راه‌اندازی مجدد کنید تا موتور وضعیتش را بازسازی کند. کل کلید را حذف نکنید و Base Filtering Engine را غیرفعال نکنید: دیوار آتش Windows و Defender به آن وابسته‌اند و یک قطعی را با قطعی بدتری معاوضه می‌کردید.

reg export "HKLM\SYSTEM\CurrentControlSet\Services\BFE\Parameters\Policy\Persistent" C:\temp\bfe-backup.reg

در Linux خطی را که iptables -S چاپ می‌کند بردارید و -A را با -D جایگزین کنید. حذف همان یک قاعده‌ای که شناسایی کردید بهتر از خالی کردن یک زنجیره است، چون خط‌مشی خودتان را دست‌نخورده می‌گذارد.

sudo iptables -D OUTPUT -p udp -j REJECT

اگر drop در زنجیره‌ای تعریف‌شده توسط کاربر باشد، اول پرش به آن زنجیره را حذف کنید و سپس زنجیره را با -X بردارید. تنظیم خط‌مشی زنجیره روی ACCEPT در حالی که قواعد drop هنوز حاضرند فقط به بسته‌هایی کمک می‌کند که اصلاً به تصمیم خط‌مشی می‌رسند. خالی کردن همه جدول‌ها آخرین راه است: قواعدی را هم که به دلایل دیگر افزوده‌اید برمی‌دارد، و با روشن بودن ufw سرویس را به این باور می‌گذارد که مالک زنجیره‌هایی است که دیگر وجود ندارند.

صاحب آن را که دوباره برش می‌گرداند پیدا کنید

پس از تعمیر فوری، هر چیزی را که می‌تواند وضعیت را بازگرداند بجویید. در Linux بررسی کنید آیا یک واحد پایداری فعال است، آیا کلاینت تنظیمی برای بازیابی دیوار آتش هنگام ورود دارد و آیا فایل قواعد ذخیره‌شده‌ای زیر /etc وجود دارد. در Windows دوباره ورودی‌های آغاز به کار، سرویس‌ها و وظایف زمان‌بندی‌شده را بررسی کنید، سپس راه‌اندازی مجدد کنید و وضعیت را با همان دستورهای پیشین دوباره بخوانید.

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

با ترافیک واقعی بررسی کنید، نه با یک ping

یک جست‌وجوی نام، یک اتصال TCP و یک نشست تازه مرورگر را بیازمایید، سپس راه‌اندازی مجدد کنید و همان سه بررسی را تکرار کنید. pingی که کار می‌کند در حالی که HTTPS شکست می‌خورد به فیلتری در لایه انتقال اشاره دارد نه به شبکه، و مسدودسازی‌ای که فقط پس از راه‌اندازی مجدد بازمی‌گردد به صاحبی اشاره دارد که هنوز پیدا نکرده‌اید.

شواهد را نگه دارید: کلید BFE صادرشده، یا خروجی iptables -S که پیش از تغییر گرفته شده است. پیش از آنکه آن را درست‌شده بنامید، تأیید کنید شیء را از کدام لایه برداشتید، کدام صاحب می‌تواند دوباره نصبش کند، وضعیت پس از یک راه‌اندازی مجدد پاک، و اینکه مرور عادی بدون هیچ فرایند VPN در حال اجرا کار می‌کند. صفحه راهنمای iptables(8) نگارش دقیق حذف و خط‌مشی را دارد اگر پاک‌سازی را اسکریپت می‌کنید.