การเข้าถึง Customer Edge
เส้นทางสี่แบบใช้งานได้ และเส้นทางใดที่ใช้ได้นั้นถูกตัดสินโดยสถานะของโหนด โดยตำแหน่งที่คุณ เชื่อมต่อมา และโดยสิ่งที่คุณต้องเข้าถึง — ไม่ใช่โดยความชอบส่วนตัว
| เส้นทาง | ต้องการโหนด ONLINE | ต้องการการเข้าถึงทางเครือข่าย | ข้อจำกัด | ครอบคลุม |
|---|---|---|---|---|
| Debug API | ใช่ | ใช่ | ประมาณ 25–30 นาทีในการวอร์มอัพบนไซต์ใหม่ | 34 คำสั่ง |
| Site Console | ไม่ | ผ่าน Azure Bastion ไม่ต้องใช้ jump host | Bastion ต้องเป็น Standard SKU ที่รองรับ tunneling และไม่ได้ถูกติดตั้งโดยค่าเริ่มต้น | UI แก้ไขปัญหาโหนดของ F5 |
| SSH | ไม่ | จากภายใน VNet ไปยังที่อยู่ภายในเท่านั้น | คีย์ต้องมีอยู่ตั้งแต่การบูตครั้งแรก | Site CLI บนเครื่องแบบเต็มรูปแบบ |
| Serial console | ไม่ | ไม่ | หนึ่งเซสชันต่อ VM; จำกัดการวาง 2,048 อักขระ | Site CLI บนเครื่องแบบเต็มรูปแบบ |
Serial console คือทางเลือกสุดท้าย และเป็นเส้นทางเดียวที่ยังใช้งานได้กับโหนดที่ไม่มีเส้นทาง เครือข่ายที่ทำงานอยู่
Site Console มักเป็นสิ่งแรกที่ควรลอง มันเรียกร้องจากคุณน้อยที่สุด —
ไม่ต้องแจกจ่ายคีย์ SSH ไม่ต้องมี jump host ไม่ต้องมี public IP บนโหนด และไม่ต้องเปลี่ยน VM —
เพราะการเข้าถึงกลายเป็นการตัดสินใจด้วย Azure RBAC แทนที่จะเป็นปัญหาการแจกจ่ายข้อมูลรับรอง
มันให้ UI แก้ไขปัญหาของ F5 เองแทนที่จะเป็นพื้นผิวคำสั่ง ดังนั้นจงข้ามไปใช้เส้นทางอื่น
เมื่อคุณต้องรันคำสั่งเฉพาะหรือต้องการเขียนสคริปต์ ข้อกำหนดเบื้องต้นเพียงข้อเดียวคือ Azure
Bastion ซึ่งการติดตั้งนี้กำหนดให้เป็นแบบเลือกเปิดใช้ (enable_bastion, ค่าเริ่มต้น false) เพราะโฮสต์
Standard-SKU มีค่าใช้จ่ายไม่ว่าจะมีใครเปิดอุโมงค์หรือไม่ก็ตาม
SSH คือสิ่งที่ควรใช้เมื่อ debug API ไม่เพียงพอ เพราะแอปพลายแอนซ์มีคำสั่งมากกว่า 34 คำสั่ง
ที่ API นั้นเปิดเผยอยู่อย่างมาก มันมีต้นทุนสองอย่าง คีย์ถูกเขียนโดย cloud-init จึงต้องมีอยู่
ตั้งแต่การบูตครั้งแรก ซึ่งหมายความว่าการเปิดใช้บนโหนดที่กำลังทำงานอยู่จะแทนที่ CE VM ทุกตัว —
เป็นการสร้างฟลีตใหม่มากกว่าการเปลี่ยนการตั้งค่า และ sshd ตอบสนองเฉพาะที่อยู่ภายในของโหนด
เท่านั้น จึงต้องมีโฮสต์อยู่ภายใน VNet; การตรวจสอบที่อยู่ที่คุณรู้จักโหนดนั้นจะรายงานว่าปิดอยู่เสมอ
เหตุใดการแบ่งนี้จึงไม่ใช่เรื่องความชอบ
หัวข้อที่มีชื่อว่า “เหตุใดการแบ่งนี้จึงไม่ใช่เรื่องความชอบ”Debug API ให้บริการโดย F5 Distributed Cloud control plane ซึ่งส่งต่อไปยัง
โหนดผ่านอุโมงค์ที่ vpm สร้างขึ้นระหว่างการลงทะเบียน ไม่มีการลงทะเบียนก็หมายถึง
ไม่มีอุโมงค์ ซึ่งหมายความว่า API ไม่มีอะไรให้ส่งต่อไปถึง
มันล้มเหลวในลักษณะที่ไม่ช่วยอะไรมากกว่าจะชัดเจน ดังนั้นโหนดที่ไม่เคยขึ้นมาเลย จึงดูเหมือนเป็นปัญหาของ API
Serial console ไปในทางตรงกันข้ามโดยสิ้นเชิง — ผ่านแพลตฟอร์ม Azure ไปยัง พอร์ตอนุกรมจำลองของโหนด มันไม่สนใจว่าโหนดได้ลงทะเบียนแล้วหรือไม่ มีการเข้าถึง ทางเครือข่ายหรือไม่ หรือมี data plane ที่ทำงานได้หรือไม่ ความเป็นอิสระนั้นคือประเด็นทั้งหมด และเป็นเหตุผลที่ boot diagnostics ต้องเปิดใช้งานอยู่บน CE VM
ข้อมูลรับรอง
หัวข้อที่มีชื่อว่า “ข้อมูลรับรอง”แต่ละเส้นทางใช้ข้อมูลรับรองที่ต่างกัน และไม่มีอันใดที่ควรอยู่บนบรรทัดคำสั่ง
- Debug API — โทเค็น API ของ F5 Distributed Cloud ในรูป
XCSH_API_TOKENพร้อมกับ URL ของ tenant ในรูปXCSH_API_URLไฟล์บริบทของxcshที่~/.config/xcsh/contexts/<tenant>.jsonเก็บทั้งสองอย่าง ซึ่งเป็นสิ่งที่scripts/capture-sitecli.shอ่านเมื่อสภาพแวดล้อมไม่ได้จัดเตรียมไว้ให้ Tenant ของการติดตั้งนี้คือf5-sales-demo; โทเค็นที่สร้างขึ้นสำหรับ tenant อื่น จะคืนค่า401เปล่า ๆ ซึ่งอ่านดูเหมือนข้อมูลรับรองหมดอายุ - Site Console — ข้อมูลรับรองสองชุด ในคนละชั้น การล็อกอิน Azure แบบโต้ตอบของคุณ
เปิดอุโมงค์ Bastion และบัญชี
adminของแอปพลายแอนซ์เองใช้ลงชื่อเข้าใช้คอนโซล ที่อยู่เบื้องหลังผ่าน HTTP Basic ฝั่ง Azure นั้น Microsoft ระบุว่าต้องการสิทธิ์ Reader บน VM, NIC ของมัน และโฮสต์ Bastion; ข้อกำหนดนั้นไม่ได้รับการตรวจสอบที่นี่ เพราะการทดสอบ ทุกครั้งรันในฐานะเจ้าของ subscription - SSH — ส่วนคีย์ส่วนตัวของคู่คีย์ที่ส่วนสาธารณะถูกเขียนโดยการติดตั้งลงใน
/var/home/admin/.ssh/authorized_keysตั้งแต่การบูตครั้งแรก บวกกับโฮสต์ภายใน VNet เพื่อ เข้าถึงที่อยู่ภายในผ่านทางนั้น เชื่อมต่อในฐานะadminไม่ใช่azureuser - Serial console — การล็อกอิน Azure แบบโต้ตอบของคุณ ไม่มี service principal สำหรับสิ่งนี้: Entra tenant ขององค์กร F5 ไม่อนุญาตให้จัดเตรียมขึ้นมา ซึ่งเป็น เหตุผลว่าทำไมไม่มีส่วนใดของกระบวนการนี้ที่รันใน CI