เชื่อม AI สองตัวข้ามเครื่อง
โดยไม่เปิด firewall สักช่อง

ช่วงที่ 1ที่มา คืนที่เน็ตหายทั้งเครื่อง

เรามีผู้ช่วย AI สองตัว ตัวหนึ่งรันอยู่บนเครื่อง Mac ที่บ้าน อีกตัวรันอยู่บนเซิร์ฟเวอร์ในคลาวด์ (เครื่องที่เปิดทิ้งไว้ตลอดบนอินเทอร์เน็ต) อยากให้สองตัวนี้คุยกันได้ ให้ตัวบน Mac เป็นคนสั่งงานอีกตัวบนคลาวด์

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

ช่วงที่ 2ปูพื้น ทำไมการให้เครื่องสองเครื่อง "คุยกัน" ถึงไม่ง่าย

ลองคิดว่าเครื่องคอมพิวเตอร์แต่ละเครื่องเหมือนโทรศัพท์ จะคุยกันได้ ฝ่ายที่รับสายต้องมี "เบอร์" ที่อีกฝ่ายกดถึง

ปัญหาคือเครื่องที่บ้านหรือมือถือเราส่วนใหญ่ โทรออกได้ แต่ไม่มีเบอร์ให้คนอื่นโทรเข้า เหมือนอยู่ในคอนโดที่มีเบอร์กลางตัวเดียว เราโทรออกไปข้างนอกได้สบาย แต่คนข้างนอกจะโทรเข้ามาหาห้องเราตรงๆ ไม่ได้ ในทางเทคนิคเรียกอาการนี้ว่าอยู่หลัง NAT

ส่วนเครื่องคลาวด์ต่างออกไป มี "เบอร์" สาธารณะของตัวเอง ใครจะวิ่งเข้ามาก็ได้ แต่ตรงนี้แหละที่เป็นดาบสองคม เพราะเครื่องที่ใครก็วิ่งเข้าได้ ก็เปิดช่องให้คนไม่หวังดีลองวิ่งเข้ามาด้วย เครื่องพวกนี้เลยมี firewall เป็นเหมือนรั้วที่ปิดประตูทุกบานไว้ก่อน เปิดเฉพาะบานที่ตั้งใจเปิด ประตูแต่ละบานในที่นี้เรียกว่า พอร์ต (port)

สรุปกำแพงคือ เครื่อง Mac (ตัวที่อยากเป็นคนสั่ง) ดันเป็นฝ่าย "ไม่มีเบอร์ให้โทรเข้า" ส่วนเครื่องคลาวด์ก็ปิดประตูไว้หมดเพื่อความปลอดภัย แล้วจะให้สองตัวคุยกันยังไง

ช่วงที่ 3ทางง่ายสองทาง ที่ดูเหมือนใช่ แต่ต้องจ่ายแพง

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

ทางสอง ลงเครือข่ายส่วนตัว (VPN) ทับลงไป อย่าง Tailscale เพื่อทำเหมือนสองเครื่องอยู่วงเดียวกัน เราลองแล้ว ผลคือ เน็ตหายทั้งเครื่อง เพราะ Mac เครื่องนี้ต่อเน็ตผ่าน VPN ของบริษัทอยู่ก่อนแล้ว พอลง VPN ตัวที่สองทับ สองตัวก็ไปแย่งกันคุมว่า "ข้อมูลควรวิ่งออกทางไหน" แย่งเส้นทางหลักกันเอง เครื่องเลยงงและออกเน็ตไม่ได้เลย

ทั้งสองทางต้องจ่ายแพง (ความเสี่ยง หรือเน็ตล่ม) เพื่อแก้ปัญหาเล็กๆ คำตอบที่ใช้จริงกลับเป็นเครื่องมือเก่าแก่ที่มีอยู่แล้วในทุกเครื่อง

ช่วงที่ 4หลักการ ถ้าวิ่งออกไปหาเองได้ ก็ไม่ต้องเปิดประตูให้ใครเข้า

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

