kubectl ไม่สามารถแก้ไขชื่อ API ของคลัสเตอร์ส่วนตัวผ่าน OpenVPN ได้

kubectl ล้มเหลวในการค้นหาชื่อในขณะที่อุโมงค์ทำงานอยู่และที่อยู่ส่วนตัวของ API ยังตอบ ping อยู่ เส้นทางถูกต้อง ไคลเอนต์กำลังถามตัวแก้ไขชื่อที่ไม่เคยรู้จักโซนส่วนตัวของคลัสเตอร์ การแก้ไขที่ใช้บ่อยที่สุดมีสองวิธี คือผลักตัวแก้ไขชื่อของเครือข่ายเสมือนไปยังไคลเอนต์ VPN ทุกตัว หรือปักชื่อไว้ในเครื่องด้วยรายการ hosts หรือ forwarder แบบมีเงื่อนไข ทั้งสองวิธีแก้อาการเดียวกันด้วยความเป็นเจ้าของที่ต่างกัน และการสับสนระหว่างสองวิธีนี้ทำให้ทีมต้องแก้ไฟล์ hosts ทุกครั้งที่ปลายทางถูกสร้างใหม่

การแก้ชื่อและการเข้าถึงล้มเหลวคนละชั้น

ลองค้นหาด้วยตัวเองก่อนจะเปลี่ยนอะไร getent hosts บน Linux หรือ nslookup บน Windows บอกว่าลูกข่ายได้รับคำตอบหรือไม่ หมดเวลาหรือ NXDOMAIN ชี้ไปที่ตัวแก้ไขชื่อ ขณะที่คำตอบที่ผิดที่อยู่ชี้ไปที่ระเบียนเก่าหรือทางออกสาธารณะ

จากนั้น ยืนยันว่า kubectl ต่อกับเซิร์ฟเวอร์ใดจริง ๆ บริบท kubeconfig เก็บ URL ไว้ และเส้นทาง VPN ไม่เขียนทับ URL นั้น ถ้าบริบทระบุปลายทางสาธารณะ 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 ถูกสร้างใหม่ มันยังซ่อนช่องว่างจริงจากคนอื่นในทีม

forwarder แบบมีเงื่อนไขขยายได้ดีกว่าโดยไม่ต้องผลัก DNS ไปยังทุกไคลเอนต์ dnsmasq ส่งโซนหนึ่งไปยังตัวแก้ไขชื่อของ VNet และปล่อยอย่างอื่นไว้ได้ server=/cluster.internal/10.0.0.4 DNS ของ Windows มี forwarder แบบมีเงื่อนไข และไคลเอนต์ Windows ใช้กฎ NRPT สำหรับการแยกเดียวกันได้ forwarder ยังต้องมีเส้นทางไปยังตัวแก้ไขชื่อของ VNet

การส่งต่อทำให้การท่องเว็บปกติอยู่ภายในเครื่อง ซึ่งสำคัญใน split tunnel มันยังให้ที่เดียวสำหรับบันทึกคำถามของโซนส่วนตัว และที่เดียวที่พังเมื่อโฮสต์ของ forwarder ย้าย

เลือกตามความเป็นเจ้าของ ไม่ใช่ตามความสะดวก

ผลักตัวแก้ไขชื่อเมื่อคุณควบคุมโปรไฟล์ VPN และต้องการให้ทุกชื่อส่วนตัวทำงาน ไม่ใช่แค่ API เลือก forwarder เมื่อไคลเอนต์ต้องเก็บ 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 ครั้งถัดไป

เริ่มจากการค้นหา เลือกเส้นทางของตัวแก้ไขชื่อที่ตรงกับเจ้าของโซน แล้วตรวจสอบปลายทาง ถ้าทั้งสามผ่าน ปัญหาที่เหลือคือการอนุญาต ไม่ใช่การแก้ชื่อ