VPN เซิร์ฟเวอร์ที่บ้านกับเซิร์ฟเวอร์คลาวด์ อันไหนไปถึง NAS ของคุณ
อุโมงค์ขึ้นได้ แต่ NAS ที่บ้านยังเข้าถึงไม่ได้ เลือกตำแหน่ง endpoint ตามทรัพยากรที่ต้องแตะก่อน แล้วค่อยตรวจเส้นทาง
อุโมงค์ขึ้นได้ ไคลเอนต์แสดงจุดสีเขียว และ ssh 192.168.1.20 ก็ยังค้างจนหมดเวลา ผมเจอแบบนี้พอดีหลังเช่าเครื่องคลาวด์เล็ก ๆ แล้วติด WireGuard ลงไป แฮนด์เชกปกติ DNS ปกติ แต่ NAS บนโต๊ะของผมเข้าถึงไม่ได้ราวกับอยู่บนดวงจันทร์ อุโมงค์ไม่ได้มีอะไรผิด ปัญหาคือ endpoint ไปอยู่ในเครือข่ายที่ไม่มีเส้นทางมาบ้านผม ตำแหน่งของ endpoint เป็นตัวกำหนดว่าเครือข่ายไหนอยู่ติดกัน จึงต้องเลือกจากทรัพยากรที่ต้องแตะก่อน แล้วค่อยเทียบเรื่องโฮสติ้ง
อุโมงค์ไปถึงได้เฉพาะเครือข่ายที่ endpoint หาเส้นทางได้
VPN ให้ที่อยู่กับไคลเอนต์ภายในโดเมนการหาเส้นทางของ endpoint เอง เมื่อไคลเอนต์ส่งแพ็กเก็ตไปที่ 192.168.1.20 endpoint ต้องรู้ว่ามันไปที่ไหน ตารางของ VM บนคลาวด์รู้จักซับเน็ต VPC ของผู้ให้บริการ แต่ไม่เคยรู้จัก LAN ของคุณ การเชื่อมต่อได้กับเข้าถึงได้เป็นคนละข้อเท็จจริง และความสับสนระหว่างบ้านกับคลาวด์ส่วนใหญ่มาจากการเอาข้อแรกไปเป็นหลักฐานของข้อที่สอง
คำสั่งเดียวตัดสินได้ บน endpoint ip route get 192.168.1.20 จะระบุอินเทอร์เฟซ LAN หรือชี้ไปที่เส้นทางเริ่มต้น บนเครื่องที่บ้านคำตอบคือฝั่ง LAN บนเครื่องคลาวด์แพ็กเก็ตออกไปอินเทอร์เน็ตแล้วตาย การเปิด net.ipv4.ip_forward=1 และเพิ่มกฎ MASQUERADE ไม่เปลี่ยนสิ่งนั้น เพราะยังไม่มีที่ให้ส่งต่อไปจนกว่าอะไรฝั่งบ้านจะปิดลิงก์เข้าคลาวด์
กรณีบ้านมีครึ่งหลัง คือเส้นทางขากลับ แพ็กเก็ตที่ออกจาก LAN ผ่านกล่องอุโมงค์จะถูก NAT หรือ LAN ต้องมีเส้นทางคงที่กลับไปยังซับเน็ตของอุโมงค์ เมื่อทำงานได้เพียงทิศเดียว ให้ตรวจ sysctl net.ipv4.conf.all.rp_filter การกรองเส้นทางย้อนกลับแบบเข้มจะทิ้งคำตอบที่มาจากอินเทอร์เฟซอื่นจากที่เส้นทางคาดไว้ และอาการจะดูเหมือนกฎไฟร์วอลล์เป๊ะ
อ่านอาการก่อนแตะการตั้งค่า
อุโมงค์ไม่ขึ้น คีย์ ที่อยู่ endpoint หรือพอร์ต UDP ถูกบล็อก อุโมงค์ขึ้นแต่โฮสต์ใน LAN ตาย ตำแหน่งและการหาเส้นทาง อุโมงค์ขึ้นแต่การท่องเว็บตาย การส่งต่อ NAT หรือ DNS นี่คือสามชั้นและการตรวจสามแบบที่ต่างกัน การเขียนการตั้งค่าที่ถูกอยู่แล้วใหม่ทำให้เสียเวลาทั้งเย็น
| Symptom | First suspect | Check |
|---|---|---|
| Handshake fails, no transfer | Keys, endpoint port, UDP blocked | wg show, then the port from outside |
| Peer pings, LAN host times out | No route to the LAN | ip route get on the endpoint |
| Tunnel up, name resolution fails | DNS options in the peer config | Resolve a name from the client |
| Large transfers reset the connection | MTU | Lower the tunnel MTU and retry |
การเข้าถึงจากภายนอกเข้าบ้านควรตรวจแยก เพราะเป็นตัวตัดสินว่าการโฮสต์ที่บ้านเป็นไปได้หรือไม่ เปรียบเทียบที่อยู่ WAN ที่เราเตอร์รายงานกับที่อยู่ที่โฮสต์ภายนอกเห็น ถ้ามันอยู่ใน 100.64.0.0/10 หรือสองอย่างไม่ตรงกัน คุณอยู่หลัง NAT ของผู้ให้บริการและไม่มีการส่งต่อพอร์ตใดจะทำงานได้เลย ทางเลือกจริงคือรีเลย์ ลิงก์คลาวด์ที่โทรออกจากบ้าน หรือย้าย endpoint
การโฮสต์ที่บ้านให้อะไรและแลกกับอะไร
บ้านเป็นตำแหน่งเดียวที่อยู่ใน LAN โดยค่าเริ่มต้น และนั่นคือเหตุผลทั้งหมดที่วางเซิร์ฟเวอร์ไว้ที่นั่น อุปกรณ์ที่ตอบเฉพาะเซกเมนต์ท้องถิ่น เช่น เครื่องพิมพ์และหน้าจัดการ NAS ที่ปฏิเสธซับเน็ตที่ไม่ใช่ท้องถิ่น ทำงานได้โดยไม่ต้องหาเส้นทางเพิ่ม คุณยังดูแลเครื่อง เราเตอร์ และอัปลิงก์เองด้วย
ค่าใช้จ่ายเป็นเรื่องกายภาพ อัปโหลดที่บ้านเป็นเพดานของไคลเอนต์ทุกตัวพร้อมกัน วิดีโอคอลกับแบ็กอัปจึงแย่งท่อเดียวกัน ไฟฟ้า การสึกของดิสก์ แพตช์ ที่อยู่ไดนามิกที่ต้องใช้ DDNS เราเตอร์ที่ต้องส่งต่อ UDP เข้ามา และอาจเป็น NAT ซ้อน ทั้งหมดตกอยู่กับคุณ สิ่งที่คนมักข้ามคือการกู้คืน ถ้ากล่องตายตอนคุณไม่อยู่ ทางเดียวเข้าบ้านก็ตายไปด้วย เก็บอุปกรณ์เครื่องที่สองที่มีคีย์เดียวกัน หรืออย่างน้อยมีแผนเข้าถึงทางกายภาพ
ถ้าอยากเข้าถึง LAN โดยไม่มีกล่องที่บ้าน ให้สร้างลิงก์แทนการเสแสร้ง endpoint บนคลาวด์กลายเป็นเราเตอร์ อุโมงค์จากฝั่งบ้านด้วย AllowedIPs = 192.168.1.0/24 บน peer ฝั่งคลาวด์ พร้อมการส่งต่อและ NAT บนกล่องคลาวด์ คู่มือการส่งต่อของ strongSwan อธิบายครึ่งขากลับของการตั้งค่านี้ และนั่นคือที่ที่ความพยายามเหล่านี้ล้มเหลวเป็นส่วนใหญ่ peer ที่บ้านต้องออนอยู่เพื่อให้อะไรก็ตามทำงาน คุณจึงแลกความขึ้นต่อกันอย่างหนึ่งกับอีกอย่าง และควรจดไว้
endpoint บนคลาวด์มีไว้เพื่ออะไรจริง ๆ
endpoint บนคลาวด์เปลี่ยนทางออกสาธารณะของคุณ ทราฟฟิกออกจากช่วงที่อยู่ของผู้ให้บริการ และเว็บไซต์เห็นที่อยู่นั้นแทนที่อยู่บ้าน นั่นคือคุณค่า และนั่นคือเหตุผลที่ VPN บนคลาวด์ไม่ได้ให้ NAS แก่คุณ คุณย้ายทางออก ไม่ใช่ LAN
คุณยังดูแลระบบเกสต์ บริการ VPN และข้อมูลรับรองของมัน ขณะที่ผู้ให้บริการดูแลไฮเปอร์ไวเซอร์และเครือข่ายกายภาพ และการแบ่งนี้สำคัญเมื่อมีอะไรพังตอนตี 2 endpoint สาธารณะถูกสแกนตลอดเวลา จึงปิดพอร์ตจัดการ เปิดเฉพาะพอร์ต VPN และแพตช์ตามตาราง กลุ่มความปลอดภัยและไฟร์วอลล์ของผู้ให้บริการต้องอนุญาตพอร์ตนั้น และคลาวด์บางแห่งทิ้งทราฟฟิกที่ส่งต่อเว้นแต่คุณปรับการตรวจต้นทางและปลายทางบนอินสแตนซ์
อินสแตนซ์เล็กครอบคลุมไคลเอนต์ไม่กี่ตัว แต่การเข้ารหัสเป็นงาน CPU และอินสแตนซ์ burstable ที่เครดิตหมดจะทำงานไม่สม่ำเสมอภายใต้โหลดต่อเนื่อง มองเส้นทางที่คุณใช้จริง ไม่ใช่ใบบอกสเปก
การตัดสินใจที่จดได้
งานเป็นตัวกำหนดตำแหน่ง ไม่ใช่ป้ายบนกล่อง ถ้าต้องการอุปกรณ์ใน LAN ที่บ้าน คำตอบที่ถูกและถูกที่สุดคือ endpoint ที่บ้าน กล่องคลาวด์จะใช้ได้หลังสร้างลิงก์กลับมาแล้วเท่านั้น ถ้าต้องการทางออกสาธารณะอื่น คำตอบคือคลาวด์ และคำถามเรื่อง LAN ไม่เกิดขึ้นเลย อยากได้ทั้งสองอย่างเป็นเรื่องชอบธรรม แต่หมายถึงสอง endpoint สองชุดคีย์ และสองเส้นทางที่บันทึกไว้
| What you need | Endpoint location | What else must exist |
|---|---|---|
| Reach a NAS or printer on the home LAN | A box on that LAN | Port forward or relay, DDNS, recovery plan |
| Browse from an exit unrelated to home | Cloud instance | Firewall and egress rules, patching |
| Both, reliably | Two endpoints, or cloud plus a link home | Separate keys, routes, documented failure modes |
ตรวจจากไคลเอนต์ตามลำดับ แฮนด์เชก ที่อยู่ peer โฮสต์ใน LAN แล้วจึง IP ทางออก curl -s https://ifconfig.me แสดงสิ่งที่อินเทอร์เน็ตเห็น และ ip route get 192.168.1.20 แสดงสิ่งที่ endpoint เชื่อ เมื่อการตรวจทางออกผ่านแต่การตรวจ NAS ค้าง คุณมีคำตอบเรื่องตำแหน่งแล้ว การปรับ AllowedIPs บนไคลเอนต์ไม่ได้ทำให้เกิดเส้นทาง 10.8.0.0/24, 192.168.1.0/24 บรรทัดแยกเช่นนี้เก็บทราฟฟิก LAN ไว้ในอุโมงค์ก็ต่อเมื่อเส้นทางนั้นมีอยู่จริง