ทำไมเส้นทางซับเน็ตของ Tailscale ที่อนุมัติแล้วยังหมดเวลา

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

สี่ขั้นตอน หนึ่งความล้มเหลว

เราเตอร์ประกาศพรีฟิกซ์ tailnet อนุมัติประกาศนั้น ไคลเอนต์ยอมรับเส้นทางที่ได้รับ และนโยบายการเข้าถึงอนุญาตการเชื่อมต่อที่ระบุ นี่คือสี่การตัดสินใจแยกกันจากสามองค์ประกอบที่ต่างกัน ดังนั้นเส้นทางที่อนุมัติแล้วบอกเพียงว่าเครือข่ายเป็นส่วนหนึ่งของตารางเส้นทางของ tailnet แล้ว

ขั้นตอนที่สี่ถูกละเลยบ่อยที่สุด เพราะสามขั้นตอนแรกให้สถานะที่มองเห็นได้ การอนุญาตที่ครอบคลุมที่อยู่ tailnet ของเราเตอร์เองไม่ได้ครอบคลุมซับเน็ตส่วนตัวที่อยู่ข้างหลังโดยอัตโนมัติ สิ่งเหล่านี้เป็นปลายทางที่ต่างกัน และนโยบายถูกประเมินแยกตามปลายทาง

บน Linux ขั้นตอนที่สามยังมีค่าเริ่มต้นที่ทำให้คนประหลาดใจ: การยอมรับเส้นทางซับเน็ตเป็นทางเลือก ไคลเอนต์ GUI หลายตัวยอมรับเส้นทางที่ประกาศตามค่าเริ่มต้น ดังนั้นฟลีตแบบผสมอาจแสดงเครื่องหนึ่งล้มเหลวในขณะที่เครื่องอื่นทำงาน

ยืนยันการตั้งค่าบนเครื่องที่ล้มเหลวแทนการเดาแพลตฟอร์ม เครื่องที่ทำงานไม่เคยขาดเส้นทาง ดังนั้นให้เครื่องเหล่านั้นพิสูจน์ว่าฝั่ง tailnet สมบูรณ์ เอกสารของ Tailscale เกี่ยวกับเราเตอร์ซับเน็ตครอบคลุมการอนุมัติ การยอมรับเส้นทางของไคลเอนต์ และขั้นตอนนโยบาย

ตรวจสอบเส้นทางที่ไคลเอนต์ทำงานอยู่

เริ่มจากไคลเอนต์ที่ล้มเหลว ไม่ใช่เราเตอร์ ยืนยันว่าเส้นทางมีอยู่และการตั้งค่าไคลเอนต์อนุญาตให้ยอมรับเส้นทาง

tailscale status
tailscale debug prefs | grep -i route
ip route get 10.20.0.42

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

การยอมรับเส้นทางบน Linux ให้เชื่อมต่อใหม่พร้อมแฟล็กแทนการสมมติว่าตั้งไว้แล้ว: tailscale up --accept-routes ไคลเอนต์ที่เข้าร่วมด้วยแฟล็กอื่นจะเก็บไว้จนกว่าจะเปลี่ยน ดังนั้นตรวจสอบการตั้งค่าปัจจุบันก่อนเพิ่มอีกอัน การรันคำสั่งแรกซ้ำหลังการเปลี่ยนแปลงควรแสดงเส้นทางในตาราง

พิสูจน์การส่งต่อและเส้นทางขากลับ

การอนุมัติไม่ได้กำหนดค่าเราเตอร์ให้ส่งต่อแพ็กเก็ต และไม่ได้จัดการคำตอบ ทั้งสองเป็นเรื่องระดับโฮสต์ที่ฝั่ง LAN ของเราเตอร์ ทดสอบบนเราเตอร์ ไม่ใช่บนไคลเอนต์

sysctl net.ipv4.ip_forward
iptables -t nat -L POSTROUTING -n -v
tcpdump -ni any host 10.20.0.42 and port 443

