Tailscale ปลอดภัยไหม? เจาะลึกระบบความปลอดภัยและ Trust

Tailscale ปลอดภัยหรือไม่? คำตอบโดยสรุป

Tailscale ปลอดภัยหรือไม่? สำหรับส่วนที่คนส่วนใหญ่กังวล คำตอบคือใช่: coordination server ที่รัน tailnet ของคุณไม่เคยเก็บ private key ที่ใช้เข้ารหัสข้อมูลของคุณ ดังนั้นเซิร์ฟเวอร์จึงไม่สามารถอ่านสิ่งที่อุปกรณ์ของคุณส่งถึงกันได้ หน้าความปลอดภัย ของ Tailscale ระบุไว้ชัดเจนว่า: "Private keys จะไม่ถูกส่งออกจากอุปกรณ์ ข้อมูลทั้งหมดจะถูกเข้ารหัสแบบ end-to-end เสมอ" คำถามที่มีประโยชน์กว่าคือคำถามอื่น coordination server ที่ถูกบุกรุกหรือถูกบังคับด้วยคำสั่งทางกฎหมายไม่จำเป็นต้องอ่าน packet ของคุณ แต่เซิร์ฟเวอร์มีอำนาจตัดสินใจว่าอุปกรณ์ของคุณจะเชื่อถือ public key ใด ดังนั้นจึงอาจเพิ่มอุปกรณ์ที่คุณไม่เคยอนุมัติเข้ามาในเครือข่ายได้

นั่นคือรูปแบบความเชื่อมั่น (trust model) ในประโยคเดียว: การเข้ารหัสช่วยปกป้องข้อมูล และ control plane เป็นตัวกำหนดสมาชิก แต่ละส่วนด้านล่างนี้จะระบุถึงฝ่ายที่คุณต้องเชื่อถือ ระบุสิ่งที่ฝ่ายนั้นทำได้จริง และให้การควบคุมที่จำกัดอำนาจของฝ่ายนั้น หากคุณยังใหม่กับผลิตภัณฑ์นี้ ให้เริ่มต้นที่ Tailscale คืออะไรและ mesh ทำงานอย่างไร

Control plane และ data plane แยกออกจากกัน

Tailscale คือ mesh VPN (virtual private network) ที่สร้างขึ้นบนพื้นฐานของ WireGuard ซึ่งเป็นโปรโตคอลเดียวกับที่คุณต้องตั้งค่าด้วยตนเองบน VPS ที่รัน WireGuard ด้วยตัวเอง อุปกรณ์ทุกเครื่องจะสร้างคู่กุญแจ WireGuard ขึ้นมาเองในเครื่อง บทความ วิธีการทำงาน ของ Tailscale เรียก coordination server ว่าเป็น "กล่องรับฝากกุญแจสาธารณะร่วม" และระบุว่า "กุญแจส่วนตัวจะไม่ถูกส่งออกจากโหนดของตนเองโดยเด็ดขาด"

Data plane คือการรับส่งข้อมูลที่เข้ารหัสระหว่างอุปกรณ์ของคุณ ข้อมูลจะเดินทางจากอุปกรณ์เครื่องหนึ่งไปยังอีกเครื่องหนึ่งโดยตรงหากเครือข่ายเอื้ออำนวย ส่วน control plane คือส่วนประกอบอื่นทั้งหมด ได้แก่ อุปกรณ์ใดบ้างที่อยู่ใน tailnet, กุญแจสาธารณะใดเป็นของอุปกรณ์เครื่องไหน, นโยบายการเข้าถึง (access policy), การตั้งค่า DNS และรายการ relay ทั้งหมด Tailscale ดำเนินการ control plane ในรูปแบบบริการแบบ hosted ในขณะที่คุณรัน data plane บนเครื่องของคุณเอง

หากแยกสองส่วนนี้ออกจากกัน คำถามด้านความปลอดภัยทุกข้อในที่นี้จะสามารถหาคำตอบได้ การเข้ารหัสเป็นคุณสมบัติของ data plane ส่วนการเป็นสมาชิกเป็นสิ่งที่ตัดสินใจโดย control plane การเข้ารหัสไม่สามารถบอกคุณได้ว่าใครได้รับอนุญาตให้เป็น peer ในเครือข่าย

เซิร์ฟเวอร์ประสานงานที่ถูกบุกรุกสามารถทำอะไรได้บ้าง?

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

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

มันสามารถเปลี่ยนแปลงสิทธิ์การเข้าถึงของอุปกรณ์คุณได้ นโยบายการเข้าถึง (access policy) ถูกจัดเก็บไว้ใน control plane และถูกแจกจ่ายไปยังโหนดต่างๆ เอกสารทางเทคนิคของ tailnet lock ของ Tailscale ระบุว่า tailnet lock "ไม่ได้ป้องกันไม่ให้ control plane ที่ถูกบุกรุกทำลายการเชื่อมต่อในเครือข่ายของคุณ เช่น การไม่แจกจ่ายกุญแจโหนดใหม่ หรือการแจกจ่ายนโยบายการควบคุมการเข้าถึงที่ปฏิเสธการเชื่อมต่อกับทุกโหนด"

