kubectl לא מצליח לפתור את ה-API של האשכול הפרטי דרך OpenVPN

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. ל-DNS של Windows יש מעבירים מותנים, ולקוחות 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 הבאה.

התחילו בחיפוש, בחרו את נתיב הפותר שמתאים למי שמחזיק באזור, ואז אמתו את נקודת הקצה. אם כל השלושה עוברים, הבעיה שנותרה היא הרשאה, לא פתרון שמות.