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

سه مسئولیت، یک مجموعه قاعده

مسئولیت اول کارکرد شبکهٔ بیرونی است: میزبان باید روی پیوند خود بماند، همسایه‌ها را حل کند و حدود مسیر آن پیوند را بیاموزد. دومی شنوندهٔ رمزگذاری‌شده است که UDP را روی نشانی و درگاهی که انتخاب کرده‌اید می‌پذیرد. سومی مجموعه سرویس‌های رمزگشایی‌شده‌ای است که می‌خواهید کاربران تونل به آن برسند.

این‌ها سه سیاست متفاوت‌اند و فقط دومی و سومی به VPN مربوط می‌شوند. مجموعه قاعده‌ای که آن‌ها را یکی می‌بیند حالتی از خرابی را به ارث می‌برد که در آن سخت‌تر کردن مرز برنامه بی‌صدا اتصال میزبان را می‌شکند.

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

ICMPv6 برای میزبان چه می‌کند

IPv6 برای بسیار بیشتر از پژواک به ICMPv6 تکیه می‌کند. درخواست و اعلام همسایه جای ARP را می‌گیرند و برای تحویل محلی لازم‌اند. Packet Too Big اطلاعات MTU مسیر را حمل می‌کند و نادیده گرفتن آن انتقال‌هایی می‌سازد که روی بسته‌های بزرگ متوقف می‌شوند. اعلام‌های مسیریاب مسیر پیش‌فرض و اطلاعات پیشوند را حمل می‌کنند وقتی پیوند از پیکربندی خودکار استفاده می‌کند.

RFC 4890 پیام‌هایی را که صافی میزبان باید مجاز کند از آن‌هایی که انتخابی اداری هستند جدا می‌کند و این کار را در بخش میزبان انجام می‌دهد که با قواعد مسیریابی که بین شبکه‌ها فرست می‌دهد تفاوت دارد. خواندن تنها بخش فرستادن سیاست ورودی‌ای می‌سازد که برای میزبانی که از آن محافظت می‌کند بیش از حد سخت‌گیرانه است.

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

جایگزین کردن همهٔ این‌ها با یک اجازهٔ عمومی ICMPv6 مشکل دسترس‌پذیری را حل می‌کند و از صافی‌گری می‌گذرد. جایگزین کردن آن با یک ریزش عمومی مشکل صافی‌گری را حل می‌کند و از میزبان می‌گذرد.

اول تونل را بپذیرید، سپس سرویس را

حمل‌ونقل WireGuard را روی نشانی بیرونی و درگاه UDP مورد نظر بپذیرید و ترافیک برگشتی را از طریق ردیابی اتصال بپذیرید. سپس سرویس‌های برنامه را از طریق رابط تونل و از منابعی که واقعاً مجاز می‌کنید اجازه دهید.

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

مجموعه قاعده را همان‌طور که هست بخوانید، نه آن‌طور که فایل توصیف می‌کند:

sudo nft list ruleset
ip -6 addr show
ip -6 route show default

شنونده روی نشانی فیزیکی مواجهه‌ای جدا از همان سرویس روی نشانی تونل است. اگر ماشین ترافیک را به ماشین دیگری هم فرست می‌دهد، آن تصمیم زنجیرهٔ فرستادن است نه این سیاست ورودی، و استدلال خودش را می‌خواهد.

پیوند را بیازمایید، نه فقط تونل را

تونل کارکننده پس از تغییر کمتر از آنچه به نظر می‌رسد را اثبات می‌کند، چون یک ورودی همسایهٔ موجود و یک اتصال برقرارشده می‌توانند پیام کنترلی را پنهان کنند که سیاست اکنون آن را می‌ریزد.

اتصال را مستقیم بررسی کنید و سپس بررسی کنید که مسیر کنارگذاشته هنوز شکست می‌خورد:

ip -6 neigh show
ping -6 -c 3 2001:db8:1::1
sudo nft -c -f /etc/nftables.conf

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

میزبانی را که خود را از آن قفل کرده‌اید بازیابید

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

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

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

مقالات مرتبط