قواعد هدایت پورت فراگیر می‌تواند شنوندهٔ WireGuard شما را ببلعد
یک قاعدهٔ هدایت گسترده می‌تواند شنونده‌های WireGuard و SSH خود دروازه را ببلعد. قواعد باریک یا نشانی عمومی جداگانه برگزینید، سپس مسیر کنترل را بیازمایید.
یک دروازهٔ عمومی از پیش WireGuard را روی UDP 51820، SSH را روی 22 و یک برنامه را که باید از اینترنت در دسترس باشد اجرا می‌کند. قاعدهٔ وسوسه‌انگیز هر پورت را به peer هدایت می‌کند و کار را تمام‌شده می‌داند. روی یک دروازهٔ WireGuard آن قاعده می‌تواند ترابری خود تونل را بگیرد و شما را از ماشینی که آن را پایان می‌دهد بیرون ببندد. انتشار یک تصمیم مسیریابی با استثنای صفحهٔ کنترل است، نه یک خط DNAT.
ورود عمومی یا ورود تونلی: یکی را برگزینید
انتشار یک سرویس نقطهٔ ورود تازه‌ای به اینترنت می‌سازد. این با دادن عضویت VPN به یک peer یکی نیست، زیرا بازدیدکننده هرگز به تونل نمی‌پیوندد و دروازه چهرهٔ عمومی backend می‌شود. همین تمایز مخاطب قاعده و گواهی آن را تعیین می‌کند.
رابط‌های مدیریتی به‌ندرت به آن جایگاه تعلق دارند. صفحهٔ مدیریتی که مشتریان مجاز VPN به آن می‌رسند سطح حمله را درون تونل نگه می‌دارد و از قرار دادن فرم ورود در برابر پیمایش خودسرانه پرهیز می‌کند. نقاط پایانی عمومی برنامه هنوز به گواهی TLS خود، احراز هویت و محدودسازی نرخ نیاز دارند؛ جهش رمزگذاری‌شدهٔ WireGuard پای بازدیدکننده تا دروازه را محافظت نمی‌کند.
اگر سرویس واقعاً باید عمومی باشد، نام میزبان، گواهی‌ای که آن را پوشش می‌دهد و بازه‌های بازدیدکنندگانی که باید به آن برسند را بنویسید. همان سه واقعیت بعداً شکل قاعده و سیاست پالایش را تعیین می‌کنند. هر چیزی بیرون از آن‌ها گسترش دامنه روی یک شنوندهٔ عمومی است.
یک پورت به درون، یک backend به بیرون
از یک پورت عمومی و یک سرویس backend استفاده کنید. در این نمونه eth0 نشانی عمومی 198.51.100.20 را حمل می‌کند، نشانی تونل دروازه 10.200.0.1 است و peer برنامه را روی 10.200.0.7 اجرا می‌کند. TCP عمومی 9443 به TCP 8443 در peer نگاشت می‌شود:
iptables -t nat -A PREROUTING -i eth0 -d 198.51.100.20 -p tcp --dport 9443 -j DNAT --to-destination 10.200.0.7:8443
iptables -t nat -A POSTROUTING -o wg0 -d 10.200.0.7 -p tcp --dport 8443 -m conntrack --ctorigdst 198.51.100.20 --ctorigdstport 9443 -j SNAT --to-source 10.200.0.1قاعدهٔ SNAT با backend ترجمه‌شده و مقصد عمومی اصلی منطبق می‌شود، بنابراین اتصال دیگری به همان سرویس backend بیرون از این نگاشت می‌ماند. همچنین نشانی بازدیدکننده را از peer پنهان می‌کند، و این همان بده‌بستانی است که بازگشت مسیریابی‌شدهٔ حافظ منبع را طراحی جداگانه می‌کند. مرجع افزونه‌های iptables هر دو هدف و گزینه‌های انطباقشان را مستند می‌کند.
هدایت هنوز باید فعال شود و زنجیرهٔ پالایش به اجازه‌ای برای مقصد و پورت ترجمه‌شده به‌همراه پاسخ‌های برقرارشده نیاز دارد. زنجیرهٔ FORWARD مقصد ترجمه‌شده را پس از DNAT می‌بیند، پس قاعده‌ای که برای نشانی عمومی نوشته شده با بستهٔ هدایت‌شده منطبق نمی‌شود. اجازه را برای چندتایی backend بنویسید، نه عمومی.
peer باید اتصال سرویس را از نشانی تونل دروازه بپذیرد و پاسخ را از راه تونل بازگرداند. AllowedIPs آن باید منبعی را که واقعاً دریافت می‌کند مجاز کند، که زیر ترجمهٔ منبع همان نشانی تونل دروازه است، و ورودی گستردهٔ 0.0.0.0/0 روی هر peer برای این طراحی لازم نیست. چیزی که ترافیک بازگشت را می‌اندازد peerی است که فهرستش آن نشانی را جا می‌گذارد، یا طراحی حافظ منبع که به‌جای آن نشانی خود بازدیدکننده را هدایت می‌کند، پس منبعی را که peer واقعاً می‌بیند بررسی کنید، نه آن را که در قاعدهٔ شماست.
شنونده‌های خود دروازه را بیرون از قاعده نگه دارید
انطباق پورت را با قاعده‌ای که هر مقصد TCP و UDP را پوشش می‌دهد عوض کنید، و سوکت WireGuard خود دروازه درونش می‌افتد. ترجمهٔ مقصد پیش از آن رخ می‌دهد که ماشین تصمیم بگیرد بسته بومی است، پس UDP 51820 می‌تواند به peer برسد نه به فرایندی که هر اتصال peer را نگه می‌دارد. قاعده با موفقیت بار می‌شود و تونل می‌میرد، که خواندنش از سمت peer دشوار است.
SSH، عامل‌های پایش و هر سرویس دیگری که روی دروازه میزبانی می‌شود همین مواجهه را دارند. قاعده‌ای که همه چیز را هدایت می‌کند صفحهٔ کنترل را از برنامهٔ منتشرشده جدا نمی‌کند، و نخستین راه‌اندازی مجدد پس از تغییر همان لحظه‌ای است که قفل شدن آشکار می‌شود. قاعدهٔ فراگیر دربارهٔ سرویسی که بی‌صدا برمی‌دارد هشدار نمی‌دهد. آن را وقتی اتصال بعدی شکست بخورد کشف می‌کنید.
اگر هدایت گسترده واقعاً لازم است، پورت‌های کنترل را پیش از قاعدهٔ فراگیر رزرو کنید یا برای انتشار نشانی عمومی جداگانه به کار ببرید. گزینهٔ دوم پاکیزه‌تر است زیرا نشانی کنترل سیاست خود را نگه می‌دارد، اما ارائه‌دهنده باید آن نشانی را بدهد؛ افزودن یک رکورد DNS نشانی تخصیص نمی‌دهد.
هدایت گستردهٔ TCP و UDP هم همهٔ پروتکل‌ها نیست. ICMP، IPv6، بازخورد MTU مسیر و ترابری بیرونی VPN به سیاست خود نیاز دارند و قاعده‌ای که TCP و UDP را پوشش می‌دهد آن موارد را به زنجیرهٔ پیش‌فرض می‌سپارد.
پیش از نوشتن قاعده‌ها مدل را برگزینید
چهار شکل بیشتر انتشارهای دروازه را پوشش می‌دهد و انتخاب به شمار سرویس‌هایی که اجرا می‌کنید و میزان ریسک صفحهٔ کنترل که می‌توانید تحمل کنید بستگی دارد. جدول زیر آن‌ها را از باریک‌ترین تا گسترده‌ترین مرتب می‌کند.
| Model | What it protects | Cost | Use when |
|---|---|---|---|
| Narrow port forward | Every other listener, including the VPN | One rule per service | Few services, stable ports |
| Catch-all with reserved ports | Ports named in the exception list | Rule order becomes critical | Many services and disciplined review |
| Separate public address | Control address fully isolated | Provider must supply the address | High-value publication |
| VPN-only access | No public entry at all | Visitors need the tunnel | Admin interfaces and internal tools |
حتی اگر بعداً سرویس‌های بیشتری انتظار دارید با مدل باریک آغاز کنید. بازرسی آن آسان‌ترین است و تبدیل مجموعه‌ای از قاعده‌های باریک به قاعدهٔ فراگیر بازبینی‌شده ساده‌تر از کشف این است که کدام شنونده را قاعدهٔ گسترده گرفته است. هر مدلی که برگزینید، قاعده‌ها را نزد مالک دیوار آتش نگه دارید. اعمال خطوط iptables در کنار پیکربندی UFW یا nftables که همان زنجیره‌ها را هم مدیریت می‌کند سیاستی می‌سازد که بسته به ترتیب راه‌اندازی تغییر می‌کند.
هم انتشار و هم مسیر کنترل را اثبات کنید
از یک مشتری بیرونی مجاز با نام میزبان تأییدشده و گواهی معتبر برای آن بیازمایید. تأیید کنید کدام backend پاسخ داد، سپس بررسی کنید که پورت‌های عمومی نامرتبط همچنان رد می‌شوند. بررسی گواهی غیرفعال یک آزمون HTTPS موفق نیست، و اتصالی که به backend اشتباه می‌رسد از اتصال ناموفق بدتر است.
پس از آن خود دروازه را بررسی کنید: یک peer WireGuard وصل کنید، یک نشست SSH باز کنید و تأیید کنید که پایش همچنان گزارش می‌دهد. سرویس منتشرشده می‌تواند کار کند در حالی که صفحهٔ کنترل خراب است، پس هر دو بررسی به یک پنجرهٔ تغییر تعلق دارند. یک بار راه‌اندازی مجدد کنید تا اثبات شود قاعده‌ها به ترتیب انتظار دوباره اعمال می‌شوند، سپس انتشار را بردارید و تأیید کنید که برداشتن واقعاً با افزودن می‌خواند. مجموعهٔ بزرگی از افزودن‌های راه‌اندازی با برداشتن ناقص همان روشی است که یک آزمون موقت به یک بازشدن دائمی بدل می‌شود.