kubectl نمی‌تواند API خوشه خصوصی را از طریق OpenVPN حل کند

kubectl هنگام جستجوی نام شکست می‌خورد در حالی که تونل بالاست و نشانی خصوصی API هنوز به ping پاسخ می‌دهد. مسیر درست است؛ کلاینت از resolver می‌پرسد که هرگز درباره منطقه خصوصی خوشه نشنیده است. دو اصلاح بیشتر استفاده می‌شود: فرستادن resolver شبکه مجازی به هر کلاینت VPN، یا میخ کردن نام به صورت محلی با ورودی hosts یا forwarder شرطی. هر دو همان نشانه را با مالکیت متفاوت حل می‌کنند و قاطی کردن آن‌ها باعث می‌شود تیم‌ها هر بار که نقطه پایانی بازسازی می‌شود فایل‌های hosts را ویرایش کنند.

حل نام و دسترس‌پذیری در لایه‌های متفاوت شکست می‌خورند

پیش از تغییر هر چیزی خودتان جستجو را اجرا کنید. getent hosts در Linux یا nslookup در Windows می‌گوید آیا کلاینت اصلاً پاسخی می‌گیرد؛ پایان مهلت یا NXDOMAIN به resolver اشاره می‌کند، در حالی که پاسخ با نشانی نادرست به رکورد کهنه یا گذرگاه عمومی اشاره دارد.

سپس تأیید کنید kubectl واقعاً به کدام سرور وصل می‌شود. بافت kubeconfig یک URL ذخیره می‌کند و مسیر VPN آن را بازنویسی نمی‌کند: اگر بافت نقطه پایانی عمومی را نام ببرد، DNS می‌تواند بی‌عیب باشد و فرمان باز هم شکست بخورد.

getent hosts api.internal.example
kubectl config view --minify -o jsonpath='{.clusters[0].cluster.server}'
kubectl -v=8 get nodes 2>&1 | head -40

نشانه سوم شکل شکست پس از جستجو است. نامی که به نشانی خصوصی حل می‌شود و سپس مهلت TCP می‌گیرد مشکل فایروال یا شبکه مجاز است. نامی که به نشانی عمومی حل می‌شود یعنی پرس‌وجو از منطقه خصوصی خارج شده است. این سه نتیجه را جدا نگه دارید؛ هر یک شما را به مسئول متفاوتی می‌فرستد.

گزینه A: resolver شبکه مجازی را به تونل بفرستید

وقتی سرور VPN داخل شبکه مجازی اجرا می‌شود، کلاینت‌ها می‌توانند از همان resolver میزبان سرور استفاده کنند. در OpenVPN Community سرور گزینه DNS را می‌فرستد؛ Access Server همان تنظیم را در رابط مدیریت نشان می‌دهد و کلاینت‌ها باید پروفایل را دوباره بارگیری کنند زیرا دستور DNS درون آن سفر می‌کند.

# server.conf
push "dhcp-option DNS 10.0.0.4"
push "route 10.0.0.4 255.255.255.255"

خط مسیر در پروفایل‌های split tunnel مهم است. فرستادن نشانی resolver با قابل دسترس کردن آن یکی نیست: اگر فقط زیرشبکه خوشه از تونل بگذرد، پرس‌وجو به 10.0.0.4 از LAN محلی خارج می‌شود و می‌میرد. مسیر میزبان برای resolver بفرستید یا زیرشبکه آن را در تونل بگنجانید.

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

روی کلاینت بررسی کنید چه اعمال شده است: resolvectl status در Linux با systemd-resolved، scutil --dns در macOS، ipconfig /all در Windows. سرور DNS فرستاده‌شده‌ای که هرگز ظاهر نمی‌شود یعنی پروفایل دوباره بارگیری نشده است.

گزینه B: ورودی‌های hosts و ارسال شرطی

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

forwarder شرطی بدون فرستادن DNS به هر کلاینت بهتر مقیاس می‌شود. dnsmasq می‌تواند یک منطقه را به resolver شبکه مجازی بفرستد و بقیه را به حال خود بگذارد: server=/cluster.internal/10.0.0.4. DNS ویندوز forwarder شرطی دارد و کلاینت‌های ویندوز می‌توانند برای همان تفکیک از قاعده NRPT استفاده کنند. forwarder هنوز به مسیری به resolver شبکه مجازی نیاز دارد.

ارسال، مرور عادی را محلی نگه می‌دارد که در split tunnel اهمیت دارد. همچنین یک جا برای ثبت پرس‌وجوهای منطقه خصوصی و یک جا برای شکستن وقتی میزبان forwarder جابه‌جا می‌شود به شما می‌دهد.

بر اساس مالکیت انتخاب کنید، نه راحتی

وقتی پروفایل VPN را کنترل می‌کنید و می‌خواهید هر نام خصوصی کار کند نه فقط API، resolver را بفرستید. وقتی کلاینت‌ها باید DNS محلی خود را برای بقیه چیزها نگه دارند یا وقتی VPN را تیمی غیر از خوشه مدیریت می‌کند، forwarder را انتخاب کنید.

ورودی‌های hosts تشخیص است نه استقرار. یکی را به کار ببرید تا ثابت کنید API قابل دسترس است، سپس آن را بردارید و مسیر resolver را درست کنید؛ باقی گذاشتن آن بعداً پرسش مسیریابی را به جستجوی گنج تبدیل می‌کند. هر گزینه‌ای که انتخاب کنید، منطقه، نشانی resolver و مسیری که پرس‌وجو را می‌برد بنویسید.

نقطه پایانی API را آزمایش کنید، نه فقط نام را

وقتی جستجو موفق شد، نقطه پایانی نسخه API را با CA خوشه بگیرید. curl --cacert ca.crt https://api.internal.example:6443/version خطاهای TLS و مجوز را از DNS جدا می‌کند. 403 یعنی نام و اتصال کار می‌کنند و هویت کار نمی‌کند.

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

هنگام بالا بردن سطح چهار واقعیت را ثبت کنید: resolverی که کلاینت استفاده کرد، نشانی که بازگرداند، URL سرور در بافت kubeconfig انتخاب‌شده و نخستین عملیاتی که شکست خورد. این سابقه به مهندس بعدی می‌گوید آیا DNS، مسیریابی یا سیاست فایروال را تغییر دهد و ویرایش بعدی فایل hosts را متوقف می‌کند.

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