แชร์ VPN ของ Windows ให้คอนโซลแบบต่อสาย: เกตเวย์บนพีซีหรือเราเตอร์
คอนโซลที่อยู่หลังพีซี Windows ต้องมีเซกเมนต์ปลายทาง การกำหนดแอดเดรส การแปล และไคลเอนต์ที่ยอมส่งต่อ เปรียบเทียบกับการที่เราเตอร์ถืออุโมงค์ไว้
คอนโซลที่ไม่สามารถรันไคลเอนต์ VPN ได้บางครั้งก็ยืมอุโมงค์ของพีซี Windows ได้ และการจัดแบบนี้นั้นล้มเหลวบ่อยกว่าที่จะสำเร็จ ด้วยเหตุผลที่ไม่เกี่ยวกับ VPN เลย พีซีต้องกลายเป็นเกตเวย์ อินเทอร์เฟซปลายทางเฉพาะ การกำหนดแอดเดรสให้คอนโซล การแปล และไคลเอนต์ที่ยอมส่งต่อแพ็กเก็ตของอุปกรณ์อื่น อุโมงค์ที่ใช้ได้กับแอปของพีซีเองไม่ได้พิสูจน์สิ่งใดในนี้
การเปรียบเทียบที่คุ้มค่าคือระหว่างการจัดแบบนั้นกับเราเตอร์ที่ถืออุโมงค์ให้ทั้งเครือข่าย ทั้งสองต่างกันที่การบำรุงรักษา พฤติกรรมเมื่อเกิดความล้มเหลว และจำนวนนโยบายที่มองเห็นได้พร้อมกัน
สิ่งที่เกตเวย์บนพีซีต้องทำ
เกตเวย์ต้องมีอินเทอร์เฟซที่หันไปทางคอนโซล ช่วงแอดเดรสสำหรับเซกเมนต์นั้น และกฎการแปลที่เขียนทราฟฟิกของคอนโซลใหม่ไปยังอุโมงค์ ยังต้องให้ไคลเอนต์ส่งต่อแพ็กเก็ตที่ตัวเองไม่ได้สร้าง ซึ่งเป็นการตั้งค่าที่ต่างจากการรับทราฟฟิกของตัวเอง การแก้ชื่อต้องไปตามเส้นทางเดียวกัน ไม่เช่นนั้นคอนโซลจะแก้บริการเกมผ่านเส้นทางหนึ่งแล้วเชื่อมต่ออีกเส้นทางหนึ่ง แต่ละข้อเป็นการกำหนดค่าคนละขั้นและมีวิธีล้มเหลวของตัวเอง
console -> dedicated ethernet -> windows sharing / nat
-> selected tunnel interface -> internetการแชร์การเชื่อมต่ออินเทอร์เน็ตของ Windows ให้รูปแบบนี้พอดี โดยการเชื่อมต่อหนึ่งถูกกำหนดเป็นสาธารณะและอีกอันเป็นส่วนตัว การกำหนดนั้นสำคัญกว่าที่คนคาด เพราะอินเทอร์เฟซที่ไปถึงเราเตอร์ในบ้านไม่ใช่ตัวที่พาอุโมงค์โดยอัตโนมัติ
การเปรียบเทียบที่ชี้ขาด
ความต่างสามข้อแยกเกตเวย์บนพีซีออกจากเกตเวย์บนเราเตอร์ และเป็นข้อที่โผล่ขึ้นมาในอีกหลายเดือน ตารางวางทั้งสองไว้ข้างกัน
| Aspect | Windows PC gateway | Router gateway |
|---|---|---|
| Tied to a user session | Yes; sleep or sign-out ends it | No |
| Policy visibility | Split across client and sharing layer | One ruleset |
| Address service | Private side of the sharing feature | Router scope |
| Recovery after reboot | Manual, per session | Automatic |
การผูกกับเซสชันผู้ใช้เป็นความต่างข้อแรกและเป็นข้อที่ทำให้คนประหลาดใจ พีซีที่หลับ ออกจากระบบ หรือติดตั้งอัปเดตจะเลิกเป็นเกตเวย์ และคอนโซลก็เสียเส้นทางโดยไม่มีการตั้งค่าใดเปลี่ยน การมองเห็นนโยบายเป็นข้อที่สอง เพราะกฎของไคลเอนต์และชั้นการแชร์อยู่คนละที่และไม่มีที่ใดอธิบายอีกที่หนึ่ง บริการแอดเดรสเป็นข้อที่สาม และอธิบายคอนโซลที่มีแอดเดรสแต่ยังไปไม่ถึงสิ่งใด
ไม่มีข้อใดทำให้การจัดบนพีซีผิด มันทำให้เป็นการออกแบบชั่วคราว ซึ่งยอมรับได้เมื่อความต้องการเป็นเรื่องชั่วคราว
ทราฟฟิกที่ส่งต่อเป็นอีกหมวดหมู่
ไคลเอนต์บนเดสก์ท็อปอาจปฏิบัติต่อแพ็กเก็ตที่ส่งต่อให้อุปกรณ์อื่นต่างจากแพ็กเก็ตของตัวเอง รายการรวมแอปตามแอปครอบคลุมโปรเซสบนพีซีและไม่พูดถึงทราฟฟิกของคอนโซลเลย ขณะที่สวิตช์ตัดการเชื่อมต่อที่ปกป้องแอปในเครื่องอาจไม่ปกป้องเส้นทางที่ส่งต่อเลย ยืนยันพฤติกรรมที่เอกสารระบุของไคลเอนต์สำหรับทราฟฟิกที่ส่งต่อ แทนที่จะอนุมานจากหน้าเว็บที่โหลดสำเร็จบนพีซี เมื่อพฤติกรรมนั้นไม่ชัดเจน การจัดทั้งหมดก็ตั้งอยู่บนข้อสันนิษฐาน
การกำหนดแอดเดรสของคอนโซลต้องมาจากการจัดแบบแชร์ ไม่ใช่จากการคัดลอกแอดเดรสอุโมงค์ของพีซีไปใส่ การคัดลอกทำให้เกิดแอดเดรสซ้ำ เกตเวย์ผิด และตัวแก้ชื่อที่ชี้ไปยังสิ่งที่คอนโซลไปไม่ถึง ปล่อยให้บริการปลายทางแจกการตั้งค่า แล้วตรวจสอบว่าคอนโซลได้รับอะไรจริง
ตรวจทราฟฟิกของคอนโซล ไม่ใช่ของพีซี
การทดสอบที่มีความหมายเพียงอย่างเดียวคือการสังเกตเส้นทางของคอนโซล บนพีซี คำสั่งด้านล่างแสดงผังอินเทอร์เฟซ ตารางเพื่อนบ้านบนลิงก์ปลายทาง และคอนโซลตอบบนพอร์ตบริการหรือไม่ รันคำสั่งเหล่านี้ขณะเซสชันเกมเชื่อมต่ออยู่จริง
Get-NetIPConfiguration | Select-Object InterfaceAlias, IPv4Address
Get-NetAdapter | Select-Object Name, Status, LinkSpeed
arp -a | findstr 192.168.137.
Test-NetConnection 192.168.137.10 -Port 3074อินเทอร์เฟซที่ไม่มีแอดเดรสทางฝั่งปลายทางหมายความว่าการแชร์ไม่เคยเริ่ม ซึ่งเป็นปัญหาคนละอย่างกับคอนโซลที่เชื่อมต่อไม่ได้ รายการของคอนโซลในตารางเพื่อนบ้านพิสูจน์ว่าลิงก์และการกำหนดแอดเดรสยังมีชีวิต การทดสอบพอร์ตที่ล้มเหลวหลังจากนั้นชี้ไปที่การส่งต่อหรือวิธีที่ไคลเอนต์จัดการทราฟฟิกที่ส่งต่อ ไม่ใช่ที่สาย เปรียบเทียบแอดเดรสขาออกของคอนโซลกับของพีซีก่อนสรุปว่าอุโมงค์คือเส้นทางที่ใช้
เก็บการจัดนี้เป็นเอกสารพร้อมชื่ออินเทอร์เฟซและช่วงแอดเดรส เมื่อมันพังหลังอัปเดตครั้งหน้า หน้านั้นจะประหยัดเวลาการค้นพบซ้ำได้หนึ่งชั่วโมง