มันสามารถเห็นและบันทึกข้อมูล metadata ของการเชื่อมต่อได้ บันทึกการไหลของเครือข่าย ของ Tailscale ถูกปิดใช้งานโดยค่าเริ่มต้นและมีให้ใช้งานเฉพาะในแผน Premium และ Enterprise เท่านั้น เมื่อผู้ดูแลระบบเปิดใช้งาน บันทึกเหล่านี้จะเก็บข้อมูลสถิติการรับส่งข้อมูลในช่วงเวลา 5 วินาที ได้แก่ โปรโตคอล, ต้นทาง, ปลายทาง, รวมถึงจำนวนแพ็กเก็ตและไบต์ในแต่ละทิศทาง โดยจะบันทึกเฉพาะการเชื่อมต่อที่สำเร็จเท่านั้น และไม่มีการเก็บรายละเอียดเชิงลึกของการเชื่อมต่อแต่ละรายการ เอกสารการบันทึกของ Tailscale ระบุว่าบันทึกเหล่านั้น "ไม่มีข้อมูลเกี่ยวกับการทำงานของไคลเอนต์หรือเนื้อหาของการรับส่งข้อมูลเครือข่ายโดยเด็ดขาด" ดังนั้นหากเปิดใช้งาน flow logs ทาง Tailscale จะทราบว่าอุปกรณ์ใดของคุณสื่อสารกับอุปกรณ์ใดและเมื่อใด แต่จะไม่ทราบว่ามีการสื่อสารเนื้อหาใดบ้าง

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

Identity provider ของคุณคือรากฐานความน่าเชื่อถือของ tailnet

Tailscale ไม่ได้เก็บฐานข้อมูลรหัสผ่านของตนเอง เอกสารระบุไว้อย่างชัดเจนว่าไม่มีรหัสผ่านของ Tailscale โดยการลงชื่อเข้าใช้จะถูกมอบหมายไปยัง identity provider (IdP) ได้แก่ Apple, Google, GitHub, Microsoft, Okta, OneLogin หรือผู้ให้บริการ OpenID Connect อื่นๆ

โปรดทำความเข้าใจว่านี่คือข้อกำหนดด้านความปลอดภัย ผู้ใดก็ตามที่สามารถลงชื่อเข้าใช้บัญชี Google หรือ Microsoft ของคุณได้ ก็สามารถลงชื่อเข้าใช้ tailnet ของคุณได้เช่นกัน การยืนยันตัวตนแบบหลายปัจจัย (MFA) ของคุณจะเป็นไปตามที่ IdP กำหนด และการยกเลิกสิทธิ์การเข้าถึงจะเป็นไปตามกระบวนการของ IdP เมื่อบุคคลนั้นพ้นสภาพ หากบัญชี IdP ถูกฟิชชิง (phished) บัญชี tailnet ก็จะถูกบุกรุกไปด้วย โดยที่ผู้โจมตีไม่จำเป็นต้องโจมตี WireGuard เลย เพียงแค่เพิ่มอุปกรณ์เข้ามาในระบบ ก็จะได้รับสิทธิ์ตามนโยบายที่คุณกำหนดไว้ให้กับผู้ใช้นั้นทันที

มีกลไกควบคุม 2 อย่างที่ขวางกั้นระหว่างบัญชีที่ถูกขโมยกับอุปกรณ์ที่ใช้งานได้จริงภายใน tailnet ของคุณ ได้แก่ การอนุมัติอุปกรณ์ (device approval) และการหมดอายุของคีย์ (key expiry) ส่วน Tailnet lock เป็นกลไกที่ 3 ซึ่งมุ่งเน้นไปที่ control plane แทนที่จะเป็นตัวบัญชีผู้ใช้โดยตรง

การอนุมัติอุปกรณ์: จะไม่มีการเชื่อมต่อจนกว่าจะมีผู้ยืนยัน

เอกสารของ Tailscale อธิบายว่าการอนุมัติอุปกรณ์เป็นฟีเจอร์ที่ "ช่วยให้ผู้ดูแลเครือข่าย Tailscale สามารถตรวจสอบและอนุมัติอุปกรณ์ใหม่ก่อนที่จะเข้าร่วมเครือข่าย Tailscale ของคุณได้" โดยผู้ที่เป็น Owner, Admin หรือ IT admin จะสามารถทำการอนุมัติได้ อุปกรณ์ใหม่จะแสดงป้าย "Needs approval" ในหน้า Machines จนกว่าจะมีผู้ดำเนินการกับอุปกรณ์นั้น

