DNS نقطه پایانی AWS Client VPN: چرا تثبیت IP حل‌شده شکست می‌خورد
نام نقطه پایانی AWS Client VPN را با نشانی‌ای که حل کرده‌اید جایگزین کنید و تونل بعداً از کار می‌افتد. نام صادرشده و پیشوند تصادفی آن را نگه دارید.
هفته گذشته dig +short یک نشانی برای نام نقطه پایانی در نمایه AWS Client VPN شما داد و تونل متصل شد. این هفته همان نمایه روی لپ‌تاپ شما در حالت 'Connecting' می‌ماند، در حالی که نسخه دست‌نخورده همکارتان هنوز کار می‌کند. هیچ چیز مسدود نشد و گواهی منقضی نشد. کسی نام میزبان نقطه پایانی را با همان نشانی حل‌شده جایگزین کرده است و سرویس دیگر آنجا پاسخ نمی‌دهد. نام صادرشده همان بخشی است که برای بقا در برابر این تغییر ساخته شده است.
نام در نمایه شما ممکن است همان نامی نباشد که پرس‌وجو می‌شود
نمایه‌هایی که از Client VPN صادر می‌شوند معمولاً remote-random-hostname دارند. با فعال بودن این گزینه، کلاینت یک برچسب یک‌بارمصرف می‌سازد، آن را با نقطه به نام نقطه پایانی می‌چسباند و نام ترکیبی را حل می‌کند. یک رکورد wildcard در ناحیه نقطه پایانی به هر برچسبی پاسخ می‌دهد، به همین دلیل یک پیشوند ساختگی هم حل می‌شود و به همین دلیل این ترفند وقتی پرس‌وجو را دستی بازتولید می‌کنید نامرئی می‌ماند.
پس وقتی نام نقطه پایانی را در یک ترمینال می‌چسبانید و پاسخ می‌گیرید، نامی متفاوت از نامی که کلاینت هنگام اتصال استفاده می‌کند حل کرده‌اید. این ناهماهنگی نقصی نیست که در نمایه اصلاح شود. برچسب عمداً از نو ساخته می‌شود: این گزینه مانع نگه‌داشتن پاسخ کهنه در حافظه‌های نهان می‌شود و هرگز ماشین یا نشست شما را شناسایی نمی‌کند.
به مورد سازگاری برخورده‌ام که کلاینت گزینه را کاملاً نادیده می‌گیرد. AWS راه‌حل را مستند می‌کند: نام واقعی نقطه پایانی را نگه دارید و یک رشته تصادفی به‌همراه نقطه جلوی آن بگذارید و آن را الگویی برای نام‌گذاری بدانید، نه مقداری برای چسباندن. اعمال آن روی کلاینت قدیمی معقول است؛ کدنویسی سخت رشته پیشونددار به‌عنوان نقطه پایانی چنین نیست.
چرا یک پاسخ ذخیره‌شده نمی‌تواند درست بماند
نشانی‌های نقطه پایانی Client VPN توسط AWS مدیریت می‌شوند و با گذشت زمان تغییر می‌کنند، که مستندات بهترین شیوه‌ها صریح می‌گوید. پاسخی که ثبت می‌شود تصویری از یک حل است. نمایه‌ای که آن را سخت کد کند به محض جابه‌جایی سرویس به نمایه‌ای تبدیل می‌شود که به میزبان از کار افتاده اشاره می‌کند، و خطا به‌ندرت شبیه DNS به نظر می‌رسد: زمان‌سنج اتصال یا handshake متوقف می‌گیرید، پس مردم دنبال مسیریابی و گواهی‌ها می‌افتند.
همان پاسخ در /etc/hosts همان انقضا را با یک مشکل اضافه به ارث می‌برد. یک ورودی hosts از راه‌اندازی مجدد، صدور دوباره و تعمیرهای 'کلاینت را دوباره نصب کن' جان سالم به در می‌برد، پس هر بار که نشانی جابه‌جا می‌شود خطا برمی‌گردد. دیده‌ام یکی هفته‌ها بی‌ضرر ماند و سپس هر ماشینی که آن را داشت از کار انداخت، در حالی که نصب‌های تازه به‌طور عادی متصل می‌شدند. این شکاف، گروهی که شکست می‌خورد و گروهی که در همان حساب خوب است، ارزان‌ترین سرنخی است که می‌گیرید.
دامنه تصادفی‌سازی را هم درست تعیین کنید. برای هر تلاش اتصال رخ می‌دهد. تونل برقرارشده نقطه پایانی خود را دوباره حل نمی‌کند، وسط نشست سرور عوض نمی‌کند و درخواست‌های جداگانه برنامه‌ها هر یک میزبان VPN تازه انتخاب نمی‌کنند. تنها تلاش بعدی دوباره حل می‌کند، به همین دلیل نشستی که تمام بعدازظهر کار می‌کند درباره فردا صبح چیزی نمی‌گوید.
سرویس هنگام برپایی تونل چه چیزی را بررسی می‌کند
Client VPN لازم می‌داند نشانی‌ای که به آن متصل هستید با نشانی حل‌شده برای نام DNS نقطه پایانی مطابق باشد. همین یک شرط چندین خطای ظاهراً بی‌ربط را توضیح می‌دهد: رکورد DNS سفارشی که جای دیگری اشاره می‌کند، frontend سفارشی که به نشانی واقعی نقطه پایانی هدایت می‌کند، و نمایه‌ای که به نشانی خام بازنویسی شده است. AWS ترکیب رکورد سفارشی به‌همراه هدایت را با کلاینت‌های جدید AWS خطا می‌داند. بررسی باریک است؛ حکمی نیست که هر نام مستعار ممنوع باشد.
این قاعده کلی درباره پروتکل‌های VPN هم نیست. remote عددی در استقرار معمولی OpenVPN کاملاً معتبر است و بسیاری این‌گونه کار می‌کنند. محدودیت از ترتیب مدیریت‌شده می‌آید، نه از پروتکل زیر آن.
که سست‌کردن بررسی گواهی را بازتاب اشتباه می‌کند. اگر نمایه پس از تعویض نشانی شکست بخورد، غیرفعال‌کردن بررسی سرور خطا را جابه‌جا می‌کند به‌جای اصلاح حل یا شرط تطابق نشانی، و کلاینتی باقی می‌گذارد که به هر چیزی اعتماد می‌کند. CA صادرشده، بررسی سرور و تنظیمات احراز هویت متقابل را دقیقاً همان‌گونه که آمده‌اند نگه دارید.
فهرست‌های مجاز، خروج و DNS خصوصی سه مشکل جداگانه‌اند
قاعده فایروالی که باید پیش از اتصال لپ‌تاپ مقصدی را مجاز کند مربوط به شنونده بیرونی است. به مالک شبکه نام نقطه پایانی، انتقال و پورت پیکربندی‌شده را بدهید، سپس بپرسید آیا کنترل آن‌ها می‌تواند رفتار DNS سرویس را دنبال کند. قاعده‌ای که یک نشانی ثبت‌شده را نگه می‌دارد تصویری با انقضای نانوشته است. اگر کنترل فقط مقصدهای تغییرناپذیر را می‌پذیرد، این شکاف را پیش از استقرار حل کنید نه اینکه بی‌صدا پاسخی را سخت کد کنید.
شریکی که برای درخواست‌های پس از برپایی تونل به نشانی مبدأ ثابت نیاز دارد شرط دیگری دارد: خروج. آنچه یک وب‌سایت می‌بیند به مسیر برنامه و سیاست تونل تقسیم‌شده بستگی دارد، نه به نشانی‌ای که کلاینت به آن متصل شد. ترافیک تونل تقسیم‌شده ممکن است هرگز AWS را لمس نکند.
DNS خصوصی درون تونل لایه سوم است. حل‌کننده‌ای که به کلاینت‌ها داده می‌شود پس از اتصال به نام‌های داخلی پاسخ می‌دهد؛ نمی‌تواند نقطه پایانی عمومی را پیش از وجود تونل حل کند. خطای حل نقطه پایانی و خطای حل برنامه داخلی در مراحل متفاوت رخ می‌دهند و مخلوط‌کردن آن‌ها شما را به گزارش اشتباه می‌فرستد.
خانواده نشانی هم در همان فهرست است. پاسخ IPv4 درباره مسیر مجاز نقطه پایانی IPv6 یا دوپشته چیزی نمی‌گوید، پس تصویری که در یک خانواده گرفته شده شاهد خانواده دیگر نیست.
یک اتصال را بدون تثبیت هیچ چیز بررسی کنید
از نمایه همان‌گونه که صادر شده شروع کنید و بخوانید واقعاً چه می‌خواهد:
grep -nE '^remote|remote-random-hostname' profile.ovpn
dig +short cvpn-endpoint-ID.prod.clientvpn.REGION.amazonaws.com
ss -tnp | grep -E ':(443|1194)'سپس سه چیز را مقایسه کنید: نام نقطه پایانی که نمایه دارد، نشانی‌ای که کلاینت برای تلاش تازه گزارش می‌کند، و اینکه نام همین حالا به چه چیزی حل می‌شود. نامی که حل می‌شود فقط ثابت می‌کند رکورد پاسخ می‌دهد؛ انتقال و احراز هویت جدا هستند و نقطه پایانی لازم نیست به ping پاسخ دهد. گزارش خود کلاینت تنها منبع مورد میانی است، پس آن را در حین تلاش ثبت کنید نه بعد از آن.
| What you see | Usual cause | Next check |
|---|---|---|
| One machine fails, others connect | Pinned address or stale hosts entry on that machine | Diff its profile and hosts file against a working copy |
| Everyone fails at once, no config change | The endpoint address rotated | Confirm the current endpoint configuration with the account owner |
| Tunnel up, internal names fail | Client DNS policy, not endpoint resolution | Inspect the resolver pushed after connection |
نشانی‌ای که امروز پاسخ می‌دهد شاهدی درباره امروز است؛ نام همان چیزی است که سرویس معتبر نگه می‌دارد. مشاهده را ثبت کنید، آن را برای دارنده نقطه پایانی بفرستید و نمایه را به نام اشاره‌گر نگه دارید.
دو عادت را کنار بگذارید: غیرفعال‌کردن بررسی گواهی برای عبور از handshake متوقف، و چیدن برچسب‌ها جلوی نام نقطه پایانی به امید اینکه یکی بچسبد. برچسب از طریق رکورد wildcard حل می‌شود یا مشکل جای دیگری است. اگر نمایه درست پیکربندی‌شده باز هم شکست خورد، پرس‌وجوی دقیق و رویداد اتصال را بفرستید، نه نام میزبان بلندتر.
پیش از بستن: نمایه هنوز نام نقطه پایانی صادرشده را دارد، هیچ فایل hosts نشانی را تثبیت نمی‌کند، remote در گزارش کلاینت با حل فعلی مطابق است و قاعده فایروال نقطه پایانی را نام می‌برد نه یک نشانی. این همان حالتی است که به نفر بعدی تحویل می‌دهید.