جلوی رسیدن کلاینت‌های VPN به یکدیگر روی تونل را بگیرید
رسیدن به یک سرویس مسیر است، رسیدن به کلاینت دیگر سیاست. نقطهٔ فورواردی را پیدا کنید که ترافیک همتاها را تعیین می‌کند، سپس منع را از یک کلاینت اثبات کنید.
دو کلاینت می‌توانند هر دو میزبان پرش را باز کنند و باز هم کاری برای باز کردن یکدیگر نداشته باشند. رسیدن به یک سرویس تصمیم فوروارد است، در حالی که رسیدن به یک همتا تصمیم سیاست است، و بیشتر پشته‌های VPN این دو را در اشیای جداگانه نگه می‌دارند. هیچ چیز از آنچه برای اولی تنظیم می‌کنید دومی را اعمال نمی‌کند. پس کار نه افزودن یک قاعده است، بلکه یافتن شیئی که ترافیک همتاها را روی این سرور تعیین می‌کند، نوشتن منع در آنجا و اثبات آن از یک کلاینت.
مسیر به سرویس مشترک مجوزی بین همتاها نیست
اعلام زیرشبکهٔ کلاینت‌ها به همتا می‌گوید چگونه بسته را روی سیم به سوی نشانی کلاینت دیگر بگذارد. اینکه آن بسته تحویل شود بعداً روشن می‌شود، توسط آنچه آن را فوروارد می‌کند. روی دروازهٔ Linux این زنجیرهٔ FORWARD است؛ درون دیمنی در فضای کاربر این جدول جلسات خود تونل است. مسیر به دسترس‌پذیری پاسخ می‌دهد و مجوز را دست‌نخورده می‌گذارد.
به همین دلیل بررسی جداسازی که فقط مسیرها را می‌خواند چیزی را اثبات نمی‌کند. می‌توان /24 را به هر کلاینت فرستاد، در حالی که هر بستهٔ همتا-به-همتا در قلاب فوروارد انداخته می‌شود. حالت خطرناک برعکس است: هیچ قاعدهٔ صریحی نیست، پیش‌فرضی سهل‌گیرانه است، و جداسازی فقط به این دلیل وجود دارد که کسی آن را آزمایش نکرده است.
الزام را پیش از باز کردن پایانه در یک خط بنویسید. به بلوک سرویس و میزبان پرش برسید، درون بلوک کلاینت‌ها به هیچ چیز دیگری نرسید.
بفهمید چه کسی واقعاً بستهٔ همتا را فوروارد می‌کند
دو رفتار سرور از سمت کلاینت یکسان به نظر می‌رسند و به قواعد متفاوتی نیاز دارند. یا هسته بسته را دوباره از رابط تونل به بیرون فوروارد می‌کند، یا دیمن آن را بین جلسات کپی می‌کند و هسته هرگز آن را نمی‌بیند.
WireGuard در گروه نخست است: کلیدی بین همتاها ندارد، پس بسته از 10.8.0.4 به 10.8.0.5 روی wg0 می‌رسد، به قلاب فوروارد می‌خورد و وقتی AllowedIPs هر دو نشانی را می‌پوشاند دوباره از wg0 مسیریابی می‌شود. OpenVPN گروه دوم است وقتی client-to-client در پیکربندی سرور تنظیم شود، چون آن دستور بسته را در فضای کاربر بین جلسات تحویل می‌دهد. پیش از نوشتن هر چیز، پیکربندی بارگذاری‌شده را برای آن دستور بررسی کنید. قاعدهٔ هسته‌ای که هرگز ترافیک نمی‌بیند از قاعده‌ای که کار می‌کند قابل تشخیص نیست، و دقیقاً این‌گونه استقرار بدون هیچ جداسازی به پایان می‌رسد.
پیکربندی مؤثر را بخوانید نه فایلی را که گمان می‌کنید بارگذاری شده است، چون بسته‌های توزیع دربرگیری‌های خود را می‌آورند. اگر دیمن فوروارد می‌کند، منع جای خود را در کنترل‌های هر-کلاینت خودش دارد، و فایروال میزبان فقط ترافیک ارسال‌شده به میزبان را فیلتر می‌کند. اگر هسته فوروارد می‌کند، قلاب فوروارد تنها جای مهم است.
استقرارهای مسیریابی‌شده و ترجمه‌شده یک بررسی دیگر لازم دارند: ممکن است منبعی که کلاینت دور می‌بیند همان نباشد که انتظار دارید. آنگاه قاعده‌ای که با زیرشبکهٔ کلاینت‌ها می‌خواند با هیچ چیز نمی‌خواند. پیش از نوشتن تطبیق، نشانی‌ای را که از ترجمه جان سالم می‌برد یادداشت کنید و تطبیق جفت رابط را به حدس زدن نشانی‌های NAT ترجیح دهید.
به هر نشانی هویتی بدهید که خودش به‌تنهایی قابل ابطال باشد
جداسازی به‌محض اینکه دو دستگاه یک اعتبارنامه را شریک شوند فرو می‌ریزد. قاعده‌ای که به آن هویت گره خورده نمی‌تواند آنها را جدا کند، و ابطال یک لپ‌تاپ گمشده کل گروه را ابطال می‌کند. گواهی‌های هر-دستگاه یا کلیدهای هر-همتا ابطال را محلی و سیاست را خوانا نگه می‌دارند، چون هر نشانی دقیقاً به یک شخص یا ماشین نگاشت می‌شود. جایی که طرح نمی‌تواند این کار را بکند، در دفترچهٔ عملیات بگویید، نه اینکه قاعده را ریزدانه توصیف کنید.
تخصیص نشانی باید با سیاست هم‌خوان باشد. یک بلوک برای سرویس‌ها و یک بلوک برای کلاینت‌ها رزرو کنید و نشانی‌های کلاینت را از استخری که در اختیار دارید بدهید نه از بازه‌ای به ترتیب ورود. اگر سرور ترجمه یا پل می‌زند، جدول نگاشت را کنار پیکربندی نگه دارید، چون همان جدول چیزی است که خوانندهٔ بعدی برای بازاستخراج قاعده لازم دارد.
منع را جایی بگذارید که بسته از تونل می‌گذرد
روی دروازه‌ای که ترافیک WireGuard را فوروارد می‌کند، دو قاعده این حالت را می‌پوشانند: بلوک سرویس را مجاز کنید، سپس بقیهٔ بلوک کلاینت را بیندازید. جفت رابط به‌اندازهٔ نشانی‌ها مهم است، چون تطبیق فقط روی مقصد ترافیک آمده از LAN را هم می‌گیرد. آنها را به همین ترتیب بارگذاری کنید تا مجوز نخست ارزیابی شود.
با nftables این جفت به جدول موجود inet filter می‌رود، نخست مجوز و سپس انداختن. هر دو تطبیق جفت رابط و نیز نشانی‌ها را سنجاق می‌کنند.
nft add rule inet filter forward iifname "wg0" oifname "wg0" ip saddr 10.8.0.0/24 ip daddr 10.8.2.0/24 accept
nft add rule inet filter forward iifname "wg0" oifname "wg0" ip saddr 10.8.0.0/24 ip daddr 10.8.0.0/24 dropپس از بارگذاری زنجیره را دوباره بخوانید نه اینکه به وضعیت خروج اعتماد کنید، و تأیید کنید که هر دو قاعده در ترتیبی که می‌خواستید قرار دارند. قواعد ip6 مطابق برای استخر IPv6 بیفزایید، وگرنه جفت v4 روی تونل دوپشته فقط تزیین است. اگر سرور از قبل سیاست فوروارد سهل‌گیرانه دارد، انداختن را بیفزایید نه اینکه کل زنجیره را جایگزین کنید.
وقتی client-to-client روی OpenVPN فعال است، این قواعد فوروارد هرگز با ترافیک همتاها نمی‌خوانند و منع باید در کنترل‌های خود دیمن زندگی کند. قواعد هسته را برای ترافیک ارسال‌شده به میزبان نگه دارید، اما آنها را کنترل جداسازی نشمارید.
منع را از یک کلاینت اثبات کنید، نه از سرور
آزمایش از دروازه چیزی را اثبات نمی‌کند، چون ترافیک تولیدشدهٔ محلی مسیر خروج را می‌گیرد و هرگز از قلاب فوروارد نمی‌گذرد. از دو کلاینت واقعی استفاده کنید: یکی که باید به سرویس برسد و یکی که باید رد شود. نخست حالت مجاز را اجرا کنید تا تونل خراب با سیاست کارکننده اشتباه گرفته نشود.
از کلاینت مجاز تأیید کنید که سرویس روی درگاه خود پاسخ می‌دهد. از همان کلاینت نشانی همتا را آزمایش کنید و انتظار انداختن بی‌صدا داشته باشید نه رد کردن:
ping -c 3 -W 2 10.8.0.5
nc -z -w 2 10.8.0.5 22
nft list chain inet filter forward
iptables -vnL FORWARD
ping -6 -c 3 -W 2 fd00:8::5بستهٔ انداخته‌شده و همتای آفلاین هر دو مانند اتمام زمان به نظر می‌رسند، پس پیش از هر نتیجه‌گیری شمارنده‌ها را بررسی کنید. تأیید کنید که شمارندهٔ قاعدهٔ انداختن بالا می‌رود در حالی که همتا آشکارا بالاست. روی IPv6 تکرار کنید، جایی که نبود قاعدهٔ ip6 منع v4 را کارآمد نشان می‌دهد. نتایج پذیرفته‌شده و ردشده را با تاریخ در دفترچهٔ عملیات ثبت کنید، چون مهاجرت بعدی قاعده را دوباره استخراج خواهد کرد.