در واقع چه کسی به نشانی اختصاصی VPN پاسخ می‌دهد؟

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

مسیر بسته در پشت نشانی

همتا IKE را به نشانی‌ای که به آن داده شده می‌فرستد، روی UDP 500 یا روی UDP 4500 وقتی گذر از NAT در میان است. هر دستگاهی که آن نشانی را روی مسیر در اختیار دارد، یا بسته را به‌صورت محلی دریافت و پاسخ می‌دهد، یا آن را به جایی دیگر هدایت می‌کند. این‌ها تنها دو امکان‌اند، و هر چیز دیگری در این مقاله از این ناشی می‌شود که کدام درست است.

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

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

مدل A: دروازه مالک نشانی است

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

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

ip -br addr show
ss -lunp | grep -E ':500|:4500'
sudo tcpdump -ni eth0 'udp port 500 or udp port 4500'

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

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

مدل B: دستگاه بالادستی آن را ترجمه می‌کند

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

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

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

هویت نشانی بیرونی نیست

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

هویت تأییدشده باز هم جداست. IKEv2 یک بار داده هویت و تبادل تأیید هویت حمل می‌کند که لازم نیست با نشانی بسته بیرونی مطابق باشد، و دقیقاً به همین دلیل طرح ترجمه‌شده هنوز می‌تواند درست تأیید هویت شود.

این استقلال سودمند و در همان حال تله است. دو نام DNS که به یک شنونده معمولی تحلیل می‌شوند پشتوانه‌های VPN متفاوت برنمی‌گزینند، و گواهی‌ای که یک هویت را نام می‌برد همتایی را که هویت دیگری انتظار دارد راضی نمی‌کند. پیش از فرض این که تنها نشانی این را تعیین می‌کند، تأیید کنید که همتا چه چیزی را بررسی می‌کند.

طرح را با مشاهده یک اتصال بپذیرید

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

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

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