کلید قطع پیش از عبور هر ترافیکی سرور VPN را مسدود می‌کند
کدام مرحله را کلید قطع مسدود می‌کند: جست‌وجوی نقطه پایانی، مسیر بیرونی، مسیر بازگشت و استثناهای کهنهٔ همتا — با شمارنده‌ها به‌جای حدس.
کلیدهای قطع در جهتی شکست می‌خورند که مردم انتظار ندارند: آن‌ها برای مسدود کردن ترافیک وقتی تونل پایین است ساخته شده‌اند، و بسته‌هایی که تونل را می‌سازند خودشان ترافیک‌اند. کل باگ همین است. مجموعه‌قاعده‌ای که هر چیزی را که از تونل خارج نمی‌شود دور می‌ریزد، دست‌دادنی را هم که باید آن را بالا بیاورد دور می‌ریزد، پس کلاینت در حلقه دوباره تلاش می‌کند و خطا به مرحله‌ای نسبت داده می‌شود که اول بررسی می‌شود. پیش از گسترش دیوار آتش، بفهمید کدام‌یک از سه مرحله رد می‌شود: جست‌وجوی نام، بسته بیرونی به همتا، یا پاسخی که برمی‌گردد.
چگونه تونل و حمل‌ونقل خودش به یکدیگر وابسته‌اند
کلاینت VPN را به‌عنوان دو حالت شبکه که یک مسیر سوکت را شریک‌اند بخوانید. پیش از آنکه تونل وجود داشته باشد، کلاینت سوکتی روی آداپتور فیزیکی باز می‌کند و فریم‌های رمزنگاری‌شده را به نشانی و درگاهی همتا می‌فرستد. تنها پس از موفقیت آن تبادل است که دستگاه تونل را می‌سازد و مسیرها را نصب می‌کند. کلید قطع سیاستی درباره حالت دوم است که چنان گسترده نوشته شده که بر هر دو اعمال می‌شود.
قواعد مبتنی بر رابط شکل معمول‌اند: آنچه از tun0 یا wg0 خارج می‌شود را بپذیرید، بقیه مسیر خروج را دور بریزید. این صورت‌بندی نمی‌تواند اتصال خود کلاینت به سرور را استثنا کند، پس پیاده‌سازی درست آن استثنا را صریح اضافه می‌کند، و شما هم هنگام نوشتن قاعده‌ها با دست همین کار را می‌کنید. قاعده‌های هر برنامه در Windows و macOS بخشی از این را با تطبیق یک فرایند به‌جای رابط دور می‌زنند، اما فرایند باز هم باید پیش از وجود تونل خارج شود.
سه مرحله، به ترتیبی که رخ می‌دهند
مرحله اول تفکیک است. وقتی پروفایل به‌جای نشانی تحت‌اللفظی نام میزبان را نگه می‌دارد، کلاینت پیش از فرستادن هر چیزی به پاسخ DNS نیاز دارد. پروفایلی که DNS را به تفکیک‌کننده تونل می‌فرستد بن‌بستی می‌سازد: تفکیک‌کننده فقط از راه تونلی در دسترس است که جست‌وجو باید آن را ممکن کند. تفکیک بیرون از تونل، یا سنجاق کردن نقطه پایانی به یک نشانی، این ابهام را برمی‌دارد.
مرحله دوم بسته بیرونی است که باید نخست مسیریابی و سپس دیوار آتش را به همین ترتیب پشت سر بگذارد. wireguard-tools نیمه مسیریابی این کار را برای WireGuard انجام می‌دهد: بسته‌های خودش را علامت می‌زند و یک قاعده سیاستی می‌افزاید تا از مسیر پیش‌فرضی که تازه نصب کرده بگذرند؛ صفحه راهنمای wg-quick آن قاعده و جدولی را که به کار می‌برد توصیف می‌کند. این مسیریابی را دستی از نو بسازید، یا بگذارید ابزار دومی قاعده‌ها را بازنویسی کند، و بسته‌های علامت‌خورده می‌توانند به همان تونلی بازگردانده شوند که باید بسازند.
مرحله سوم مسیر بازگشت است. دست‌دادن بدون پاسخ مدرکی بر دور ریختن در خروج نیست؛ به همان اندازه با قاعده ورودی سرور یا دستگاه NAT که نگاشت را فراموش کرده سازگار است. پیش از دست زدن به کلاینت این‌ها را جدا کنید.
| What you see | Stage | Where to look |
|---|---|---|
| The client log repeats a resolve step and no packets appear on the wire | 1, name lookup | Resolver path while the tunnel is down |
| The send counter on the physical adapter stays flat | 2, routing | Peer route and policy rules |
| The send counter rises and a firewall drop counter rises | 2, firewall | Rule order, mark, and interface match |
| Packets leave and nothing comes back | 3, return path | Server input rules, NAT, listening port |
کلاینت‌ها نشانه‌ای را ثبت می‌کنند که تشخیص می‌دهند، نه مرحله‌ای را که شکست خورده، پس جدول معمولاً از گزارش سریع‌تر است.
شمارنده‌ها سریع‌تر از گزارش‌ها تصمیم می‌گیرند
در Linux، nft list ruleset یا iptables -vnL OUTPUT برای هر قاعده یک شمارنده بسته چاپ می‌کند. یک بار وصل شوید، بگذارید شکست بخورد، سپس شمارنده‌ها را دوباره بخوانید. قاعده‌ای که شمارنده‌اش تکان خورده قاعده‌ای است که دست‌دادن به آن خورده؛ اگر هیچ‌جا چیزی تکان نخورده، بسته هرگز به دیوار آتش نرسیده است. دیده‌ام مجموعه‌قاعده‌ای دست‌دادن خودش را دور ریخته و تنها شمارنده‌ها این را گفته‌اند.
برای جدا کردن هرگز به دیوار آتش نرسید از هرگز از میزبان خارج نشد، خود رابط را بپایید. ip -s link show dev wlan0 بسته‌های فرستاده‌شده را گزارش می‌کند، و tcpdump -ni wlan0 udp port 51820 فریم‌ها را نشان می‌دهد. اگر در حالی که کلاینت دوباره تلاش می‌کند صاف بماند، اشکال بالاتر از netfilter است: مسیر همتای گمشده، قاعده سیاستی که به دستگاهی اشاره می‌کند که هنوز نیست، یا خطای سوکتی که کلاینت می‌بلعد.
استثناها را با نشانی‌های مستندسازی مانند 203.0.113.10 بیازمایید، تا لغزشی نتواند میزبان دیگری را کاوش کند.
استثنای کهنهٔ نقطه پایانی مانند قطعی سرور خوانده می‌شود
گمراه‌کننده‌ترین نسخه پس از تغییر نشانی همتا پدیدار می‌شود: سرویس نشانی پویا آن را جابه‌جا کرده، میزبان بازسازی شده، یا نشانی خروجی شبکه شما متفاوت است. استثنا هنوز نشانی قدیمی را نام می‌برد، پس بسته‌های به‌سوی نشانی جدید به قاعده دور ریختن می‌خورند. همان پیکربندی دیروز کار می‌کرد، و به همین دلیل مردم با عیب‌یابی سرور شروع می‌کنند.
نام میزبان درون یک قاعده دیوار آتش شما را نجات نمی‌دهد. در nftables نام هنگام بارگذاری مجموعه‌قاعده تفکیک می‌شود، پس هر نشانی که در آن لحظه وجود داشته را میخکوب می‌کند و مانند یک نشانی تحت‌اللفظی کهنه می‌شود. راه‌حل پایدار این است که استثنا را هنگام تغییر نقطه پایانی به‌روز کنید و باریک نگه دارید: یک نشانی همتا، یک درگاه حمل‌ونقل. بازه‌ای که به‌اندازه کافی پهن باشد تا تغییر نشانی را تاب بیاورد، به‌اندازه کافی پهن است تا ترافیک بی‌ربط را هم بیرون بفرستد.
وقتی کلید قطع روی میزبان سرور اجرا می‌شود
همان وابستگی در سر دیگر هم هست و آنجا آسان‌تر از چشم می‌افتد. اگر ماشینی که سرور VPN شماست کلاینت رومیزی با کلید قطع یا نمایه دیوار آتشی کپی‌شده از لپ‌تاپ هم اجرا کند، قاعده‌های دور ریختنش بر سرویسی اعمال می‌شود که تونل‌ها را پایان می‌دهد. پاسخ‌ها به دست‌دادن کلاینت دور ریخته می‌شوند، پس هر کلاینت در اتصال شکست می‌خورد در حالی که سرور سالم به نظر می‌رسد و رابط تونلش بی‌استفاده می‌ماند.
آن میزبان پیش از دور ریختن به سه پذیرش باریک نیاز دارد: درگاه شنود روی رابط فیزیکی، رابط تونل برای ترافیک رمزگشایی‌شده، و ارسال از تونل به‌سوی آنچه کلاینت‌ها باید به آن برسند. مجموعه نصب‌شده را با nft list ruleset یا iptables -S یا pfctl -sr بخوانید، پیش از تغییر هر چیزی، و به یاد داشته باشید مجموعه‌قاعده‌ای که ذخیره شده از راه‌اندازی دوباره جان سالم به در می‌برد، پس خطایی آنجا از فرایندی که آن را ساخته بیشتر می‌ماند.
ترتیب بازیابی که ماشین را بسته نگه می‌دارد
از پروفایل به بیرون کار کنید. نشانی و درگاه همتایی را که کلاینت به کار می‌برد بخوانید، تأیید کنید که نام میزبان بدون تونل تفکیک می‌شود، سپس یک استثنا برای آن نشانی و درگاه فقط روی آداپتور فیزیکی اضافه کنید. دوباره وصل شوید و شمارنده ارسال را بپایید؛ دست‌دادن کامل همان نشانه‌ای است که مرحله دوم درست شده است.
بقیه سیاست دور ریختن را هنگام آزمون سر جایش بگذارید. بررسی بی‌خطر این است که اتصال به نشانی مستندسازی بی‌ربطی را بیازمایید و تأیید کنید که هنوز زمان‌اش تمام می‌شود، که نشان می‌دهد کلید قطع کار می‌کند نه اینکه خاموش شده. وقتی تونل پایدار شد استثنا را تنگ‌تر کنید، و برای برنامه کلاینت به‌خاطر راحتی یک اجازه دائمی همه‌چیز باقی نگذارید.
اگر تونل بالا بیاید و برنامه هنوز شکست بخورد، مرحله‌های باقی‌مانده این نیست: DNS تفکیک‌شده، MTU و مسیریابی هر برنامه هر یک تونلی متصل با ترافیک خراب می‌سازند، و هر یک نخستین بررسی متفاوتی دارد.