SSH tunnel แค่พลิกมุมคิด แทนที่จะรอให้คลาวด์วิ่งเข้ามาหา Mac (ซึ่งทำไม่ได้) เราให้ Mac เป็นฝ่ายวิ่งออกไปเปิด "ท่อ" ค้างไว้ ผ่านสาย SSH ที่เชื่อถือได้และเข้ารหัสอยู่แล้ว ปลายท่อฝั่ง Mac คือประตูในเครื่องตัวเอง เดินผ่านท่อนี้ไปก็ทะลุถึง service บนคลาวด์

เปรียบเหมือนแทนที่จะเจาะกำแพงทำประตูใหม่ (เสี่ยง) เราใช้ลิฟต์ส่วนตัวที่ต่อถึงกันอยู่แล้ว แอบส่งของผ่านลิฟต์นั้นแทน

ผลที่ได้

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

ผู้ช่วย AI บน Mac จึงคุยกับตัวบนคลาวด์ผ่าน "ประตูในบ้านตัวเอง" ที่ทะลุไปถึงคลาวด์ โดยโลกภายนอกไม่เห็นอะไรเลย

ช่วงที่ 5ทำให้ท่ออยู่ถาวร ไม่ใช่แค่ตอนเปิดเครื่องทิ้งไว้

ท่อที่เปิดด้วยมือมีจุดอ่อนเดียว พอปิดเครื่องหรือสายหลุด ท่อก็หายไป ระบบที่พึ่งอยู่ก็ล่มตาม

ทางแก้คือมอบงานนี้ให้ "พนักงานเบื้องหลัง" ที่มาเข้างานเองและลุกเองถ้าล้ม บน Mac คือ launchd บนคลาวด์คือ systemd เราตั้งสามตัวให้เริ่มเอง + ฟื้นเอง

1. ตัว service ของผู้ช่วยฝั่ง Mac
2. ตัวท่อ SSH
3. ตัว service ฝั่งคลาวด์

พอครบสามขา ระบบก็กลับมาเองหลังรีบูต โดยเราไม่ต้องมานั่งต่อใหม่ทุกครั้ง

เส้นแบ่งที่ควรรู้ ท่อนี้เป็นทางเดียว (Mac วิ่งไปหาคลาวด์) ซึ่งพอดีกับสิ่งที่เราต้องการ คือให้ตัวบน Mac เป็นคนสั่ง ถ้าวันหนึ่งอยากให้สั่งกลับได้สองทาง ค่อยย้ายตัวศูนย์กลางไปไว้ฝั่งที่มีเบอร์สาธารณะ (เครื่องคลาวด์) แทน

ช่วงที่ 6บทเรียนแถม เกือบรื้อทำใหม่ เพราะรันผิดคำสั่ง

ตอนต่อเสร็จใหม่ๆ เราลองเช็กว่าเชื่อมติดไหม คำสั่งที่รันแล้วขึ้นว่า "เห็นแค่เครื่องตัวเอง" เหมือนยังไม่ติด เกือบรื้อทำใหม่ทั้งหมด

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

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

ช่วงที่ 7สรุปสั้น เอาไปใช้ได้เลย

• ถ้าจะเชื่อมสองเครื่อง โดยเครื่องหนึ่งอยู่ที่บ้าน/หลัง NAT อย่าเพิ่งเริ่มที่เปิดพอร์ตหรือลง VPN ทับ ลองให้เครื่องนั้นวิ่งออกไปเปิด SSH tunnel ก่อน
• ปลอดภัยกว่า (ไม่เปิดช่องสาธารณะ) และไม่ชนกับ VPN ที่ใช้อยู่
• อยากให้ถาวร มอบให้พนักงานเบื้องหลังของระบบ (launchd / systemd) จะเริ่มเอง + ฟื้นเอง
• ก่อนสรุปว่าอะไรพัง เช็กว่าใช้คำสั่ง/เครื่องมือถูกตัวไหม แล้วยืนยันที่ข้อมูลจริง

เขียนจากงานจริง ไม่ใช่ทฤษฎี งานเชื่อม fleet ข้ามเครื่องจริง