مسیریابی یک زیرشبکه شعبه از خروجی اینترنت SonicWall ستاد مرکزی
یک گروه مبدأ شعبه انتخاب کنید، آن را در سیاست تونل بپذیرید، در WAN مرکزی ترجمه کنید و سپس سه کلاینت را آزمایش کنید. مسیر بهتنهایی دروازه ایجاد نمیکند.
تلفنهای شعبه باید از ستاد مرکزی خارج شوند در حالی که لپتاپهای شعبه همچنان از WAN محلی استفاده میکنند، و سیاست مسیریابی بهتنهایی این را فراهم نمیکند. مسیر شعبه میتواند تونل را انتخاب کند، اما سیاست تونل باید ترافیک را بپذیرد، ستاد مرکزی باید آن را ارسال و ترجمه کند، و پاسخ باید از همان مسیر بازگردد. اگر هر یک از این سه را جا بیندازید، نشانه آن زیرمجموعهای از کلاینتها خواهد بود که دقیقاً وقتی تونل برپاست اینترنت را از دست میدهند.
با انتخابگر شروع کنید، نه با مسیر
سیاست مسیریابی بر اساس مبدأ تطبیق میکند، پس مبدأ باید پیش از هر چیز پایدار باشد. دستگاههای انتخابشده را در یک گروه آدرس که مدیر آن را نگهداری میکند قرار دهید، یا بهتر، در یک بخش اختصاصی که عضویت آن از نقش دستگاه پیروی میکند. وقتی چرخش معمول DHCP میتواند یک آدرس منطبق را به ماشین دیگری منتقل کند، سیاست بیصدا کلاینت اشتباه را انتخاب میکند، و نخستین گزارش معمولاً درباره مرور کند است که در واقع یک دور زدن است.
گروه را به نام سیاستی که به آن خدمت میکند نامگذاری کنید، نه به نام یک طبقه یا بخش، زیرا قاعده مسیریابی از هر دو بیشتر عمر میکند. ثبت کنید کدام دستگاهها در آن هستند و چه کسی اجازه افزودن یکی را دارد.
سیاست شعبه را اضافه کنید، سپس از ترتیب آن دفاع کنید
در SonicWall شعبه، یک سیاست مسیر گروه مبدأ را انتخاب میکند، مقصدهای موردنظر را نام میبرد و رابط تونل را بهعنوان دروازه تنظیم میکند، و طراحی پشتیبانیشده رابط تونل دقیقاً برای همین است. قواعد مقصدهای محلی و خصوصی را بالای قاعده گسترده اینترنت نگه دارید، زیرا نخستین تطابق برنده است و یک پیشوند خصوصی که به تونل رانده شود فقط برای دور انداخته شدن به ستاد مرکزی میرسد. مسیر خود فایروال به همتای VPN آن را نیز حفظ کنید، وگرنه انتقال تونل از سیاستی که به آن وابسته است پیروی خواهد کرد. هیچیک از اینها شما را مجبور نمیکند هر تونل مبتنی بر سیاست موجود را تغییر دهید؛ رابط تونل یکی از چند گزینه پشتیبانیشده است.
ترتیب همان بخشی است که تصادفی تغییر میکند. هر کسی که استثنایی اضافه میکند باید آن را بالای قاعده گسترده درج کند، و هر کسی که قاعده گسترده را ویرایش میکند میتواند کل طراحی را با یک ذخیرهسازی وارونه کند. ترتیب موردنظر را کنار سیاست بنویسید و پس از بهروزرسانیهای میانافزار دوباره بررسی کنید، زیرا نامگذاری رابطها و نمایش سیاستها میان نسخهها واقعاً جابهجا میشوند.
مسیر را در ستاد مرکزی کامل کنید
سیاست تونل در ستاد مرکزی باید ترافیکی را بپذیرد که مسیر شعبه اکنون انتخاب میکند. یک انتخابگر بیندفتری که به LAN خصوصی ستاد مرکزی محدود شده است، مجوز حمل مقصدهای عمومی دلخواه نیست، بنابراین سیاست به مبدأ شعبه و محدوده مقصدی که واقعاً منظورتان است نیاز دارد. سپس ستاد مرکزی آن ترافیک ورودی را طبق قواعد دسترسی خود به لینک اینترنتش ارسال میکند، و نمونه خروجی مرکزی SonicWall ترجمه مبدأ برای شبکه دور را در WAN مرکزی شامل میشود. بدون آن ترجمه، طرف دور یک آدرس خصوصی شعبه میبیند و مسیری برای بازگشت به آن ندارد.
پاسخها نیمه دیگر قرارداد هستند. آنها باید از طریق تونل یا از طریق ترجمه حالتمندی که برایشان ایجاد شده بازگردند، و ترافیک سایتهای خصوصی ممکن است به رفتار NAT متفاوتی از خروجی عمومی نیاز داشته باشد. آن قواعد را قابل تشخیص نگه دارید، زیرا یک قاعده ترجمه گسترده که هر مبدأ داخلی را پنهان میکند، ثبت وقایع و عیبیابی بعدی را بسیار دشوارتر میکند.
تصمیم بگیرید گروه هنگام افتادن تونل چه میکند
اگر خروجی مرکزی یک الزام باشد نه یک ترجیح، بازگشت به WAN محلی یک نقض انطباق است حتی اگر کاربران آنلاین بمانند. SonicOS مسیر رهاکردن رابط تونل را بهعنوان روش پشتیبانیشده برای جلوگیری از گرفتن یک مسیر جایگزین ناخواسته توسط ترافیک انتخابی مستند میکند.
دامنه و اولویت آن مسیر را با نسخه نصبشده تطبیق دهید، و آن را با پایین آوردن تونل آزمایش کنید نه با اعتماد به برچسب. گروهی که هرگز نباید بهصورت محلی خارج شود باید بسته شکست بخورد، در حالی که گروهی که دسترسپذیری در آن مهمتر است میتواند بهطور مشروع بازگردد؛ هر دو تصمیم هستند و هیچیک نباید بهطور پیشفرض رخ دهد.
از سه کلاینت بررسی کنید، سپس تمیز عقبگرد کنید
پینگ به دروازه مرکزی چیز اشتباهی را آزمایش میکند، زیرا از فایروال نشأت میگیرد نه از یک کلاینت انتخابشده. بهجای آن از دستگاهها آزمایش کنید، و سه مورد از آنها را آزمایش کنید: یک دستگاه انتخابشده، یک دستگاه عادی که باید محلی بماند، و یکی که به سرویسهای محلی وابسته است.
ip -4 route get 203.0.113.10
curl -sS -m 5 -o /dev/null -w "%{http_code}\n" https://example.com
traceroute -n -m 6 203.0.113.10
مقایسه کنید درخواست عمومی واقعاً کجا ظاهر شد. کلاینت انتخابشده باید از طریق خروجی ستاد مرکزی به اینترنت برسد، و کلاینت عادی باید همچنان آدرس خود شعبه را در طرف دور نشان دهد؛ 203.0.113.10 یک آدرس مستندسازی است که بهعنوان جایگزین مقصد موردنظر شما استفاده میشود. DNS را در همان مرحله بگنجانید، زیرا کلاینتی که از حلکننده شعبه میپرسد میتواند جستوجویی با منشأ روتر و مبدأ متفاوت و در نتیجه مسیر متفاوت تولید کند.
عقبگرد همان ترتیب ذخیرهشده سیاستها بههمراه گروه آدرس است. ترتیب قبلی را بازگردانید، گروه را از سیاست حذف کنید و هر دو کلاس دستگاه را دوباره آزمایش کنید. پیکربندی صادرشده را همراه با سابقه تغییر نگه دارید، زیرا مهندس بعدی باید بداند کدام قاعده گسترده بود پیش از آنکه کسی آن را ویرایش کند.