Wi-Fi مهمان همچنان از مسیر اصلی استفاده می‌کند: خروجی جداگانه به آن بدهید

شما یک شبکه مهمان ساخته‌اید، برای آن مسیر اضافه کرده‌اید، و مهمان‌ها هنوز از اتصال اینترنت معمولی شما خارج می‌شوند. تونل بالا است، LAN اصلی کار می‌کند و دستگاه‌های مهمان آدرسی در محدوده‌ای که تعیین کرده‌اید گزارش می‌دهند، پس هیچ چیز خراب به نظر نمی‌رسد. آنچه معمولاً کم است نه یک مسیر بلکه یک انتخابگر است: روتر قبل از اینکه در نظر بگیرد بسته از کدام رابط وارد شده مسیر را تعیین می‌کند، و تا زمانی که چیزی صریحاً با ترافیک مهمان مطابقت نکند، آن ترافیک پیش‌فرض را به ارث می‌برد. راه حل یک بخش، یک قاعده سیاستی و یک مسیر بازگشت است، به همین ترتیب.

نشانه: مهمان‌ها هنوز از WAN خارج می‌شوند

نشانه، آدرس خروجی است. دستگاه مهمانی که از طریق تونل به اینترنت می‌رسد آدرس ارائه‌دهنده تونل را گزارش می‌دهد، و دستگاهی که پیش‌فرض را به ارث برده آدرس اتصال معمولی شما را. یک دستگاه مهمان و یک دستگاه LAN اصلی را کنار هم مقایسه کنید، زیرا مورد جالب وقتی است که با آنچه پیکربندی کرده‌اید متفاوت باشند و با یکدیگر مطابق باشند.

نشانه دوم نبود هرگونه ترافیک روی رابط تونل در حالی است که مهمان‌ها مرور می‌کنند. اگر شمارنده‌ها حرکت نکنند، سیاست هرگز اعمال نشده است، و تنظیم خود تونل نمی‌تواند کمکی کند.

مرحله 1: یک بخش واقعی، نه فقط یک نام

نام SSID جداسازی ایجاد نمی‌کند. بررسی کنید که شبکه مهمان روی رابط، VLAN یا پل خودش تمام می‌شود و محدوده آدرس با LAN مطمئن متفاوت است. در بسیاری از نقاط دسترسی مصرفی، SSID مهمان به همان بخش بقیه چیزها پل می‌شود، که تا اصلاح آن، بقیه این کار را غیرممکن می‌کند.

سپس محدوده مهمان و سرور DHCP آن را تأیید کنید و تنظیمات مفسر نام را به همان بخش گره بزنید نه به کل روتر. زیرشبکه مهمانی که فقط به صورت یک توضیح در قاعده فایروال وجود دارد یک بخش نیست، و روتر هیچ رابطی برای مطابقت نخواهد داشت.

مهمان‌ها را برای آسان‌تر کردن پیکربندی VPN به LAN اصلی پل نکنید. این جداسازی مورد نظر شما را با یک میانبر مسیریابی عوض می‌کند، و همین دلیل معمول دسترسی شبکه مهمان به چاپگر و NAS است.

مرحله 2: تونل را بر اساس مبدأ انتخاب کنید

جدول‌های مسیریابی بر اساس مقصد انتخاب می‌شوند، بنابراین قاعده‌ای که می‌گوید «0.0.0.0/0 را به تونل بفرست» برای همه اعمال می‌شود. مسیریابی سیاستی بُعد دومی اضافه می‌کند: جدول را بر اساس آدرس مبدأ انتخاب کنید. روی روتر لینوکسی، این یک قاعده اضافی به همراه یک جدول اختصاصی است، و ترتیب مهم است زیرا اولین قاعده منطبق برنده می‌شود:

ip rule add from 192.168.60.0/24 lookup 100 priority 1000
ip route add default dev wg0 table 100
ip route get 1.1.1.1 from 192.168.60.10

آن دستور آخر مستقیماً به سؤال پاسخ می‌دهد: این مبدأ برای این مقصد از کدام رابط استفاده خواهد کرد. آن را قبل و بعد از تغییر اجرا کنید و بدون دست زدن به مرورگر خواهید دانست که آیا سیاست اثر کرده است.

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

مرحله 3: مسیر بازگشت و ترجمه

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

nft add rule ip nat POSTROUTING ip saddr 192.168.60.0/24 oifname "wg0" masquerade

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

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

جداسازی را آزمایش کنید، نه فقط مرور را

مرور ثابت می‌کند خروجی تغییر کرده است. ثابت نمی‌کند که بخش جدا شده است، و جداسازی دلیل وجود شبکه مهمان است. از یک دستگاه مهمان، سعی کنید به رابط مدیریت روتر، یک میزبان LAN مطمئن و سرویسی که باید رد شود برسید؛ هر سه باید شکست بخورند، و شکست باید یک تصمیم سیاستی باشد نه یک وقفه که هیچ‌کس نمی‌تواند توضیح دهد.

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

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

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