เมื่อเปิดใช้งานฟีเจอร์นี้ สถานการณ์กรณีบัญชีถูกขโมยจะเปลี่ยนไป ผู้โจมตีจะล็อกอินและลงทะเบียนอุปกรณ์ได้สำเร็จ แต่หลังจากนั้นอุปกรณ์จะรอคอยโดยไม่สามารถเข้าถึงทรัพยากรใดๆ ได้ พร้อมกับมีป้ายแจ้งเตือนในคอนโซลผู้ดูแลระบบของคุณว่ามีเครื่องที่คุณไม่รู้จักกำลังขอเข้าร่วมเครือข่าย ระบบอัตโนมัติยังคงทำงานได้ตามปกติเนื่องจาก auth key สามารถกำหนดให้เป็นแบบ pre-approved ได้ในขณะสร้าง และอุปกรณ์สามารถได้รับอนุมัติผ่าน API รวมถึงการใช้ webhook เพื่ออนุมัติอุปกรณ์โดยอัตโนมัติเมื่อผ่านเกณฑ์ที่คุณกำหนด เช่น การมีชื่ออยู่ในทะเบียนอุปกรณ์ภายใน เส้นทางเหล่านี้ทั้งหมดจะข้ามขั้นตอนการตรวจสอบด้วยตนเอง ดังนั้น auth key ที่ได้รับอนุมัติล่วงหน้าหรือกฎการอนุมัติจึงควรได้รับการดูแลอย่างเข้มงวดเช่นเดียวกับการกดปุ่มอนุมัติด้วยตนเอง

Auth keys เป็นอีกช่องทางหนึ่งในการเข้าถึงระบบ จึงควรจัดการเสมือนเป็นข้อมูลประจำตัว (credentials) เอกสารของ Tailscale ระบุไว้อย่างชัดเจนเกี่ยวกับความเสี่ยงว่า: "โปรดระมัดระวังอย่างยิ่งกับการใช้ reusable keys! สิ่งเหล่านี้อาจเป็นอันตรายอย่างมากหากถูกขโมย ควรเก็บไว้ในผลิตภัณฑ์ประเภท key vault ที่ออกแบบมาเพื่อวัตถุประสงค์นี้โดยเฉพาะ" ณ เดือนตุลาคม 2026 ช่วงเวลาหมดอายุของคีย์ที่ระบุไว้ในเอกสารคือ 1 ถึง 90 วัน และหากไม่ได้ระบุวันหมดอายุ ระบบจะตั้งค่าเริ่มต้นไว้ที่ 90 วันซึ่งเป็นค่าสูงสุด ควรเลือกใช้ one-off keys, กำหนดให้เป็น ephemeral สำหรับเครื่องที่มีการใช้งานชั่วคราว และเก็บ reusable key ใดๆ ไว้โดย เข้ารหัสด้วย Ansible Vault หรือเก็บไว้ใน secrets manager แทนการใส่ไว้ใน shell script

การหมดอายุของคีย์: ตัวจับเวลาที่จำกัดความผิดพลาดอื่นทั้งหมด

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

tailscale up --force-reauth

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

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

Tailnet lock: การนำ coordination server ออกจากห่วงโซ่ความเชื่อถือ

Tailnet lock แก้ไขปัญหาเรื่องการลงทะเบียนโดยตรง เอกสาร tailnet lock documentation ของ Tailscale อธิบายกลไกไว้ว่า: "เมื่อโหนดใหม่เข้าร่วม tailnet กุญแจสาธารณะของโหนดนั้นจำเป็นต้องได้รับลายเซ็นจากกุญแจ Tailnet Lock เสียก่อน จากนั้น coordination server จะกระจายกุญแจสาธารณะที่ลงนามแล้วไปยังโหนดอื่นๆ ในเครือข่าย" อุปกรณ์เดิมของคุณจะตรวจสอบลายเซ็นดังกล่าวก่อนที่จะยอมรับโหนดใหม่ ดังนั้นกุญแจโหนดที่ control plane สร้างขึ้นเองโดยพลการจะถูกปฏิเสธ

tailscale lock status
tailscale lock sign nodekey:1abddef1 tlpub:abcdef12

tailscale lock init เป็นคำสั่งสำหรับเปิดใช้งานฟีเจอร์นี้ โดยคุณจะต้องระบุโหนดที่จะทำหน้าที่ลงนามในขณะนั้น ขั้นตอนการเปิดใช้งานผ่าน admin console จะให้คุณเลือกโหนดสำหรับลงนามอย่างน้อย 2 โหนด ในขณะที่คู่มือ CLI ของ Tailscale แสดงการใช้ tailscale lock init ร่วมกับกุญแจที่เชื่อถือได้เพียงกุญแจเดียว ซึ่งต้องรวมถึงกุญแจของโหนดที่คุณกำลังรันคำสั่งนั้นอยู่ด้วย tailnet หนึ่งเครือข่ายสามารถมีโหนดสำหรับลงนามได้สูงสุด 20 โหนด หลังจากนั้น อุปกรณ์ใหม่ทุกเครื่องจำเป็นต้องได้รับลายเซ็นจากหนึ่งในโหนดเหล่านี้ ซึ่งถือเป็นภาระในการปฏิบัติงานจริง เช่น การเพิ่มโทรศัพท์เครื่องใหม่หมายถึงคุณต้องรันคำสั่งบนแล็ปท็อป

ข้อจำกัดต่างๆ ได้รับการระบุไว้ในเอกสาร และมีความสำคัญมากกว่าคำอธิบายฟีเจอร์:

