kubectl OpenVPN দিয়ে ব্যক্তিগত ক্লাস্টারের API সমাধান করতে পারে না

kubectl নাম খোঁজায় ব্যর্থ হয় যখন টানেল চালু এবং API-র ব্যক্তিগত ঠিকানা এখনও ping-এ সাড়া দেয়। পথ ঠিক আছে; ক্লায়েন্ট এমন রিজলভারকে জিজ্ঞাসা করছে যে ক্লাস্টারের ব্যক্তিগত জোন সম্পর্কে কখনও শোনেনি। দুটি সংশোধন সবচেয়ে বেশি ব্যবহৃত হয়: ভার্চুয়াল নেটওয়ার্কের রিজলভার প্রতিটি VPN ক্লায়েন্টে পাঠানো, অথবা নামটি স্থানীয়ভাবে hosts এন্ট্রি বা শর্তসাপেক্ষ ফরওয়ার্ডার দিয়ে পিন করা। দুটোই একই উপসর্গ ভিন্ন দায়িত্বে সমাধান করে, আর এগুলো মিশিয়ে ফেলাই কারণ টিমগুলো প্রতিবার এন্ডপয়েন্ট পুনর্নির্মাণ হলে hosts ফাইল সম্পাদনা করে।

সমাধান ও নাগাল আলাদা স্তরে ব্যর্থ হয়

কিছু বদলানোর আগে খোঁজাটি নিজে চালান। Linux-এ getent hosts বা Windows-এ nslookup বলে ক্লায়েন্ট আদৌ উত্তর পায় কি না; সময় শেষ বা NXDOMAIN রিজলভারের দিকে ইঙ্গিত করে, আর ভুল ঠিকানার উত্তর পুরোনো রেকর্ড বা সর্বজনীন পথের দিকে ইঙ্গিত করে।

তারপর নিশ্চিত করুন 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: ভার্চুয়াল নেটওয়ার্কের রিজলভার টানেলে পাঠান

যখন VPN সার্ভার ভার্চুয়াল নেটওয়ার্কের ভিতরে চলে, ক্লায়েন্টরা সার্ভার হোস্টের মতো একই রিজলভার ব্যবহার করতে পারে। 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 প্রোফাইলে গুরুত্বপূর্ণ। রিজলভারের ঠিকানা পাঠানো তাকে নাগালযোগ্য করার সমান নয়: যদি টানেল দিয়ে কেবল ক্লাস্টারের সাবনেট যায়, 10.0.0.4-এ কোয়েরি স্থানীয় LAN দিয়ে বেরিয়ে মারা যায়। রিজলভারের জন্য হোস্ট রুট পাঠান, বা তার সাবনেট টানেলে অন্তর্ভুক্ত করুন।

গ্রহণকারী পক্ষেরও নীতি আছে। ক্লায়েন্টের ঠিকানা পরিসর থেকে নাগালযোগ্য রিজলভার তবুও সেখান থেকে আসা কোয়েরি প্রত্যাখ্যান করতে পারে, আর ভার্চুয়াল নেটওয়ার্কে সংযুক্ত ব্যক্তিগত জোন কেবল সেই ক্লায়েন্টদের উত্তর দেয় যারা ওই নেটওয়ার্কের DNS পথে আসে। পাঠানোর পরে খোঁজা সময় শেষ হলে, ক্লায়েন্ট আবার ছোঁয়ার আগে রিজলভারের নিজের লগ দেখুন।

ক্লায়েন্টে যাচাই করুন কী প্রয়োগ হয়েছে: systemd-resolved Linux-এ resolvectl status, macOS-এ scutil --dns, Windows-এ ipconfig /all। পাঠানো DNS সার্ভার যদি কখনও না দেখা যায়, তার অর্থ প্রোফাইল আবার লোড হয়নি।

বিকল্প B: hosts এন্ট্রি ও শর্তসাপেক্ষ ফরওয়ার্ডিং

hosts এন্ট্রি সবচেয়ে ছোট সম্ভাব্য সংশোধন এবং সবচেয়ে নাজুক। এটি একটি নামকে একটি মেশিনে একটি ঠিকানার সঙ্গে মেলায়, তাই ডেমোর জন্য কাজ করে এবং ব্যক্তিগত এন্ডপয়েন্ট বা তার IP পুনর্নির্মিত হলে ভেঙে যায়। এটি প্রকৃত ফাঁক বাকি টিমের কাছ থেকেও লুকায়।

