آیا کلید قطع اضطراری VPN پس از راه‌اندازی مجدد باقی می‌ماند؟ چگونه بررسی کنید

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

راه‌اندازی مجدد سه پرسش جداگانه می‌پرسد

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

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

شیئی را بیابید که مسدودسازی را بازمی‌گرداند

در لینوکس قواعد netfilter در هسته زندگی می‌کنند. هیچ‌چیز هنگام بوت آنها را بازنویسی نمی‌کند مگر آنکه خودتان ترتیب داده باشید: iptables-save به‌علاوه netfilter-persistent، nftables.service بارگذاری می‌کند /etc/nftables.conf، یا یک واحد systemd که اسکریپت خودتان را اجرا می‌کند. بررسی کنید چه چیزی فعال است، نه آنچه به یاد دارید پیکربندی کرده‌اید.

systemctl is-enabled nftables netfilter-persistent 2>/dev/null
sudo nft list ruleset
sudo iptables -S OUTPUT

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

Get-Service | Where-Object { $_.Name -match 'vpn' } | Select-Object Name, Status, StartType
netsh wfp show state

فرمان دوم wfpstate.xml را در پوشه جاری می‌نویسد. فیلترهایی با کنش مسدودسازی را جست‌وجو کنید که پیش از اتصال کارخواه از قبل وجود دارند. Base Filtering Engine در آغاز بوت شروع می‌شود و فیلترهایی را که با نشانه پایدار افزوده شده‌اند بازمی‌گرداند، به همین دلیل برخی کلیدهای قطع اضطراری پیش از آنکه هر پنجره کارخواهی وجود داشته باشد ترافیک را مسدود می‌کنند و برخی نه. در مک‌اواس sudo pfctl -s info گزارش می‌دهد آیا pf فعال است، sudo pfctl -s rules نشان می‌دهد چه چیزی بارگذاری شده است، و کارخواه‌های VPN معمولاً قواعد خود را به یک لنگر می‌چسبانند نه به مجموعه قواعد اصلی. قاعده‌ای که utun3 را نام می‌برد می‌تواند پس از بوت بعدی به رابط دیگری اشاره کند، زیرا آن شماره در زمان اجرا تخصیص می‌یابد.

شکاف میان بالا آمدن شبکه و بالا آمدن تونل را بپایید

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

روی میزبان‌های systemd ترتیب را بخوانید نه اینکه حدس بزنید. اجرا کنید systemctl cat را روی واحدهای VPN و دیوار آتش و بگردید دنبال After= یا Before= در برابر network-pre.target و network-online.target. واحد دیوار آتشی که پس از network-online.target مرتب شده باشد به رابط می‌بازد؛ واحدی که network-pre.target آن را می‌خواهد و پیش از آن مرتب شده برنده می‌شود. در ویندوز پرسش‌های هم‌ارز نوع شروع سرویس و وابستگی‌های آن هستند، زیرا سرویسی که روی Manual تنظیم شده نمی‌تواند فرایند زمان بوت را مسدود کند. اگر نیاز شما ترافیک پیش از ورود را در بر می‌گیرد، تنها ترتیبی در سطح دستگاه آن را برمی‌آورد: تونل دستگاه Always On VPN با گواهی ماشین احراز هویت می‌کند و پیش از ورود کاربر متصل می‌شود، و مایکروسافت پیکربندی تونل دستگاه را مستند می‌کند جدا از تونل کاربر. اندروید راه دیگری می‌رود، VPN همیشه-روشن را تحمیل می‌کند و اتصال‌های بدون آن را از سیستم مسدود می‌کند نه از یک فرایند برنامه.

آزمایش را اجرا کنید، سپس دو خط زمانی را مقایسه کنید

با مقصدی که اگر نشت کند هیچ هزینه‌ای ندارد راه‌اندازی مجدد کنید، و وضعیت را در طول شکاف ثبت کنید نه پس از آن. پاک‌ترین روش یک کاوشگر زمان بوت است: یک واحد oneshot یا یک وظیفه زمان‌بندی‌شده که هرچه سکو اجازه دهد زودتر شروع می‌شود، مسیر پیش‌فرض و وضعیت دیوار آتش را ثبت می‌کند، یک درخواست با مهلت کوتاه می‌آزماید و خطی به یک پرونده محلی می‌افزاید. آن ثبت را با زمان شروع سرویس VPN از journalctl -b -u یا گزارش سیستم مقایسه کنید.

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

شکاف را ببندید بدون آنکه راه بازگشت خود را قطع کنید

اگر مسدودسازی هنگام بوت نیست، اعمال را یک لایه پایین‌تر ببرید نه اینکه قاعده دوم کارخواه را بیفزایید. مجموعه قواعد را ذخیره کنید و آن را از واحدی بارگذاری کنید که پیش از قابل استفاده شدن شبکه مرتب شده است، و مطمئن شوید آن واحد به یک جست‌وجوی DNS یا یک سوارکردن شبکه که قرار است از آن محافظت کند نیاز ندارد. دامنه به اندازه زمان‌بندی اهمیت دارد: قواعدی که با شناسه کاربر یا یک cgroup تطبیق می‌یابند هر سرویس سیستمی را بیرون از مسدودسازی می‌گذارند، و مجموعه قواعدی که تنها IPv4 را اداره می‌کند IPv6 و DNS را در دسترس می‌گذارد.

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

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