• หากทำ disablement secret หาย จะไม่มีทางกู้คืนได้ เอกสารระบุว่า "หากคุณทำ disablement secret หาย และไม่ได้มอบสำเนาให้ฝ่ายสนับสนุนของ Tailscale ไว้ tailnet จะไม่สามารถกู้คืนได้"
• กุญแจสำหรับลงนามจะถูกเก็บไว้ในอุปกรณ์ที่คุณเป็นเจ้าของ ดังนั้นความปลอดภัยของกุญแจจึงขึ้นอยู่กับความปลอดภัยของอุปกรณ์นั้น เอกสารระบุไว้อย่างชัดเจนว่า: "หากอุปกรณ์ถูกบุกรุก กุญแจอาจถูกขโมยไปได้"
• คุณไม่สามารถใช้งานทั้งสองระบบพร้อมกันได้ Tailscale ระบุว่า tailnet lock และ device approval ไม่สามารถใช้งานร่วมกันได้ ดังนั้นการเปิดใช้งานอย่างหนึ่งหมายถึงการต้องยกเลิกอีกอย่างหนึ่ง
• เป็นระบบความเชื่อถือเมื่อใช้งานครั้งแรก (TOFU) การตั้งค่าเริ่มต้นยังคงต้องผ่าน control plane และจุดยึดเหนี่ยวของความเชื่อถือจะย้ายมาอยู่ในเครือข่ายของคุณเองหลังจากขั้นตอนแรกนั้นเสร็จสิ้นแล้วเท่านั้น

Tailnet lock ช่วยปกป้องสถานะการเป็นสมาชิก แต่ไม่ได้ปกป้องความพร้อมใช้งานของระบบ ซึ่งระบุไว้ชัดเจนในเอกสาร white paper

การเชื่อมต่อแบบ relay ทำให้ข้อมูลของฉันถูกเปิดเผยหรือไม่?

ไม่ ข้อมูลจะไม่ถูกเปิดเผย ในกรณีที่อุปกรณ์สองเครื่องไม่สามารถเชื่อมต่อกันโดยตรงได้ ข้อมูลจะถูกส่งผ่าน DERP server (Designated Encrypted Relay for Packets) เอกสารของ Tailscale ระบุคุณสมบัตินี้ไว้อย่างชัดเจนว่า "เนื่องจาก private key ของ Tailscale ไม่เคยออกจากอุปกรณ์ต้นทางที่สร้างมันขึ้นมา DERP server จึงไม่สามารถถอดรหัสข้อมูลของคุณได้ DERP server ทำหน้าที่เพียงส่งต่อข้อมูลที่ถูกเข้ารหัสไว้แล้วจากอุปกรณ์หนึ่งไปยังอีกอุปกรณ์หนึ่งเท่านั้น"

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

tailscale status
tailscale netcheck

tailscale status จะระบุประเภทการเชื่อมต่อเฉพาะสำหรับ peer ที่มีการใช้งานอยู่เท่านั้น peer ที่มีการใช้งานจะแสดงผลเป็น direct ตามด้วยที่อยู่ที่เชื่อมต่อได้ เช่น direct 203.0.113.10:41641 หรือแสดงเป็น relay ตามด้วยชื่อ relay ในเครื่องหมายคำพูด เช่น relay "fra" หรือแสดงเป็น peer-relay ตามด้วยที่อยู่ของ peer relay พร้อมตัวนับไบต์ tx และ rx หลังจากที่มีการรับส่งข้อมูลแล้ว สำหรับ peer ที่ไม่มีการใช้งานจะแสดงเป็น idle, offline หรือเพียงแค่ - โดยไม่มีการระบุว่าเป็น direct หรือ relay ดังนั้นควรส่งข้อมูลทดสอบก่อนอ่านค่าดังกล่าว หาก peer ยังคงเชื่อมต่อผ่าน relay แสดงว่าปลายทางทั้งสองไม่สามารถสร้างเส้นทางตรงได้ ซึ่งมักเกิดจาก UDP ถูกบล็อกในบางจุด หรือทั้งสองฝั่งอยู่หลัง NAT (network address translation) ที่เข้มงวด tailscale netcheck จะรายงานว่า UDP สามารถใช้งานได้จากเครื่องนั้นหรือไม่, NAT ของคุณมีการแมปพอร์ตอย่างไร และค่า latency ไปยัง relay ที่ใกล้ที่สุด ซึ่งจะช่วยให้คุณทราบสาเหตุของปัญหา การทำ NAT traversal แบบเดียวกันนี้เองที่เลือกระหว่างเส้นทางตรงกับ relay ซึ่งเป็นเหตุผลว่าทำไม NAS ที่บ้านหรือ Raspberry Pi จึงไม่จำเป็นต้องเปิดพอร์ตที่ router และ การใช้ Tailscale แทนการทำ port forwarding จะอธิบายขั้นตอนการทำงานและข้อจำกัดของวิธีนี้ หาก peer เชื่อมต่อแบบ direct อยู่แล้วแต่ความเร็วยังไม่เป็นที่น่าพอใจ แสดงว่าปัญหาไม่ได้เกิดจาก relay และ ปัญหา path MTU ไม่ตรงกันมักเป็นสาเหตุหลักที่ทำให้ WireGuard ทำงานช้า

Exit node เป็นเพียงการย้ายจุดออกสู่สาธารณะ ไม่ใช่การลบจุดดังกล่าวทิ้ง

