kubectl د OpenVPN له لارې د خصوصي کلسټر API نه شي حل کولی

kubectl د نوم پلټنې پر مهال ناکام شي پداسې حال کې چې ټونل پورته دی او د API خصوصي پته لا هم ping ته ځواب وایي۔ لار سمه ده؛ مراجع له هغه حل کوونکي پوښتنه کوي چې د کلسټر خصوصي زون په اړه یې هیڅکله نه دی اورېدلی۔ دوه سمونې ډېرې کارول کیږي: د مجازي شبکې حل کوونکی هر VPN مراجع ته لیږل، یا نوم په محلي ډول د hosts داخل یا شرطي لېږدوونکي سره ټینګول۔ دواړه ورته نښه په بېلو مسؤلیتونو حل کوي، او د دوی ګډول هغه څه دي چې ټیمونه هر وخت چې پای ټکی بیا جوړ شي د hosts فایلونه سمونې ته اړ باسي۔

حل کول او د لاسرسي وړتیا په بېلو طبقو کې ناکام شي

د هر څه بدلولو دمخه پلټنه پخپله وکړئ۔ getent hosts په Linux یا nslookup په Windows درته وایي چې مراجع اصلاً ځواب ترلاسه کوي که نه؛ د وخت پای یا 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 لارې ته راشي۔ که پلټنه له لیږلو وروسته پای ته ورسیږي، د مراجع بیا لمسولو دمخه د حل کوونکي خپل ثبتونه وګورئ۔

په مراجع کې وګورئ چې څه پلي شوي: resolvectl status په Linux systemd-resolved، scutil --dns په macOS، ipconfig /all په Windows۔ هغه لیږل شوی 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 پای ټکی وازموئ، نه یوازې نوم

کله چې پلټنه بریالۍ شي، د API د نسخې پای ټکی د کلسټر CA سره ترلاسه کړئ۔ curl --cacert ca.crt https://api.internal.example:6443/version د TLS او اجازې ناکامۍ له DNS څخه بېلوي۔ 403 مانا دا ده چې نوم او اړیکه کار کوي او هویت نه۔

همدارنګه وګورئ چې آیا د مراجع د پتو حد د کلسټر مجاز شبکو یا اور وژنې لخوا اجازه لري۔ خصوصي کلسټرونه ډیری وختونه د API ترافیک یوازې له VNet یا peer حدونو څخه مني، نو هغه ټونل چې پتې له بل حوض څخه ورکوي په شبکه طبقه کې نښلول کیږي او په API کې غورځول کیږي۔

کله چې پورته کوئ څلور حقایق ولیکئ: هغه حل کوونکی چې مراجع کارولی، هغه پته چې بیرته راوګرځوله، د سرور URL په غوره شوې kubeconfig زمینه کې، او لومړنی عملیات چې ناکام شو۔ هغه ثبت راتلونکي انجنیر ته وایي چې آیا DNS، لارښوونه یا د اور وژنې پالیسي بدله شي، او راتلونکی د hosts فایل سمون بندوي۔

له پلټنې پیل وکړئ، هغه د حل کوونکي لاره غوره کړئ چې د زون مالک سره سمه وي، بیا پای ټکی تایید کړئ۔ که درې واړه تېر شي، پاتې ستونزه اجازه ده، نه د نوم حل۔