ورودی دوم VPN در WAN شکست می‌خورد در حالی که ورودی اصلی کار می‌کند

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

هر WAN به قرارداد ورودی خودش نیاز دارد

برای هر WAN پنج میدان ثبت کنید: نام و نشانی عمومی، انتقال و درگاه، واسط یا بستری که آن را پایان می‌دهد، هویت همتایی که باید ارائه دهد، و جایی که پاسخ از آن خارج می‌شود. دو مدار یعنی دو مجموعهٔ کامل. اگر مجموعهٔ دوم واسط پایانی یا مسیر بازگشت ندارد، ورودی پشتیبان ندارید؛ یک رکورد DNS دارید که قصدی را توصیف می‌کند.

دستگاه و نسخهٔ آن هم باید این ترتیب را پشتیبانی کنند. یک رکورد DNS نمی‌تواند سرویسی را روی واسط دیگر باز کند، و در بسیاری از سکوها شنونده به‌ازای نشانی و نه به‌ازای دستگاه پیکربندی می‌شود. IPsec مبتنی بر واسط در ASA نقشه‌های رمزنگاری و گروه‌های تونل را به واسط بیرونی گره می‌زند، پس اتصال بالاسوی دوم به سیاستی نیاز دارد که همان‌جا که این بسته‌ها واقعاً می‌رسند اعمال شود. طرح‌های مبتنی بر مسیر رفتار دیگری دارند: شنونده می‌تواند به همهٔ نشانی‌ها یا به یک نشانی نام‌دار گره بخورد، و همین انتخاب تعیین می‌کند که آیا ISP B اصلاً می‌تواند پاسخ دهد.

بررسی کنید که WAN دوم واقعاً پاسخ می‌دهد

از بیرون هر دو مدار آزمایش کنید، نه از ماشینی پشت درگاه، و همان نامی را آزمایش کنید که پروفایل کلاینت به کار می‌برد. برای شنوندهٔ TLS، بررسی سریع openssl s_client -connect ADDRESS:443 -servername vpn.example.com -showcerts است که از میزبان بیرون شبکهٔ شما اجرا می‌شود. شما دست‌دادن کامل‌شده‌ای می‌خواهید که زنجیره‌اش با نام در پروفایل بخواند، نه صرفاً درگاه TCP که اتصال می‌پذیرد.

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

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

پاسخ را دنبال کنید، نه فقط درخواست را

WAN دوم معمولاً در راه بازگشت می‌شکند. درخواست از ISP B می‌رسد، دستگاه پاسخ می‌دهد و پاسخ از مسیر پیش‌فرض روی ISP A با نشانی مبدأیی خارج می‌شود که کلاینت هرگز آن را نخواسته بود. ترجمهٔ حالت‌مند بدترش می‌کند: اگر نگاشت برای واسط اصلی ساخته شده باشد، بستهٔ بازگشتی ترجمه را از دست می‌دهد یا مبدأیی حمل می‌کند که دیوار آتش کلاینت دور می‌ریزد. ارائه‌دهندگان هم نشانی‌های مبدأیی را می‌اندازند که به مدار واگذارشده تعلق ندارند، و به همین دلیل این شبیه سیاه‌چالهٔ یک‌طرفه است نه خطای پروتکل تمیز.

تصمیم مسیریابی را برای ترافیکی که مبدأش ورودی دوم است بررسی کنید. پاسخ باید از واسطی خارج شود که درخواست روی آن رسیده، یا دست‌کم نشانی‌ای حمل کند که طرف دور آن را متعلق به این مسیر بداند. در سکوهای مسیریابی مبتنی بر سیاست این یعنی قاعده‌ای کلیدخورده به واسط ورودی یا مبدأ ترجمه‌شده، به‌همراه گزارهٔ ترجمه‌ای گره‌خورده به هر واسط بیرونی. هنگام اتصال کلاینت هم‌زمان روی هر دو واسط ثبت بگیرید؛ SYN که روی ISP B می‌رسد و SYN-ACK که روی ISP A خارج می‌شود پرسش را در یک اجرا روشن می‌کند.

به کلاینت راهی بدهید تا از ورودی دوم باخبر شود

انتقال تصمیمی سمت کلاینت است و هر خانوادهٔ کلاینت به شیوهٔ خودش از گزینه‌های جایگزین باخبر می‌شود. در ASA فهرست سرورهای پشتیبان از طریق ویژگی‌های webvpn سیاست گروه تحویل می‌شود، در حالی که کلاینت‌های دیگر فهرستی درون پروفایل یا پروفایل دوم دستی که کاربر انتخاب می‌کند انتظار دارند. راهنمای سیاست اتصال سیسکو هم اطلاعات پیکربندی‌شده در کلاینت و هم اطلاعات ارائه‌شده از درگاه را توصیف می‌کند، و این جزئیات وابسته به پروتکل را نباید به هر کلاینت یا حالت تونل تعمیم داد. پیش از ساختن ورودی دوم حول مکانیزم اشتباه، تأیید کنید که کلاینت مستقر کدام مکانیزم را پیاده می‌کند.

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

یک نشانی روی دو ارائه‌دهنده محصول دیگری است

نگه‌داشتن یک نشانی عمومی قابل دسترس از هر دو مدار یک سرویس مسیریابی است، نه یک خانهٔ تیک در VPN. به فضای نشانی‌ای نیاز دارد که هر دو ارائه‌دهنده حاضر به حمل آن باشند و به‌گونه‌ای اعلام شود که شبکه‌هایشان بپذیرند، و همین است که چندخانگی با فضای مستقل از ارائه‌دهنده و BGP فراهم می‌کند. اختصاص دادن نشانی ISP A به واسط ISP B به آنجا نمی‌رسد؛ بسته به شبکه‌ای می‌رسد که هرگز آن پیشوند را اعلام نکرده و در بالادست دور ریخته می‌شود.

برای انتشار دو ورودی به هیچ‌یک از این‌ها نیاز ندارید. اگر کلاینت می‌تواند دو نام را نگه دارد و میان آن‌ها جابه‌جا شود، دو ورودی مستقل کافی است و از شمارهٔ AS، ترتیبات peering و پیشوندی که باید همه‌جا پذیرفته شود دوری می‌کنید. گزینهٔ نشانی قابل‌حمل را تنها زمانی در نظر بگیرید که واقعاً به یک نقطهٔ ورود پایدار نیاز دارید که نتوان کلاینت‌ها را برای جایگزینی آن بازپیکربندی کرد، یا وقتی انتقال مبتنی بر DNS با تأخیر TTL آن برای قطعی که برایش طراحی می‌کنید بیش از حد کند است.

بعد چه چیزی را بررسی کنید

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

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