โฮสต์ Tailscale หนึ่งเครื่องเข้าถึงไม่ได้: เราเตอร์ซับเน็ตหรือโหนดออก

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

เริ่มจากปลายทางที่ล้มเหลว

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

สังเกตกลุ่มที่อยู่ด้วย ซับเน็ตที่ประกาศเป็น IPv4 เท่านั้นจะทิ้งปลายทาง IPv6 ไว้บนเส้นทางภายใน ซึ่งดูเหมือนความล้มเหลวบางส่วนจนกว่าจะมีคนเปรียบเทียบตารางเส้นทางทั้งสอง จดไว้ว่าคุณคาดว่าเส้นทางควรเป็นอย่างไร เพื่อให้การทดสอบมีอะไรโต้แย้งในภายหลัง

เข้าถึงอุปกรณ์ที่ไม่เคยรัน Tailscale

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

tailscale up --advertise-routes=10.40.0.0/24 --advertise-exit-node=false
ip route get 10.40.0.55
tailscale status

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

ความล้มเหลวทั้งสามแบบดูต่างกันในคอนโซลผู้ดูแลระบบ ตรวจสอบตามลำดับแทนการเปลี่ยนทั้งสามพร้อมกัน เพราะการเปลี่ยนครั้งที่สองจะซ่อนว่าอันไหนสำคัญจริง

ส่งทราฟฟิกสาธารณะออกผ่านเครื่องอื่น

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

tailscale up --advertise-exit-node
tailscale up --exit-node=100.101.102.103 --exit-node-allow-lan-access=false
tailscale status --json | grep -i exitnode

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

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

อ่านการแบ่งสามทางเมื่อมีเพียงโฮสต์เดียวที่ล้มเหลว

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

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

ยืนยันเส้นทางที่คุณคิดว่าสร้างไว้

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

ip route get 10.40.0.55
ip -6 route show default
tailscale ping 10.40.0.55

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