چرا nftables نمی‌تواند ترافیک OpenVPN بین کلاینت‌ها را ببیند
ترافیک همتا داخل فرایند VPN تحویل داده می‌شود، بنابراین شمارنده‌های ارسال هرگز تکان نمی‌خورند. شمردن آن یعنی انتخاب میان مسیر هسته و مسیر فرایند.
دو کلاینت روی یک سرور فایل مبادله می‌کنند، انتقال موفق می‌شود، و هر قاعده ارسالی که به تونل نشانه بگیرد صفر بسته گزارش می‌دهد. قواعد خراب نیستند و زنجیره جای اشتباه نیست. وقتی ارسال میان همتاها فعال است، بسته داخل فرایند سرور تحویل داده می‌شود و پشته میزبان هرگز روتر نمی‌شود، پس دیوار آتش هسته چیزی برای شمردن ندارد. فهم این جدایی تعیین می‌کند که میانبر را نگه دارید یا مسیر را از راه هسته بازسازی کنید.
یک بسته را از میان سرور دنبال کنید
در یک تونل مسیریابی‌شده، دیمن بسته رمزگشایی‌شده هر کلاینت را به دستگاه تونل تحویل می‌دهد. از آنجا میزبان آن را مسیریابی می‌کند، قلاب ارسال اجرا می‌شود، و قاعده‌ای که با دستگاه تونل مطابقت دارد می‌تواند ترافیک را بشمارد یا بیندازد. این همان مسیری است که بیشتر نمونه‌های دیوار آتش فرض می‌کنند.
| Forwarding path | Who decides | What the host firewall sees |
|---|---|---|
| Kernel routing between clients | Host routing table and forward rules | Every inner packet, with interface names |
| Peer forwarding inside the server process | The VPN daemon's own peer table | Only the outer encrypted transport |
میانبر میزبان را از میان برمی‌دارد. بسته رمزگشایی‌شده یک نشست داخل دیمن به نشست دیگری داده می‌شود، و بسته درونی هرگز روی دستگاه تونل فرستاده نمی‌شود و میزبان آن را مسیریابی نمی‌کند. ترافیک کپسوله‌شده هنوز از رابط فیزیکی می‌گذرد، بنابراین یک ضبط بیرونی مشغول به نظر می‌رسد در حالی که قواعد درونی ساکت می‌مانند. ضبطی که روی دستگاه تونل گرفته شود اصلاً چیزی نشان نمی‌دهد، و این هر کسی را که انتظار دارد انتقال را همان‌جا ببیند شگفت‌زده می‌کند. این عدم‌تقارن سریع‌ترین راه شناخت میانبر از بیرون دیمن است.
آزمون شمارنده‌ای که تعیین می‌کند کدام مسیر اجرا شد
یک شمارنده به قاعده‌ای که باید اعمال شود وصل کنید، انتقالی میان دو کلاینت که آن قاعده باید مسدود کند اجرا کنید، و سپس شمارنده را بخوانید.
sudo nft list ruleset
sudo nft add rule inet filter forward iifname "tun0" oifname "tun0" counter accept
sudo nft list chain inet filter forwardاگر انتقال موفق شود و شمارنده صفر بماند، هسته هرگز آن بسته‌ها را مدیریت نکرده است، و هیچ ویرایش قاعده‌ای آن را تغییر نمی‌دهد. همان آزمون را در برابر سرویسی روی خود سرور تکرار کنید، چون آن جریان واقعاً از پشته میزبان می‌گذرد و شمارنده‌اش تکان می‌خورد. مقایسه دو نتیجه همان چیزی است که پاسخ را می‌دهد.
دو جزئیات از خوانش نادرست جلوگیری می‌کند. نام یک رابط که در برچسب زنجیره نوشته شود به‌خودی‌خود چیزی را فیلتر نمی‌کند، چون تطبیق روی فیلدهای رابط درون قواعد رخ می‌دهد. و طراحی پل‌شده لایه 2 باز هم رفتار دیگری دارد: آنجا کلاینت‌ها یک دامنه پخش را شریک‌اند، پس کشف همتا انتظار می‌رود و نه خطای مسیریابی.
سوئیچ فهرست دسترسی نیست
این همان بخشی است که یک بعدازظهر می‌گیرد. ارسال میان همتاها یک تنظیم روشن یا خاموش است، و تا وقتی روشن است دیمن تنها نقطه ارسال است. دیوار آتش میزبان نمی‌تواند بیان کند چه کسی به چه کسی دسترسی دارد، و فایل‌های به‌ازای هر کلاینت سوئیچ را به ماتریس سیاست تبدیل نمی‌کند.
اگر به قواعد به‌ازای هر همتا نیاز دارید، انتخاب میان دست کشیدن از میانبر و دست کشیدن از دیوار آتش میزبان به‌عنوان ابزار کنترل است. خاموش کردنش ارسال هسته را برمی‌گرداند، که به فعال بودن ارسال IP روی سرور و قواعد صریح برای جریان‌های مورد نظر نیاز دارد. روشن نگه داشتنش یعنی سیاست در پیکربندی دیمن زندگی می‌کند، که در عمل یعنی همه همتاها یا هیچ همتا.
فرایندهای سرور جداگانه با استخرهای آدرس و پورت‌های خودشان حد میانه عملی است. هر فرایند دقیقاً یک تصمیم دسترسی دارد، پس دو گروه می‌توانند بدون ماتریس سیاست قواعد متفاوت داشته باشند. میزبان می‌تواند وقتی چنین قصدی هست میان استخرها مسیریابی کند، و آنگاه دیوار آتش آن جریان‌ها را می‌بیند چون از میزبان می‌گذرند. هزینه پورت‌های اضافه، گواهی‌های اضافه و یک پروفایل برای هر گروه است.
انتخاب نقطه ارسال
وقتی دیوار آتش موتور سیاست است، وقتی به ثبت به‌ازای هر جریان نیاز دارید، یا وقتی حسابداری مهم است، ارسال هسته را انتخاب کنید. هزینه، گذردهی از پشته میزبان و قواعد بیشتر برای نگهداری است. مزیت این است که هر ابزار موجود، از شمارنده‌ها تا صادرکنندگان جریان، دوباره ترافیک را توصیف می‌کند. روی سرور کوچک این هزینه نامرئی است؛ روی رله شلوغ نه.
وقتی ترافیک همتاها یا کاملاً مجاز است یا کاملاً ممنوع و سرور برای آن اندازه‌گیری شده، ارسال درون فرایند را انتخاب کنید. هزینه این است که شمارنده‌ها، نظم‌های صف و ردیابی اتصال دیگر جریان‌های درونی را توصیف نمی‌کنند؛ این تنها وقتی پذیرفتنی است که بعداً کسی به آن‌ها تکیه نکند.
هر کدام را که انتخاب کنید، آن را کنار قواعد دیوار آتش بنویسید. مجموعه قواعدی که به نظر می‌رسد ترافیک همتاها را مجاز می‌کند در حالی که دیمن به هر حال تصمیم می‌گیرد، نفر بعدی را که انتقالی ناموفق را اشکال‌زدایی می‌کند گمراه می‌کند. هر کس فقط قواعد را بخواند گمان می‌کند هسته دروازه است.
پیش از تغییر قواعد چه چیزی را بررسی کنید
پیکربندی‌ای را بخوانید که سرور واقعاً بارگذاری کرده است، نه فایلی را که به یاد دارید ویرایش کرده‌اید، و تأیید کنید که گزینه همتا وجود دارد یا نه. اگر آن را تغییر داده‌اید، مطمئن شوید سرویس دوباره بارگذاری شده و نه فقط فایلی روی دیسک بازنویسی شده است.
سپس آزمون را با جریانی از کلاینت به سرور تکرار کنید تا ثابت شود قاعده اصلاً مطابقت دارد، و مسیرهای ارسال‌شده را بررسی کنید، چون مسیر گمشده از سمت کلاینت دقیقاً مانند مسدودسازی دیوار آتش به نظر می‌رسد. ترتیب قواعد را تنها پس از آن تغییر دهید که بدانید کدام نقطه ارسال مالک تصمیم است.