اتصال‌های جدید روی خروجی VPN جدید، جریان‌های قدیمی دست‌نخورده می‌مانند
زهکشی برنامه‌ریزی‌شده فقط جریان‌های طبقه‌بندی‌نشده را جابه‌جا می‌کند. آن را با تعویض مسیر مقایسه کنید و نشانه‌ها، جدول‌ها و وضعیت conntrack را ببینید که آن را نگه می‌دارند.
دو خروجی سالم VPN، یک بارگذاری طولانی که از قبل در حال اجراست، و الزامی که اتصال بعدی از تونل دیگر استفاده کند. دو راه برای برآورده کردن این وجود دارد و تنها یکی از آن‌ها روی یک دروازه فعال ایمن است. تعویض مسیر پیش‌فرض هر بسته را جابه‌جا می‌کند، از جمله بسته‌هایی که به بارگذاری تعلق دارند. زهکشی برنامه‌ریزی‌شده انتخاب اتصال‌های جدید را تغییر می‌دهد و جریان‌های ردیابی‌شده را روی مسیری که از آن شروع کرده‌اند نگه می‌دارد.
دو راه برای تعویض یک خروجی
تعویض مسیر یک فرمان است و در چند ثانیه برگشت‌پذیر است، به همین دلیل در هنگام رخدادها استفاده می‌شود. همچنین بی‌ملاحظه است: بسته‌های بارگذاری موجود ناگهان از تونل دیگری خارج می‌شوند، با نشانی مبدأ عمومی متفاوت و وضعیت ترجمه جداگانه.
اگر سمت دور جریان‌ها را بر اساس نشانی مبدأ ردیابی کند، ممکن است بارگذاری به‌سادگی دیگر شناخته نشود. زهکشی با گرفتن تصمیم یک‌باره برای هر اتصال و ذخیره آن از این امر جلوگیری می‌کند، بنابراین بارگذاری قدیمی تا پایان کار خروجی خود را حفظ می‌کند. تمام ارزش این تمرین همین است: سمت دور هیچ تغییری نمی‌بیند که مجبور باشد تفسیرش کند. به دریافت بسته‌هایی ادامه می‌دهد که با اتصالی که از قبل می‌شناسد مطابقت دارند.
هزینه، پیچیدگی است: دو جدول مسیریابی، یک طبقه‌بند که در قلاب درست اجرا می‌شود، و نشانه‌هایی که باید با هر چیز دیگری روی دستگاه که از آن‌ها استفاده می‌کند هماهنگ شوند.
به هر خروجی جدول خودش را بدهید
برای هر خروجی یک جدول مسیریابی و مقادیر نشانه یا بیت‌های متمایز برای دو انتخاب رزرو کنید. هر جدول به مسیرهای مناسب نقش خود نیاز دارد، نه فقط یک نام، و به یک نتیجه شکست عمدی برای حالت مفقود نیاز دارد. جدولی خالی که بی‌صدا به جدول اصلی می‌افتد — این‌گونه ترافیک از خروجی‌ای بیرون می‌رود که هیچ‌کس انتخابش نکرده است.
ip rule add fwmark 0x10/0x10 table 101
ip rule add fwmark 0x20/0x20 table 102
ip route add default via 192.0.2.1 dev wg-a table 101
ip route add default via 198.51.100.1 dev wg-b table 102یک مسیر blackhole در پایان هر جدول اضافه کنید تا جست‌وجویی که تطابقی نمی‌یابد با صدای بلند شکست بخورد، نه اینکه به پیش‌فرضی که انتخاب نکرده‌اید بگریزد.
یک‌بار انتخاب کنید، در نخستین بسته
پس از وجود ردیابی اتصال و پیش از جست‌وجوی مسیری که اهمیت دارد طبقه‌بندی کنید. برای یک اتصال LAN جدید و طبقه‌بندی‌نشده، خروجی را انتخاب کنید و آن را در وضعیت اتصال ذخیره کنید. در بسته‌های بعدی، مقدار ذخیره‌شده را به نشانه بسته‌ای که مسیریابی سیاستی می‌خواند بازگردانید.
نکته ظریف این است که جدید چه معنایی دارد. conntrack هنوز می‌تواند برای بسته‌های اولیه و بازفرست‌ها پیش از دیدن پاسخ NEW گزارش کند، بنابراین طبقه‌بندی که تنها بر آن وضعیت تکیه کند می‌تواند انتخابی را که قبلاً انجام داده بازنویسی کند. پیش از تخصیص، بررسی کنید که هیچ خروجی‌ای برای اتصال ذخیره نشده باشد.
nftables نشانه‌های بسته و اتصال را جدا نگه می‌دارد، و راهنمای فراداده کپی صریح میان آن‌ها را مستند می‌کند. نشانه اتصال خودبه‌خود به نشانه بسته‌ای که قاعده شما با آن مطابقت دارد تبدیل نمی‌شود، و این رایج‌ترین دلیل بی‌اثر بودن طبقه‌بندی است که با دقت نوشته شده است.
بازگردانی را به جهت و ترافیک موردنظر محدود کنید. اعمال نشانه خروجی اینترنت به بسته‌های بازگشتی می‌تواند پاسخ‌ها را به‌جای LAN به سمت خروجی بفرستد، و نشانه آن اتصالی یک‌طرفه است که شبیه مشکل دیوار آتش به نظر می‌رسد. پیش از دست زدن به قاعده دیوار آتش، مسیر پاسخ را بخوانید، زیرا بسته در حال مسیریابی است، فقط نه بازگشت به فرستنده.
چهار مرحله زهکشی
B را بدون دست زدن به A آماده کنید: مسیریابی، ارسال، مجوز، NAT و مسیر بازگشت. جدول و سیاست انتخابش را از طریق مالک پیکربندی موجود دروازه نصب کنید.
طبقه‌بند را تغییر دهید تا اتصال‌های جدید و طبقه‌بندی‌نشده B را انتخاب کنند، در حالی که انتخاب‌های ذخیره‌شده حفظ می‌شوند. یک تراکنش اتمی nftables از پنجره‌ای که در آن وضعیت قدیمی باید پاک شود جلوگیری می‌کند.
A را تا پایان جریان‌هایش روشن بگذارید. رابط، جدول، خروجی دور و نگاشت‌های NAT آن هنوز بخشی از آن جریان‌ها هستند، و ویرایش یک قاعده NAT پیوندهایی را که از قبل وجود دارند بازنمی‌سازد.
وقتی شرط زهکشی برآورده شد A را بازنشسته کنید، با داوری بر اساس وضعیت اتصال و رفتار برنامه نه یک بازه آرام.
آنچه زهکشی نمی‌تواند وعده دهد
درخواست مرورگر یک اتصال انتقال جدید نیست؛ تجمیع درخواست‌ها را روی اتصال قدیمی می‌فرستد. برعکس، یک جریان UDP می‌تواند از conntrack خارج شود و بسته‌ای بعدی از نو طبقه‌بندی شود. زهکشی از جریان‌های ردیابی‌شده پیروی می‌کند، نه از تصور برنامه از یک نشست.
اگر A پیش از پایان جریان‌هایش از کار بیفتد، نشانه ذخیره‌شده نجاتشان نمی‌دهد. از طریق B دوباره متصل می‌شوند، یا اصلاً متصل نمی‌شوند. زهکشی برنامه‌ریزی‌شده تا زمانی که مسیر اصلی سالم است تداوم می‌خرد؛ این تکرار وضعیت میان خروجی‌های مستقل نیست.
هر دو نیمه را بررسی کنید
پیش از تغییر یک اتصال مجاز طولانی‌مدت و پس از آن یک اتصال واقعاً تازه آغاز کنید. تأیید کنید هر کدام از کدام تونل استفاده می‌کند و سمت دور کدام نشانی مبدأ عمومی را می‌بیند، سپس بررسی کنید که ترافیک بازگشتی برمی‌گردد.
جدول conntrack را خالی نکنید تا انتخاب جدید ظاهر شود. این دقیقاً وضعیتی را از بین می‌برد که زهکشی باید حفظ کند، و یک مهاجرت کنترل‌شده را به یک قطعی با آزمونی تمیزنما تبدیل می‌کند.