Exit node จะทำหน้าที่ส่งผ่าน traffic อินเทอร์เน็ตสาธารณะทั้งหมดของอุปกรณ์ผ่านอุปกรณ์อีกเครื่องหนึ่งบน tailnet โดยใช้ default route คือ 0.0.0.0/0 และ ::/0 สำหรับบน Linux เครื่องที่ให้บริการจะเป็นผู้ประกาศ (advertise) บริการนี้ และไคลเอนต์แต่ละเครื่องจะเป็นผู้เลือกใช้งานเอง:

sudo tailscale set --advertise-exit-node
sudo tailscale set --exit-node=100.101.102.103
sudo tailscale set --exit-node=100.101.102.103 --exit-node-allow-lan-access=true
sudo tailscale set --exit-node=

Exit node จะต้องได้รับการอนุมัติจาก Owner, Admin หรือ Network admin ใน admin console ก่อนที่ใครจะสามารถส่ง traffic ผ่านได้ เว้นแต่ว่านโยบายของคุณจะระบุผู้ใช้ที่ยืนยันตัวตนอุปกรณ์นั้นไว้ใน autoApprovers สำหรับ exit node ซึ่งในกรณีนี้จะได้รับการอนุมัติโดยอัตโนมัติ เมื่อได้รับการอนุมัติแล้ว เอกสารประกอบเรื่อง exit node ของ Tailscale ระบุว่าโดยค่าเริ่มต้น ผู้ใช้ทุกคนใน tailnet ของคุณสามารถใช้งานได้โดยไม่ต้องมี grant หรือ ACL ใดๆ แต่สถานะนี้จะเปลี่ยนไปทันทีที่คุณปรับแต่งนโยบายการควบคุมการเข้าถึง (access control policy) หลังจากนั้นไคลเอนต์จะสามารถใช้ exit node ได้ก็ต่อเมื่อมี grant หรือ ACL ที่ระบุ autogroup:internet ไว้ในส่วน dst เท่านั้น ขั้นตอนการอนุมัติถูกออกแบบมาอย่างตั้งใจ เพื่อป้องกันไม่ให้อุปกรณ์ที่ไม่ได้รับอนุญาตกลายเป็นทางออกของทั้ง tailnet โดยที่คุณไม่รู้ตัว ดังนั้นให้ถือว่าทุกรายการใน autoApprovers คือการตอบตกลงจากผู้ดูแลระบบ ประตูการอนุมัตินี้ยังครอบคลุมถึง subnet route ด้วย ดังนั้นเครื่องที่ประกาศ private range จะยังคงทำงานไม่ได้จนกว่าผู้ดูแลระบบจะยอมรับ ซึ่งถือเป็นด่านแรกใน การประกาศ private network ไปยัง tailnet จาก VPS

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

นโยบายเริ่มต้นคือเครือข่ายแบบแบน (flat network)

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

คุณควรจำกัดสิทธิ์ในไฟล์นโยบายของ tailnet ซึ่งรองรับรายการควบคุมการเข้าถึง (ACLs) หรือระบบ grants แบบใหม่ ทั้งสองแบบเขียนด้วยภาษา JSON ที่อนุญาตให้ใส่คำอธิบายได้:

{
  "acls": [
    {"action": "accept", "src": ["group:eng"], "dst": ["tag:prod:22"]},
    {"action": "accept", "src": ["autogroup:member"], "dst": ["autogroup:internet:*"]}
  ]
}

นโยบายดังกล่าวอนุญาตให้กลุ่มหนึ่งเข้าถึง SSH บนเซิร์ฟเวอร์ที่ใช้งานจริง (production) อนุญาตให้สมาชิกใช้ exit node และปฏิเสธการเข้าถึงอื่นทั้งหมดโดยปริยาย Tailscale มีรายการระบุว่าเป้าหมายของกฎใดบ้างที่สามารถใช้งานได้ในแต่ละแผนบริการ ดังนั้นควรตรวจสอบข้อมูลดังกล่าวก่อนที่คุณจะออกแบบโดยใช้ tags หรือ autogroups และดู สิ่งที่แผนบริการฟรีครอบคลุมจริง สำหรับอุปกรณ์ที่ไม่ควรยอมรับการเชื่อมต่อขาเข้าเลย เช่น โทรศัพท์ส่วนตัว tailscale set --shields-up จะทำหน้าที่บล็อกการเชื่อมต่อเหล่านั้นที่ตัวไคลเอนต์เอง

การเปลี่ยนมา self-host control plane ด้วย Headscale มีผลอย่างไร

Headscale คือ "การนำ control server ของ Tailscale มาทำ self-hosted ในรูปแบบ open source" ไฟล์ README ของโครงการระบุขอบเขตไว้อย่างชัดเจนว่า "รองรับขอบเขตที่จำกัด โดยรองรับ Tailscale network (tailnet) เพียง หนึ่ง เครือข่าย ซึ่งเหมาะสำหรับการใช้งานส่วนตัวหรือองค์กร open source ขนาดเล็ก" รายการฟีเจอร์ครอบคลุมถึง ACL และ grants, subnet routers, exit nodes, DERP server ในตัว, Tailscale SSH และ Taildrop หากข้อจำกัดด้านขอบเขตนี้เป็นประเด็นสำคัญ NetBird เป็นอีกหนึ่ง mesh ที่มี control plane แบบ self-hostable ให้ใช้งาน และการ รัน NetBird server บน VPS ของคุณเอง จะเปลี่ยนการตัดสินใจเรื่องการลงทะเบียนอุปกรณ์มาอยู่บนฮาร์ดแวร์ที่คุณเป็นเจ้าของแทน

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

