یک نام خصوصی از یک نمونه EC2 حل می‌شود اما از لپ‌تاپی که از طریق VPN متصل است حل نمی‌شود، و ناحیه در کنسول درست به نظر می‌رسد. غریزه این است که رکورد را ویرایش کنید، که تقریباً هرگز مشکل نیست. رکورد به کسی پاسخ می‌دهد؛ فقط به لپ‌تاپ شما پاسخ نمی‌دهد. آنچه بین دو فراخواننده متفاوت است این است که کدام resolver را می‌پرسند و آیا آن resolver مسیر پشتیبانی‌شده‌ای به نمای DNS در VPC دارد.

با اثبات اینکه رکورد وجود دارد شروع می‌کنم و بقیه وقت را روی مسیر پرس‌وجو می‌گذرانم. این‌ها سیستم‌های جداگانه‌ای هستند و به شکل‌های مختلف شکست می‌خورند.

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

سه نتیجه سه چیز متفاوت یعنی، و یک پرس‌وجو آن‌ها را جدا می‌کند: dig را برای نام در برابر resolverی اجرا کنید که کلاینت واقعاً استفاده می‌کند.

What you seeWhat it usually meansFirst thing to check
SERVFAIL, or a timeout after several secondsNo path to the resolver, or the resolver cannot reach AWSRoute to the endpoint and the security policy on port 53
NXDOMAIN from a resolver that did answerThe resolver replied, but the zone is not in its viewZone association or the forwarding rule for that namespace
A public address for an internal nameSplit DNS is not in effect for this clientWhich resolver the client is configured to use

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

چرا نشانی به‌علاوه دو در VPC یک resolver دوردست نیست

نشانی CIDR به‌علاوه دو سرویسی محلی برای منابع داخل VPC است. AWS مستند می‌کند که هدایت پرس‌وجوها از شبکه‌های محلی، یا از سرورهای DNS یک VPC دیگر، مستقیماً به آن نشانی پشتیبانی نمی‌شود و می‌تواند نتایج ناپایدار بدهد.

این یعنی هرگز آزمایشی کار نمی‌کند نیست. یعنی رفتار یک قرارداد نیست که بتوانید در یک اسکریپت پشتیبانی بگذارید. جهت پشتیبانی‌شده یک endpoint ورودی Resolver است: جفتی نشانی داخل VPC شما، قابل دسترس از شبکه‌ای که کنترل می‌کنید، که پرس‌وجوهای رسیده از بیرون AWS را می‌پذیرد.

مسیر را به ترتیبی بسازید که تمیز شکست می‌خورد

سه پرش باید وجود داشته باشد و هرکدام شیوه شکست خودش را دارد.

VPN client -> approved DNS forwarder
forwarder -> forwarding rule for internal.example
forwarding rule -> Resolver inbound endpoint addresses

هدایت‌کننده به مسیری به نشانی‌های endpoint از طریق VPN نیاز دارد و مسیر بازگشت هم باید کار کند. برای DNS متعارف روی درگاه 53، endpoint از طریق UDP و TCP پاسخ می‌دهد، پس هر دو پروتکل باید مجاز باشند و هر دو باید از هر بازرسی وضعیتی در میانه جان سالم به در ببرند.

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

یک endpoint خروجی جهت مخالف را سرویس می‌دهد و به پرس‌وجویی که از لپ‌تاپ شما می‌آید پاسخ نمی‌دهد.

از هر دو سر بررسی کنید

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

اگر هر دو شکست بخورند، به سیاست امنیتی روی endpoint و به نشانی مبدأیی که واقعاً می‌بیند نگاه کنید. یک هدایت‌کننده پشت NAT نشانی NAT را به جای نشانی VPN لپ‌تاپ ارائه می‌دهد و همین تفاوت برای انداختن پرس‌وجو کافی است. اگر هر دو موفق شوند اما برنامه همچنان شکست بخورد، شاید برنامه از resolver دیگری غیر از آنکه آزمودید استفاده می‌کند.

فضاهای نام عمومی و خصوصی را عامدانه جدا نگه دارید. Split DNS سیاستی است که پیکربندی می‌کنید، نه اثر جانبی اینکه یک جست‌وجو تصادفاً داده برگرداند.

کاری که نمی‌کردم

قاعده‌ای NAT اضافه نمی‌کردم که یک جست‌وجو را کار انداخت و آن را طراحی بنامم.

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

مقالات مرتبط