Tailscale Serve กับ Funnel: ใครกันแน่ที่เปิดลิงก์ได้จริง

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

Serve ตอบคำถามภายใน tailnet ของคุณ

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

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

Funnel เปลี่ยนผู้เข้าถึงเป็นอินเทอร์เน็ตสาธารณะ

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

Funnel ยังมีข้อจำกัดที่บทช่วยสอนจากเวอร์ชันเก่าอาจไม่กล่าวถึง มันยุติ TLS ด้วยใบรับรองที่ Tailscale ขอมาให้ชื่อนั้น และรองรับเฉพาะพอร์ตรับฟังบางพอร์ต ตามที่ เอกสารของ Funnel อธิบาย หากบริการของคุณคาดหวังโปรโตคอลอื่นที่ไม่ใช่ HTTPS บนพอร์ตใดพอร์ตหนึ่งเหล่านั้น Funnel คือเครื่องมือที่ผิด ไม่ใช่ปริศนาการตั้งค่า

อ่านโหมดจากไคลเอนต์ ไม่ใช่จากพอร์ต

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

tailscale serve status
tailscale funnel status
tailscale status --json | head -40

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

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

ทดสอบกับผู้เข้าถึงที่คุณตั้งใจไว้จริงๆ

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

curl -sI https://host.tailnet-name.ts.net
curl -sI https://host.tailnet-name.ts.net --resolve host.tailnet-name.ts.net:443:203.0.113.10

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

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