คำสั่งแรกต้องรายงาน 1 มิฉะนั้นเคอร์เนลจะทิ้งแพ็กเก็ตที่ส่งต่อ คำสั่งที่สองแสดงว่าการมาสคาเรดเส้นทางซับเน็ตเขียนแหล่งที่มาใหม่หรือไม่ ซึ่งเป็นพฤติกรรมเริ่มต้นและมักเป็นสิ่งที่คุณต้องการ คำสั่งที่สามแสดงว่าคำขอไปถึงปลายทางและมีอะไรกลับมาหรือไม่ คำขอที่ไม่มีการตอบกลับเป็นปัญหาเส้นทางขากลับ ไม่ใช่ปัญหาการอนุมัติ อ่านผลลัพธ์ทั้งสามพร้อมกันก่อนเปลี่ยนสิ่งใด

หากปิดการมาสคาเรด เครือข่ายปลายทางต้องมีเส้นทางกลับไปยังที่อยู่ของ tailnet และทุกฮอประหว่างทางต้องรู้ การเปิดมาสคาเรดอีกครั้งเป็นการแก้ไขที่เร็วที่สุดสำหรับบริการเดียว แต่แลกกับการซ่อนที่อยู่เดิมของไคลเอนต์จากปลายทาง การแลกเปลี่ยนนี้สำคัญเมื่อปลายทางบันทึกที่อยู่ต้นทางเพื่อการตรวจสอบ ดังนั้นตัดสินใจอย่างรอบคอบแทนการพลิกแฟล็กระหว่างเหตุการณ์ บันทึกว่าคุณเลือกทางใด เพราะคนถัดไปจะเห็นเพียงหนึ่งในสองพฤติกรรม

อ่านกฎการเข้าถึงสำหรับทรัพยากร

เมื่อมีเส้นทางและพิสูจน์การส่งต่อแล้ว ผู้ต้องสงสัยที่เหลือคือนโยบาย อ่านการอนุญาตที่ควรอนุญาตการเชื่อมต่อและตรวจสอบปลายทาง ไม่ใช่แค่แหล่งที่มา ตัวตนของไคลเอนต์เองก็ต้องตรงกับตัวเลือกของนโยบาย ดังนั้นบันทึกจากเครื่องเดียวกันที่ล้มเหลว

tailscale status --json | head -40
tailscale ping <router-name-or-tailnet-ip>
ping -c 3 10.20.0.42

ผลลัพธ์สถานะระบุที่อยู่ของไคลเอนต์เองและเพียร์ที่มองเห็น และตัวเลือกแหล่งที่มาของนโยบายต้องตรงกับสิ่งเหล่านี้ tailscale ping พิสูจน์เส้นทาง tailnet ถึงเราเตอร์ซับเน็ตเอง มันแก้ชื่อเพียร์และที่อยู่ tailnet ไม่ใช่โฮสต์ภายในซับเน็ตที่ประกาศ คำสั่งที่สามส่ง ICMP echo ปกติผ่านเส้นทางซับเน็ต ผลลัพธ์จึงอธิบายปลายทางไม่ใช่เราเตอร์ การปฏิเสธระดับ tailnet มักกลับมาเป็นการปฏิเสธ ในขณะที่แพ็กเก็ตที่ออกไปและไม่กลับมาเลยจะหมดเวลา

ชื่อที่ล้มเหลวเป็นคำถามต่างจากที่อยู่ที่ล้มเหลว แก้ไขโฮสต์โดยตรงก่อนโทษเส้นทาง เขียนการอนุญาตตามความต้องการจริงของทรัพยากร ไม่ใช่ทั้งซับเน็ต การเปิด /24 ทั้งหมดเพื่อให้แอปพลิเคชันหนึ่งทำงานคือทางที่คำขอแคบกลายเป็นการอนุญาตกว้างที่ภายหลังไม่มีใครกล้าถอดออก

หากเป้าหมายคือทางออกสู่อินเทอร์เน็ตไม่ใช่ซับเน็ตส่วนตัว องค์ประกอบที่ถูกต้องคือโหนดทางออก ไม่ใช่เราเตอร์ซับเน็ต และนโยบายกับการกำหนดเส้นทางแตกต่างกันตามนั้น ตรวจสอบการตัดสินใจนั้นก่อนขยายการอนุญาต โหนดทางออกเปลี่ยนเส้นทางเริ่มต้น เราเตอร์ซับเน็ตเพียงประกาศพรีฟิกซ์