WireGuard ใน LXC หรือ VM บน Proxmox: ควรวางไว้ที่ไหน?
WireGuard สามารถทำงานบนโฮสต์ Proxmox ในคอนเทนเนอร์ หรือใน VM ปัจจัยชี้ขาดคือความเป็นเจ้าของเคอร์เนล การควบคุมอินเทอร์เฟซ และการกู้คืน
WireGuard ต้องมีเคอร์เนลเดียวเท่านั้นที่เป็นเจ้าของอินเทอร์เฟซของมัน และข้อเท็จจริงนี้ก็ตัดสินข้อโต้แย้งเรื่องตำแหน่งบน Proxmox ไปเกือบทั้งหมดก่อนที่เรื่องประสิทธิภาพจะเข้ามาในวงสนทนา คอนเทนเนอร์ LXC คือมุมมองเนมสเปซของเคอร์เนลโฮสต์ ขณะที่ VM บูตเคอร์เนลของตัวเอง ดังนั้นคำถามที่มีประโยชน์จึงไม่ใช่ตัวเลือกไหนเบากว่า แต่เป็นว่าคุณยินดีแก้ไขเคอร์เนลใด และอยู่กับการกู้คืนเส้นทางไหนได้ ตอบคำถามนี้ได้ การเลือกระหว่างโฮสต์ คอนเทนเนอร์ หรือ VM มักจะเกิดขึ้นเอง
แขก LXC ทำงานอยู่ภายในเคอร์เนลของโฮสต์
การติดตั้ง wireguard-tools ในคอนเทนเนอร์ทำให้คุณได้โปรแกรมควบคุม ไม่ใช่เคอร์เนลส่วนตัว อินเทอร์เฟซ wg0 ที่คุณสร้างจะถูกลงทะเบียนในสแตกเครือข่ายของโฮสต์และปรากฏในรายการโมดูลของโฮสต์ นี่คือเหตุผลที่คอนเทนเนอร์ผ่านการตรวจสอบแพ็กเกจทั้งหมดได้แต่ยังล้มเหลวที่คำสั่ง wg แรกเมื่อเคอร์เนลของโฮสต์ไม่มีโมดูลนั้น และ เอกสารอ้างอิงคอนเทนเนอร์ของ Proxmox อธิบายแบบจำลองเคอร์เนลที่ใช้ร่วมกันนั้น พร้อมขอบเขตเนมสเปซและสิทธิพิเศษที่คุณทำงานอยู่ภายใน
อำนาจคือข้อจำกัดที่สอง การยกอินเทอร์เฟซขึ้นและผูกที่อยู่เข้ากับมันต้องใช้ สิทธิ์การดูแลเครือข่ายภายในเนมสเปซที่เป็นเจ้าของมัน และคอนเทนเนอร์ที่ไม่มีสิทธิพิเศษจะแมปสิทธิ์เหล่านั้นผ่านเนมสเปซผู้ใช้ของตัวเองแทนที่จะถือไว้โดยตรง อย่าเอื้อมไปหาสิทธิ์เต็มเป็นคำตอบแรก ให้ดูว่าคอนเทนเนอร์ถูกขอให้ทำอะไรจริง ๆ แล้วให้สิทธิ์นั้น
เคอร์เนลของโฮสต์ก็เป็น dependency ที่ใช้ร่วมกัน การอัปเดตเคอร์เนล Proxmox เปลี่ยนการทำงานของ WireGuard ใต้คอนเทนเนอร์ทุกตัวพร้อมกัน ซึ่งสะดวกจนกว่าการอัปเดตกับความคาดหวังของคอนเทนเนอร์จะไม่ลงรอยกัน
โฮสต์ คอนเทนเนอร์ และ VM: แต่ละตำแหน่งเป็นเจ้าของอะไรจริง ๆ
การวางบนโฮสต์นำ VPN ไปไว้ในเครือข่ายของไฮเปอร์ไวเซอร์เอง เส้นทาง กฎไฟร์วอลล์ และอุโมงค์กลายเป็นส่วนหนึ่งของการกู้คืนโฮสต์ และข้อผิดพลาดตรงนั้นอาจพาอินเทอร์เฟซการจัดการไปด้วย นั่นยอมรับได้สำหรับการกำหนดเส้นทางโครงสร้างพื้นฐานบนโฮสต์ที่เข้าถึงได้ผ่านคอนโซล และเจ็บปวดบนเครื่องระยะไกลที่ไม่มีทางเข้าจากนอกแบนด์
คอนเทนเนอร์เก็บบริการไว้ในแพ็กเกจและรีสตาร์ตได้ ขณะเดียวกันก็ยังยืมเคอร์เนลของโฮสต์ มันเหมาะกับบริการที่ตั้งใจใช้เคอร์เนลร่วมกันและให้หน่วยเล็ก ๆ แก่คุณในการสร้างใหม่ มันไม่ได้ให้เคอร์เนลอิสระ ดังนั้นอะไรก็ตามที่ต้องสร้างโมดูลเฉพาะจะชี้ห่างจากตัวเลือกนี้
| Placement | Kernel owner | Typical failure mode |
|---|---|---|
| Proxmox host | Hypervisor | A routing change breaks host management access |
| LXC container | Host kernel, container namespace | Missing capability or missing module at wg0 creation |
| Virtual machine | Guest kernel | Extra maintenance and a second patch cycle |
VM แลกกับหน่วยความจำที่มากกว่าและอีกระบบให้แพตช์ แต่ได้อุโมงค์ที่มีเคอร์เนลของตัวเอง ตารางเส้นทางของตัวเอง และขอบเขตสแนปช็อต เมื่อ VPN คือสิ่งที่คุณย้อนกลับหลังการเปลี่ยนแปลงที่ไม่ดี สแนปช็อตนั้นก็คุ้มกับภาระที่เพิ่มขึ้น
สามเงื่อนไขที่เลือกแทนคุณ
ถ้าอุโมงค์ต้องการเวอร์ชันเคอร์เนลหรือคุณสมบัติ WireGuard ที่โฮสต์ Proxmox ไม่มี ให้หยุดตรงนี้และใช้ VM คุณไม่สามารถติดตั้งเคอร์เนลที่ใหม่กว่าในคอนเทนเนอร์ได้ และไม่ควรเปลี่ยนเคอร์เนลของไฮเปอร์ไวเซอร์เพื่อเอาใจแขกเพียงตัวเดียว
ถ้าอุโมงค์เป็นเกตเวย์ของไซต์สำหรับพรีฟิกซ์ LAN จริง ให้ถามว่าใครเป็นเจ้าของเส้นทางขากลับอยู่แล้ว คอนเทนเนอร์กำหนดเส้นทางทราฟฟิกได้ แต่อินเทอร์เฟซของมันอยู่ในสแตกของโฮสต์ โฮสต์จึงต้องแบกส่วนหนึ่งของคอนฟิกูเรชันในที่สุด ไม่ว่าคุณจะวางแผนไว้หรือไม่ การวางบนโฮสต์ซื่อสัตย์เรื่องนี้ การวางในคอนเทนเนอร์มักไม่
จากนั้นชั่งน้ำหนักรัศมีผลกระทบของข้อผิดพลาด การรีสตาร์ตคอนเทนเนอร์นั้นถูก การกู้คืนสแนปช็อต VM นั้นคาดเดาได้ และการซ่อมเครือข่ายของโฮสต์อาจต้องเข้าถึงทางกายภาพหรือคอนโซล ตัวเลือกที่ถูกต้องคือตัวเลือกที่คุณกู้คืนกรณีเลวร้ายที่สุดได้จริงในชั่วโมงที่มันเกิดขึ้น
คำถามที่สี่ไม่ค่อยชี้ขาดแต่น่าพูด: มีอะไรอื่นบนโฮสต์ที่ต้องเห็นอินเทอร์เฟซอุโมงค์หรือไม่ ถ้ามี การวางบนโฮสต์หรือในคอนเทนเนอร์จะเก็บการมองเห็นนั้นไว้ในเครื่อง ขณะที่ VM บังคับให้คุณกำหนดเส้นทางระหว่างแขกกับโฮสต์
พิสูจน์ตำแหน่งก่อนส่งทราฟฟิกผ่านมัน
หลังติดตั้ง ให้ยืนยันว่าเคอร์เนลใดให้บริการอินเทอร์เฟซจริง และคอนเทนเนอร์ได้รับอำนาจเพียงพอที่จะรักษามันไว้หรือไม่:
$ pct config 101 | grep -E 'unprivileged|features'
unprivileged: 1
$ pct exec 101 -- wg show
interface: wg0
listening port: 51820
$ pct exec 101 -- ip -4 addr show wg0
inet 10.60.0.2/24 scope global wg0จากนั้นตรวจด้านการส่งต่อจากโฮสต์ เพราะการจับมือกันเพียงอย่างเดียวพิสูจน์แค่ว่าอุโมงค์ขึ้นแล้ว ใช้ ip route get กับที่อยู่ไคลเอนต์ และยืนยันว่าฮอปถัดไปกับอินเทอร์เฟซตรงกับการออกแบบ และมีเส้นทางขากลับอยู่อีกฝั่ง
ทิ้งการติดตั้งไว้พร้อมเจ้าของที่เป็นลายลักษณ์อักษร: เคอร์เนลใดแบกการทำงาน เนมสเปซใดถืออินเทอร์เฟซ และเกตเวย์ได้รับอนุญาตให้ส่งต่อพรีฟิกซ์ใด ประโยคนั้นป้องกันเหตุการณ์ได้มากกว่าการเปรียบเทียบ Benchmark ของทั้งสามตำแหน่งใด ๆ