پیوند بی‌سیم به‌عنوان پشتیبان: انتقال مسیریابی‌شده یا یک سگمنت؟

دو ساختمان، یک بی‌سیم نقطه‌به‌نقطه و یک VPN اینترنتی که می‌تواند مسیر دوم باشد. پیش از آنکه پشتیبان خودکار شود، یک پرسش تقریباً همه چیز دیگر را تعیین می‌کند: چه چیزی باید زنده بماند — دسترسی IP میان زیرشبکه‌های جداگانه یا یک سگمنت اترنت مشترک؟ اینکه بی‌سیم مانند کابل رفتار می‌کند دلیلی برای فرستادن هر قاب پخش از طریق اینترنت نیست. نخست به پرسش پاسخ دهید، زیرا دو پاسخ کنترل حلقه متفاوت، بررسی‌های سلامت متفاوت و برداشت‌های متفاوتی از معنای بازیابی می‌طلبند.

تعیین کنید چه چیزی باید از قطعی جان سالم ببرد

برنامه‌هایی را که باید به کار ادامه دهند فهرست کنید و یادداشت کنید که به دسترسی در Layer 3 وابسته‌اند یا به هم‌جواری در Layer 2. اشتراک فایل، اتصال‌های پایگاه داده و سرویس‌های وب معمولاً فقط به مسیرها اهمیت می‌دهند؛ پروتکل‌های کشف، برخی محصولات خوشه‌ای و هر چیزی که یک دامنه پخش واحد انتظار دارد به هم‌جواری اهمیت می‌دهند. پشتیبانی که نوع نادرست دسترسی را بازیابی کند، سایتی می‌سازد که فنی متصل و عملاً بی‌فایده است.

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

انتقال مسیریابی‌شده: دو پیشوند، یک مسیر ترجیحی

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

ip route show | grep -E '10.44\.|10.45\.'
ip route get 10.45.0.10
ip route get 10.45.0.10 from 10.44.0.1

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

انتقال پل‌شده: یک سگمنت، یک مسیر مسدودکننده

اگر هم‌جواری واقعاً لازم باشد، پشتیبان باید قاب‌های اترنت را حمل کند، کاری که یک تونل IP مسیریابی‌شده انجام نمی‌دهد. برخی پلتفرم‌ها پل کردن یک رابط VPN در یک سگمنت محلی را پشتیبانی می‌کنند، و آن رابط‌ها سپس با پیامدهای همراه به اعضای پل تبدیل می‌شوند. دو مسیر Layer 2 که هم‌زمان ارسال می‌کنند یک حلقه می‌سازند، پس طراحی به یک درخت پوشا که هر دو سایت را در بر بگیرد و به بیانیه‌ای روشن در این باره که کدام مسیر باید مسدود شود نیاز دارد.

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

مرز مهم را پایش کنید

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

ping -c 3 -W 2 10.45.0.10
ip -brief link show dev wlan0
ip route get 10.45.0.10

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

هر دو جهت را زیر بار تمرین کنید

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

sudo ip link set dev wlan0 down
ip route get 10.45.0.10
sudo ip link set dev wlan0 up
ip route get 10.45.0.10

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