สิ่งที่ยังคงเดิมคือ data plane ซึ่งยังคงเป็น WireGuard ที่มีการเข้ารหัสแบบ end-to-end เหมือนเดิม รวมถึงการใช้ relay fallback ในกรณีที่ไม่สามารถเชื่อมต่อโดยตรงได้ นอกจากนี้ คุณยังต้องรับหน้าที่ที่เดิม Tailscale เคยดูแลให้ ได้แก่ การรักษา uptime, การแพตช์ระบบ, การสำรองข้อมูล และความปลอดภัยทางกายภาพของเครื่อง หากเครื่องนั้นเป็น VPS ที่เช่ามา ความปลอดภัยทางกายภาพจะเป็นเพียงคำสัญญาของผู้อื่น ไม่ใช่สิ่งที่คุณควบคุมได้ เนื่องจาก hypervisor สามารถอ่านหน่วยความจำของ guest และเข้าถึงไดเรกทอรีของคีย์ได้ เว้นแต่ฮาร์ดแวร์จะรองรับ encrypted memory ที่คุณสามารถตรวจสอบได้ หากโฮสต์ที่รัน Headscale ถูกบุกรุก ผู้โจมตีจะได้รับสิทธิ์เช่นเดียวกับที่ได้จากการบุกรุก coordination server ซึ่งก็คืออำนาจในการลงทะเบียนโหนดและแจกจ่ายนโยบาย ฟีเจอร์ Tailnet lock ยังไม่อยู่ในรายการฟีเจอร์ของ Headscale ดังนั้นการควบคุมเพื่อชดเชยความเสี่ยงเฉพาะส่วนนี้จึงยังไม่สามารถทำได้ ในด้านต้นทุนก็เป็นปัจจัยที่ทำให้หลาย tailnet เปลี่ยนมาใช้แนวทางนี้ เนื่องจาก Tailscale คิดค่าบริการรายผู้ใช้ไม่ใช่รายอุปกรณ์ ซึ่งตัวเลขค่าใช้จ่ายจะเปลี่ยนไปทันทีเมื่อทีมขนาดเล็กมีจำนวนสมาชิกเกินกว่าแผนฟรี หากคำถามเรื่องความเป็นเจ้าของคือปัจจัยตัดสินใจของคุณ การ self-host control plane ด้วย Headscale จะอธิบายขั้นตอนการติดตั้งไว้ให้คุณแล้ว

สิ่งที่ Tailscale ป้องกันได้

• พอร์ตที่เปิดรับการเชื่อมต่อจากสาธารณะ บริการที่ผูกอยู่กับที่อยู่ tailnet จะไม่สามารถเข้าถึงได้จากอินเทอร์เน็ต ดังนั้นเครื่องมือสแกนที่พยายามเข้าถึงทุก VPS ผ่านพอร์ต 22 จะไม่พบบริการเหล่านี้ ข้อยกเว้นคือกรณีที่คุณเปิดใช้งานด้วยตนเอง เนื่องจาก Funnel จะเผยแพร่บริการใน tailnet ออกสู่สาธารณะโดยเจตนา ซึ่งเป็นเหตุผลว่าทำไมจึงควรทำความเข้าใจ จุดสิ้นสุดของ serve และจุดเริ่มต้นของ funnel ก่อนที่จะรันคำสั่งใดคำสั่งหนึ่ง อย่างไรก็ตาม ควรเปิดใช้งาน host firewall ไว้เสมอ เพราะพอร์ตของ Docker ที่ถูกเผยแพร่จะเขียนกฎของตัวเองและ ข้ามการทำงานของ ufw บนอินเทอร์เฟซสาธารณะ
• การเดารหัสผ่านกับหน้าล็อกอินที่เปิดเผย จะไม่มีเป้าหมายให้โจมตีด้วยวิธี brute force หากพอร์ตนั้นตอบสนองเฉพาะภายในอุโมงค์เท่านั้น ซึ่งเป็นสถานะที่ปลอดภัยกว่าการจำกัดอัตราการเข้าถึง (rate limiting) บนพอร์ตที่เปิดสาธารณะ แม้ว่า fail2ban บน Ubuntu 24.04 จะยังคงเป็นสิ่งที่ควรติดตั้งไว้บนบริการใดก็ตามที่จำเป็นต้องเปิดใช้งานต่อสาธารณะ
• เครือข่ายที่ไม่น่าเชื่อถือระหว่างทาง การรับส่งข้อมูลระหว่างเครื่องของคุณจะถูกเข้ารหัสแบบ end-to-end แม้จะผ่านเครือข่าย Wi-Fi สาธารณะหรือ LAN ของผู้ให้บริการที่ใช้ร่วมกัน และข้อมูลจะยังคงถูกเข้ารหัสในขณะที่ถูกส่งผ่าน relay
• การจัดการแจกจ่ายคีย์ด้วยตนเอง ทุก peer ที่เพิ่มเข้าไปในไฟล์ config ของ WireGuard ด้วยตนเองมีความเสี่ยงที่จะเกิดการใช้ที่อยู่ซ้ำหรือการวางคีย์ผิดพลาด ระบบ mesh จะจัดการงานเอกสารเหล่านี้ให้คุณ ซึ่งเป็นความแตกต่างในทางปฏิบัติส่วนใหญ่ระหว่าง WireGuard กับ Tailscale