শর্তসাপেক্ষ ফরওয়ার্ডার প্রতিটি ক্লায়েন্টে DNS না পাঠিয়েই ভালো স্কেল করে। dnsmasq একটি জোন VNet রিজলভারে পাঠিয়ে বাকি সবকিছু শান্ত রাখতে পারে: server=/cluster.internal/10.0.0.4। Windows DNS-এ শর্তসাপেক্ষ ফরওয়ার্ডার আছে, আর Windows ক্লায়েন্ট একই বিভাজনের জন্য NRPT নিয়ম ব্যবহার করতে পারে। ফরওয়ার্ডারের তবুও VNet রিজলভার পর্যন্ত রুট দরকার।

ফরওয়ার্ডিং সাধারণ ব্রাউজিং স্থানীয় রাখে, যা split tunnel-এ গুরুত্বপূর্ণ। এটি আপনাকে ব্যক্তিগত জোনের কোয়েরি লগ করার একটি জায়গা এবং ফরওয়ার্ডার হোস্ট সরে গেলে ভাঙার একটি জায়গা দেয়।

দায়িত্ব অনুযায়ী বেছে নিন, সুবিধা অনুযায়ী নয়

রিজলভার পাঠান যখন আপনি VPN প্রোফাইল নিয়ন্ত্রণ করেন এবং চান প্রতিটি ব্যক্তিগত নাম কাজ করুক, কেবল API নয়। ফরওয়ার্ডার বেছে নিন যখন ক্লায়েন্টদের বাকি সবকিছুর জন্য নিজের স্থানীয় DNS রাখতে হয়, বা যখন VPN ক্লাস্টার থেকে আলাদা টিম পরিচালনা করে।

hosts এন্ট্রি রোগনির্ণয়, মোতায়েন নয়। একটি ব্যবহার করুন প্রমাণ করতে যে API নাগালযোগ্য, তারপর সরিয়ে ফেলুন এবং রিজলভারের পথ ঠিক করুন; রেখে দিলে পরে রাউটিং প্রশ্ন ধন-সন্ধানে পরিণত হয়। যে বিকল্পই বেছে নিন, জোন, রিজলভারের ঠিকানা এবং যে রুট কোয়েরি বহন করে তা লিখে রাখুন।

API এন্ডপয়েন্ট পরীক্ষা করুন, কেবল নাম নয়

খোঁজা সফল হলে, ক্লাস্টার CA দিয়ে API-র সংস্করণ এন্ডপয়েন্ট আনুন। curl --cacert ca.crt https://api.internal.example:6443/version TLS ও অনুমতির ব্যর্থতা DNS থেকে আলাদা করে। 403 মানে নাম ও সংযোগ কাজ করে এবং পরিচয় করে না।

এছাড়াও দেখুন ক্লায়েন্টের ঠিকানা পরিসর ক্লাস্টারের অনুমোদিত নেটওয়ার্ক বা ফায়ারওয়াল দ্বারা অনুমোদিত কি না। ব্যক্তিগত ক্লাস্টার প্রায়ই API ট্রাফিক কেবল VNet বা peered পরিসর থেকে গ্রহণ করে, তাই অন্য পুল থেকে ঠিকানা দেওয়া টানেল নেটওয়ার্ক স্তরে সংযুক্ত হয় এবং API-তে বাদ পড়ে।

এস্কেলেট করার সময় চারটি তথ্য লিখুন: ক্লায়েন্ট যে রিজলভার ব্যবহার করেছে, যে ঠিকানা ফিরিয়েছে, নির্বাচিত kubeconfig কনটেক্সটে সার্ভার URL, এবং প্রথম ব্যর্থ অপারেশন। সেই রেকর্ড পরের ইঞ্জিনিয়ারকে বলে DNS, রাউটিং বা ফায়ারওয়াল নীতি বদলানো উচিত কি না, এবং পরের hosts ফাইল সম্পাদনা থামায়।

খোঁজা দিয়ে শুরু করুন, জোনের মালিকের সঙ্গে মেলে এমন রিজলভার পথ বেছে নিন, তারপর এন্ডপয়েন্ট যাচাই করুন। তিনটিই পাস হলে, অবশিষ্ট সমস্যা অনুমতি, নাম সমাধান নয়।