DNS در AWS Client VPN: از resolver مربوط به VPC استفاده کنید، نه subnet

endpoint در 10.0.8.0/24 قرار دارد، پس resolver باید 10.0.8.2 باشد. این استدلال را بیشتر از همه می‌شنوم و دو بار غلط است. Route 53 Resolver روی محدوده اصلی IPv4 مربوط به VPC به‌علاوه دو پاسخ می‌دهد که برای VPC با 10.0.0.0/16 برابر 10.0.0.2 است، مهم نیست endpoint از کدام subnet استفاده کند. خطای دوم بی‌صداتر است: قرار دادن آدرس درست در endpoint به این معنا نیست که سیستم‌عامل client هرگز چیزی از آن بپرسد. هر دو خطا یک نشانه می‌دهند: resolve نام برای بعضی clientها کار می‌کند و برای بعضی دیگر شکست می‌خورد.

افسانه از association زیرشبکه شروع می‌شود

association درباره این است که رابط‌های شبکه الاستیک برای اتصال‌های client کجا زندگی می‌کنند، نه این‌که کدام آدرس resolver وجود دارد. زیرشبکه‌های endpoint به clientها آدرسی داخل VPC می‌دهند و هرکدام resolver خودشان را حمل نمی‌کنند.

وقتی این دو ایده را جدا کنید، حساب‌وکتاب دیگر مرموز نیست و عیب‌یابی به client منتقل می‌شود، همان‌جایی که بیشتر این موارد واقعاً پایان می‌یابد.

آدرس را از محدوده اصلی VPC محاسبه کنید

CIDR اصلی IPv4 مربوط به VPC را بردارید و دو به آدرس شبکه اضافه کنید. 10.0.0.0/16 می‌شود 10.0.0.2، 172.31.0.0/16 می‌شود 172.31.0.2، و VPC با محدوده ثانویه resolver را روی محدوده اصلی نگه می‌دارد. subnet با 10.0.8.0/24 داخل آن VPC آن را جابه‌جا نمی‌کند. آدرس را کنار شناسه VPC بنویسید پیش از آن‌که به endpoint دست بزنید، چون این عدد ویژگی VPC است نه اتصال.

VPC همچنین روی آدرس link-local 169.254.169.253 پاسخ می‌دهد. این آدرس از داخل VPC قابل دسترسی است، اما مقصد مسیریابی عمومی برای لپ‌تاپ در آن سوی تونل نیست.

پس دو آدرس معتبر resolver وجود دارد و هیچ‌کدام subnet به‌علاوه دو نیست.

تنظیم endpoint چه می‌کند و چه نمی‌کند

endpoint در Client VPN فیلدهای سرور DNS دارد و جایی که کنسول گزینه resolver مربوط به VPC را پیشنهاد می‌دهد همان ایده را پر می‌کند. تنظیم آن‌ها تغییر می‌دهد که سرویس هنگام برقراری اتصال چه چیزی به clientها تحویل می‌دهد. اما تغییری در رفتار client مدیریت‌نشده OpenVPN با آن مقدار نمی‌دهد، چون client هنوز باید آن را روی سیستم‌عامل اعمال کند. شکاف همین‌جاست که جمله «روی Mac من کار می‌کند ولی روی جعبه Linux نه» از آن می‌آید.

در Linux، یکپارچه‌سازی resolver در اختیار مدیر اتصال است نه کاربر. ویرایش دستی /etc/resolv.conf ثابت می‌کند آدرس برای یک نشست کار می‌کند و بعد در اتصال مجدد ناپدید می‌شود؛ به همین دلیل بسیاری از موارد اصلاح‌شده صبح روز بعد برمی‌گردند.

پس از اتصال، resolver فعال را روی client بررسی کنید، نه صفحه پیکربندی endpoint.

split tunneling می‌تواند resolver درست را خنثی کند

با split tunneling فقط مسیرهایی که به تونل فرستاده می‌شوند استفاده می‌شوند. اگر آدرس resolver زیر پوشش هیچ مسیری نباشد، پرس‌وجو از رابط محلی خارج می‌شود و روتر خانه شما پاسخ می‌دهد. آدرس در endpoint هنوز درست است و جست‌وجو هنوز شکست می‌خورد. مسیر resolver را اضافه کنید و دوباره آزمایش کنید.

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

برای آدرس Amazon DNS گروه‌های امنیتی را باز نکنید

غریره هنگام timeout جست‌وجوها این است که قاعده‌ای اجازه‌دهنده UDP 53 به آدرس resolver اضافه کنید. AWS مستند می‌کند که گروه‌های امنیتی و ACLهای شبکه ترافیک Amazon DNS را مانند ترافیک به یک نمونه DNS سفارشی فیلتر نمی‌کنند. باز کردن آن قواعد برای resolver مربوط به VPC هیچ چیزی را تغییر نمی‌دهد و مرز را بی‌دلیل گسترش می‌دهد. resolver‌ای که خودتان اجرا می‌کنید موضوع دیگری است و واقعاً به قواعد خودش نیاز دارد.

اگر هر دو در طراحی شما هستند، پیش از ویرایش هر قاعده‌ای بررسی کنید client واقعاً به کدام اشاره می‌کند.

مسیر را بررسی کنید، سپس چیز دیگری اندازه بگیرید

یک نام عمومی را resolve کنید، یک نام خصوصی ثبت‌شده در یک hosted zone خصوصی متصل به VPC را resolve کنید و بین این دو resolver فعال client را بخوانید. این توالی «آدرس resolver غلط است» را از «zone متصل نیست» و از «client تنظیم را نادیده گرفته» جدا می‌کند. هرکدام اصلاح متفاوتی دارند و هیچ‌کدام مشکل throughput نیست.

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