สิ่งที่ Tailscale ไม่สามารถป้องกันได้

• อุปกรณ์ปลายทางที่ถูกบุกรุก tailnet จะเชื่อถืออุปกรณ์ที่ได้รับอนุญาต หากมีมัลแวร์บนแล็ปท็อปที่ได้รับอนุญาต มัลแวร์นั้นจะสามารถเข้าถึงอุโมงค์เชื่อมต่อ, ที่อยู่ภายใน tailnet และสิทธิ์ทุกอย่างที่นโยบายของคุณมอบให้ผู้ใช้นั้น นี่คือช่องโหว่ที่ใหญ่ที่สุด และไม่มี VPN ใดที่สามารถปิดช่องโหว่นี้ได้
• ผู้ดูแลระบบที่ประสงค์ร้ายหรือประมาทเลินเล่อ ใครก็ตามที่สามารถแก้ไขไฟล์นโยบายได้จะสามารถมอบสิทธิ์การเข้าถึงทุกอย่างให้ตนเอง และใครก็ตามที่สามารถยึดบัญชีผู้ใช้งานที่เป็นเจ้าของ (Owner) ได้ก็จะทำเช่นเดียวกัน ควรตรวจสอบการเปลี่ยนแปลงนโยบายในลักษณะเดียวกับที่คุณตรวจสอบโค้ด
• การวิเคราะห์ทราฟฟิก ISP (ผู้ให้บริการอินเทอร์เน็ต) ของคุณจะเห็นข้อมูล UDP ที่เข้ารหัสไหลไปยังปลายทาง รวมถึงเวลาและปริมาณข้อมูล ส่วน flow logs ของ Tailscale ในกรณีที่ผู้ดูแลระบบเปิดใช้งานไว้ จะบันทึกว่า peer ใดมีการแลกเปลี่ยนทราฟฟิกกันและเมื่อใด ทั้งสองกรณีไม่สามารถเห็นเนื้อหาภายในได้ แต่การเชื่อมต่อที่เกิดขึ้นนั้นไม่ได้ถูกซ่อนไว้ ดังนั้นโปรดอ่าน ความแตกต่างระหว่าง Tor และ VPN ก่อนเลือกใช้เครื่องมือสำหรับงานดังกล่าว
• อุปกรณ์ที่คุณทำหายไปแล้ว การหมดอายุของคีย์ (Key expiry) เป็นมาตรการป้องกันสำรองที่ค่อนข้างช้าโดยมีค่าเริ่มต้นอยู่ที่ 180 วัน การลบอุปกรณ์ออกจาก admin console เป็นวิธีที่รวดเร็วกว่า ดังนั้นควรทราบตำแหน่งของปุ่มดังกล่าวไว้ก่อนที่คุณจะจำเป็นต้องใช้งานจริง

ตรวจสอบ Tailnet ของคุณเอง

1. รัน tailscale status บนอุปกรณ์เพื่ออ่านรายการ peer อุปกรณ์ที่คุณไม่รู้จักคือสถานการณ์ที่ฟีเจอร์การอนุมัติอุปกรณ์ (device approval) มีไว้เพื่อป้องกัน
2. รัน tailscale lock status เพื่อดูว่า tailnet lock ถูกเปิดใช้งานอยู่หรือไม่ จากนั้นตัดสินใจว่าความยุ่งยากในการลงนามอุปกรณ์ใหม่ทุกครั้งนั้นคุ้มค่าสำหรับ tailnet ของคุณหรือไม่
3. เปิด admin console แล้วจดบันทึกทุกเครื่องที่ปิดการหมดอายุของคีย์ (key expiry) รวมถึง auth key แบบใช้ซ้ำได้ที่ยังคงมีอยู่ ทั้งสองอย่างนี้คือข้อมูลรับรองที่ไม่มีการจำกัดเวลา
4. อ่านไฟล์นโยบาย (policy file) ของคุณ หากยังคงเป็นค่าเริ่มต้น อุปกรณ์ทุกเครื่องจะสามารถเข้าถึงอุปกรณ์อื่นได้ทุกพอร์ต ซึ่งหมายความว่าหากแล็ปท็อปเครื่องหนึ่งติดไวรัส มันจะเข้าถึงอุปกรณ์ทั้งหมดได้

Tailscale สร้างชื่อเสียงจาก data plane ซึ่งการออกแบบไม่เปิดช่องให้ผู้ให้บริการอ่านข้อมูลการรับส่งของคุณได้ ให้ถือว่าคำกล่าวอ้างนั้นเป็นไปตามเอกสารของผู้ผลิต จากนั้นให้ตรวจสอบในส่วนที่เป็นของคุณเอง ได้แก่ บัญชีผู้ใช้งาน, การตั้งค่าการอนุมัติ, รายการการหมดอายุ และไฟล์นโยบาย หน้าความปลอดภัยของ Tailscale ระบุถึงการรับรอง SOC 2 Type II และการทำงานด้านความปลอดภัยอย่างต่อเนื่องร่วมกับ Latacora ซึ่งเป็นหลักฐานเกี่ยวกับกระบวนการของพวกเขา ไม่ใช่การยืนยันเกี่ยวกับการตั้งค่าของคุณเอง

FAQ

Tailscale สามารถอ่านข้อมูลการรับส่งข้อมูลของฉันได้หรือไม่?

ไม่ได้ ข้อมูลจะถูกเข้ารหัสด้วยกุญแจ WireGuard ที่สร้างขึ้นบนอุปกรณ์ของคุณเอง โดยหน้าความปลอดภัยของ Tailscale ระบุว่า "กุญแจส่วนตัว (Private keys) จะไม่ถูกส่งออกจากอุปกรณ์ ข้อมูลทั้งหมดจะถูกเข้ารหัสแบบ end-to-end เสมอ" หลักการนี้ยังครอบคลุมถึงการเชื่อมต่อที่ต้องอาศัย DERP relay เนื่องจาก relay จะ "ส่งต่อข้อมูลที่ถูกเข้ารหัสไว้แล้วจากอุปกรณ์หนึ่งไปยังอีกอุปกรณ์หนึ่งโดยไม่ทราบเนื้อหา" และไม่มีกุญแจใดที่จะใช้ถอดรหัสข้อมูลได้ สิ่งที่โครงสร้างพื้นฐานของ Tailscale มองเห็นคือข้อมูลเมตา (metadata) เช่น อุปกรณ์ใดบ้างที่มีอยู่ในระบบ และหากเปิดใช้งาน network flow logs จะทราบว่าอุปกรณ์ใดรับส่งข้อมูลกับอุปกรณ์ใดและเมื่อใด

หากเซิร์ฟเวอร์ coordination ของ Tailscale ถูกบุกรุก จะเกิดอะไรขึ้นได้บ้าง?

ผู้โจมตีสามารถเพิ่มโหนด (node) เข้าสู่ระบบได้ ประกาศเรื่อง tailnet lock ของ Tailscale ระบุถึงความเสี่ยงของการเพิ่มโหนดโดยไม่ได้รับอนุญาต ซึ่งอาจ "ส่งหรือรับข้อมูลไปยังโหนดเดิมของคุณได้" โดยการเข้ารหัสจะไม่ช่วยป้องกันในกรณีนี้ "เนื่องจากตัวโหนดปลายทางเองนั้นเป็นอันตราย" นอกจากนี้ หาก control plane ถูกบุกรุก ผู้โจมตีอาจแจกจ่ายนโยบายที่เปลี่ยนเส้นทางการเข้าถึงของอุปกรณ์คุณได้ และเอกสาร white paper ของ tailnet lock ยังระบุว่าอาจทำให้การเชื่อมต่อล้มเหลวโดยการไม่แจกจ่ายกุญแจโหนดใหม่ อย่างไรก็ตาม ผู้โจมตีไม่สามารถถอดรหัสข้อมูลระหว่างอุปกรณ์เดิมของคุณได้ เนื่องจากเซิร์ฟเวอร์ไม่เคยถือครองกุญแจส่วนตัวของอุปกรณ์เหล่านั้น

exit node ช่วยซ่อนประวัติการเข้าชมจาก ISP ของฉันได้หรือไม่?

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

Headscale ปลอดภัยกว่าเซิร์ฟเวอร์ coordination ของ Tailscale หรือไม่?

เป็นการตัดสินใจเรื่องความไว้วางใจที่แตกต่างกัน ไม่ใช่การเพิ่มความปลอดภัยโดยตรง ในกรณีของ Headscale คุณเป็นผู้ถือครองไดเรกทอรีของกุญแจและนโยบายต่างๆ ทำให้ไม่มีบุคคลภายนอกสามารถบังคับเพิ่มอุปกรณ์เข้าสู่ tailnet ของคุณได้ แต่คุณต้องรับผิดชอบการดูแลเซิร์ฟเวอร์เองทั้งหมด ทั้งการแพตช์ซอฟต์แวร์, การรักษา uptime, การสำรองข้อมูล และความปลอดภัยของโฮสต์ หากโฮสต์ที่รัน Headscale ถูกบุกรุก ผู้โจมตีจะมีอำนาจในการเพิ่มโหนดเช่นเดียวกับกรณีเซิร์ฟเวอร์ coordination ถูกบุกรุก และเนื่องจาก tailnet lock ยังไม่มีในรายการฟีเจอร์ของ Headscale คุณจึงต้องปกป้องโฮสต์นั้นให้ดี

ฉันยังจำเป็นต้องใช้ไฟร์วอลล์บน VPS ที่อยู่ใน tailnet หรือไม่?

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