อแดปเตอร์ VPN ของ Windows ควรเป็นแบบส่วนตัวหรือสาธารณะ
ตัดสินใจด้วยการทดสอบสามข้อว่าอแดปเตอร์ VPN ของ Windows ควรอยู่ในโปรไฟล์ส่วนตัวหรือไม่: เส้นทางที่เชื่อถือได้ การจำแนกประเภทที่มั่นคง และกฎที่คุณจำเป็นจริง ๆ
การตั้งอแดปเตอร์ VPN ของ Windows เป็นแบบส่วนตัวนั้นถูกต้องสำหรับอุโมงค์องค์กรและผิดสำหรับไคลเอนต์ VPN เชิงพาณิชย์ และความแตกต่างนี้ไม่ใช่เพียงเรื่องของรูปลักษณ์ หมวดหมู่เครือข่ายเป็นตัวเลือกโปรไฟล์ไฟร์วอลล์ ดังนั้นการเปลี่ยนครั้งเดียวจึงเปิดชุดกฎทั้งหมดในคราวเดียว ผมเคยเห็นสคริปต์ล็อกอินตั้งอแดปเตอร์ที่ไม่รู้จักทุกรายการเป็นแบบส่วนตัว ซึ่งเปิดเผยการแชร์ไฟล์บนเครือข่ายไร้สายของโรงแรมอย่างเงียบ ๆ มีสามเงื่อนไขที่กำหนดคำตอบ และทั้งหมดต้องเป็นจริงก่อนที่คุณจะแตะการตั้งค่า
หมวดหมู่กำหนดอะไรจริง ๆ
Network Location Awareness สร้างลายเซ็นสำหรับแต่ละเครือข่ายที่เชื่อมต่อจากสิ่งที่อแดปเตอร์รายงานได้ ได้แก่ ที่อยู่เกตเวย์และ MAC คำต่อท้าย DNS ตัวควบคุมโดเมนตอบหรือไม่ และเครือข่ายเข้าถึงอินเทอร์เน็ตหรือไม่ Windows ผูกโปรไฟล์กับลายเซ็นนั้น แล้วไฟร์วอลล์จึงใช้ชุดกฎของโปรไฟล์นั้น สาธารณะคือทางเลือกสำรองเมื่อการระบุตัวตนล้มเหลว ด้วยเหตุนี้อุโมงค์ที่ทำงานอยู่จึงยังอาจถูกติดป้ายว่า เครือข่ายที่ไม่รู้จัก
อแดปเตอร์ TUN หรือ TAP มักให้ข้อมูลแก่การระบุตัวตนน้อยมาก คู่ปลายทางของอุโมงค์มักเป็นที่อยู่เดียวไม่ใช่เกตเวย์ DNS อาจถูกส่งเข้าไปภายในอุโมงค์เท่านั้น และอแดปเตอร์ไม่มีเส้นทางเริ่มต้นของตัวเอง ป้ายที่ได้จึงอธิบายอินพุตของไฟร์วอลล์ ไม่ใช่สุขภาพของอุโมงค์ และนั่นคือเหตุผลที่กฎของโปรไฟล์ส่วนตัวหยุดตรงกันในทันทีที่ VPN เชื่อมต่อ
เงื่อนไขที่หนึ่ง อุโมงค์คือเส้นทางที่เชื่อถือได้
การเลือกส่วนตัวคือการยืนยันว่าทุกสิ่งที่เข้าถึงได้ผ่านอินเทอร์เฟซนี้อย่างน้อยก็เชื่อถือได้เท่ากับ LAN ของคุณเอง เพราะการค้นพบและกฎขาเข้าจะถือว่าซับเน็ตนั้นเป็นเครือข่ายท้องถิ่น สำหรับอุโมงค์องค์กรที่เชื่อมไปยังซับเน็ตที่มีการจัดการพร้อมไฟล์เซิร์ฟเวอร์และเครื่องพิมพ์ ข้อยืนยันนี้มักใช้ได้จริง อแดปเตอร์คือประตูสู่เครือข่ายที่องค์กรของคุณควบคุม และเครื่องอีกฝั่งได้รับอนุญาตด้วยนโยบายเดียวกับที่อนุญาตเครื่องของคุณ
ทางออกของ VPN เชิงพาณิชย์ไม่ผ่านการทดสอบนี้ ผู้ใช้อื่นใช้ซับเน็ตทางออกร่วมกัน และการติดป้ายเป็นส่วนตัวจะนำการค้นพบเครือข่าย LLMNR และการแปลงชื่อ NetBIOS ไปไว้บนเซกเมนต์ที่เต็มไปด้วยคนแปลกหน้า อุโมงค์แบบแยกส่วนก็อาจล้มเหลวได้ เมื่ออแดปเตอร์บรรทุกเส้นทางโฮสต์เดียวไปยังแอปพลิเคชันเดียว ก็ไม่มีซับเน็ตที่เชื่อถือได้ให้พูดถึง และการเปลี่ยนหมวดหมู่ก็ไม่ได้ให้อะไรกับคุณ
เงื่อนไขที่สอง การจำแนกประเภทอยู่รอดหลังการเชื่อมต่อใหม่
เกตเวย์หรือคำต่อท้าย DNS ใหม่สร้างลายเซ็นใหม่ และ Windows ตัดสินใจโปรไฟล์ใหม่สำหรับลายเซ็นนั้น ดังนั้น Set-NetConnectionProfile แบบครั้งเดียวจึงอยู่ได้จนถึงการเชื่อมต่อใหม่ครั้งถัดไป ไม่ใช่ตลอดไป ตรวจสอบโปรไฟล์หลังการเชื่อมต่อใหม่ ไม่ใช่หลังการเชื่อมต่อครั้งแรก เพราะนั่นคือเวลาที่การตั้งค่ากลับคืนมาเอง
มีสามวิธีทำให้คงอยู่ วิธีที่สะอาดที่สุดคือนโยบาย เปิด secpol.msc ไปที่ Network List Manager Policies และกำหนดประเภทตำแหน่งสำหรับเครือข่าย รวมถึงนโยบายสำหรับเครือข่ายที่ไม่รู้จัก เพื่อให้โปรไฟล์ถูกนำไปใช้โดยนโยบายไม่ใช่โดยคำสั่ง วิธีที่สองคือสคริปต์ต่อการเชื่อมต่อหรืองานที่กำหนดเวลาไว้ซึ่งรัน cmdlet ของ PowerShell หลังจากอุโมงค์ขึ้น วิธีที่สามคือกลเม็ดเส้นทางแบบเก่า ซึ่งให้เกตเวย์แก่การระบุตัวตนเพื่อตรวจสอบ
route -p add 0.0.0.0 mask 0.0.0.0 10.8.0.1 metric 50 IF 24
Get-NetConnectionProfileกลเม็ดเส้นทางเป็นเพียงการเลี่ยง ไม่ใช่การจำแนกประเภท มันพังเมื่อความสัมพันธ์ของเมตริกเปลี่ยนหรือไคลเอนต์ VPN เขียนเส้นทางใหม่เมื่อเชื่อมต่อใหม่ และมันเปลี่ยนการเลือกเส้นทางอย่างเงียบ ๆ สำหรับทุกสิ่งที่ไม่ตกไปยังเส้นทางเริ่มต้นที่สอง
เงื่อนไขที่สาม คุณต้องใช้ชุดกฎส่วนตัว
โดยทั่วไปโปรไฟล์ส่วนตัวมี File and Printer Sharing, Network Discovery และกลุ่มสำหรับการดูแลระยะไกล หากงานคือการเข้าถึงแชร์ SMB หรือเครื่องพิมพ์ผ่านอุโมงค์ นั่นคือเหตุผลจริงในการเปลี่ยนหมวดหมู่ หากงานคือการเข้าถึงขาออกไปยังเว็บแอปพลิเคชันเดียว หมวดหมู่ก็ไม่เกี่ยวข้อง เขียนกฎขาออก เก็บเป็นสาธารณะ และหยุดตรงนั้น
| Scenario | Category | Why |
|---|---|---|
| Corporate tunnel to a file server or printer | Private | Private rules carry the sharing you need |
| Commercial VPN for privacy | Public | The exit subnet is shared with strangers |
| Split tunnel with a single host route | Public | No trusted subnet and an unstable signature |
| Site-to-site tunnel to a branch LAN | Private | The far subnet is managed like the local one |
| Lab adapter you control end to end | Private | Discovery helps and nothing else is exposed |
อ่านตารางเป็นจุดเริ่มต้น แล้วตรวจสอบว่ากฎส่วนตัวใดเปิดใช้งานจริงในอิมเมจของคุณ อิมเมจที่เสริมความแข็งอาจลบการแชร์ไฟล์ออกจากโปรไฟล์ส่วนตัวทั้งหมด ซึ่งในกรณีนั้นการเปลี่ยนหมวดหมู่จะไม่ได้อะไรเลยจนกว่าคุณจะเพิ่มกฎกลับคืน การตรวจสอบนั้นใช้คำสั่งเดียวและประหยัดเวลาบ่ายยาว
ทำการเปลี่ยนแปลงโดยไม่ขยายอย่างอื่นทั้งหมด
เล็งที่ดัชนีอินเทอร์เฟซ ไม่ใช่ไวลด์การ์ด และอ่านรายการก่อนและหลัง
Get-NetConnectionProfile
Set-NetConnectionProfile -InterfaceIndex 24 -NetworkCategory Private
Get-NetFirewallProfileโปรไฟล์ที่จัดเก็บไว้อยู่ในคีย์ NetworkList ในรีจิสทรี ซึ่งค่า Category แยกเครือข่ายสาธารณะ ส่วนตัว และโดเมน การแก้ไขทำได้และผิดพลาดได้ง่าย คุณต้องเปลี่ยนรายการที่ตรงกับลายเซ็นปัจจุบันของอแดปเตอร์ ไม่ใช่รายการเก่าที่ที่อยู่ก่อนหน้าทิ้งไว้ รายการที่ล้าสมัยดูถูกต้องในตัวแก้ไขและไม่ทำอะไรเลยเมื่อเชื่อมต่อใหม่
ไม่ว่าคุณจะทำอะไร อย่าเผยแพร่สคริปต์ที่ตั้งอแดปเตอร์ที่ไม่รู้จักทุกรายการเป็นส่วนตัว นั่นคือเวอร์ชันบรรทัดเดียวของการเปิดการค้นพบบนเครือข่ายไร้สายที่ไม่น่าเชื่อถือ หากคุณต้องการแชร์เฉพาะกับซับเน็ตของอุโมงค์ ให้เก็บโปรไฟล์เป็นสาธารณะและเพิ่มกฎขาเข้าที่จำกัดเฉพาะช่วงที่อยู่ระยะไกลของอุโมงค์ กฎของไฟร์วอลล์นั้นแคบกว่าหมวดหมู่
ตรวจสอบการแชร์ ไม่ใช่ป้ายกำกับ
หลังการเปลี่ยนแปลง ให้ทดสอบทรัพยากรเองแทนที่จะเชื่อป้ายกำกับ
Test-NetConnection files.corp.example -Port 445
Resolve-DnsName files.corp.exampleหากการแชร์ยังล้มเหลวในขณะที่อแดปเตอร์แสดงเป็นส่วนตัว หมวดหมู่ก็ไม่ใช่ปัญหาของคุณอีกต่อไป การแปลงชื่อ เส้นทางที่หายไป หรือสิทธิ์การแชร์จะให้อาการเดียวกัน และการเปลี่ยนโปรไฟล์อีกครั้งไม่สามารถแก้ไขสิ่งใดในนั้นได้ เชื่อมต่อใหม่หนึ่งครั้งและรัน Get-NetConnectionProfile อีกครั้งเพื่อยืนยันว่าการตั้งค่ายังคงอยู่ จากนั้นจัดการความล้มเหลวที่เหลือเป็นปัญหา SMB ปกติ
รายการตรวจสอบ ยืนยันว่าอุโมงค์เป็นเส้นทางที่มีการจัดการ โปรไฟล์อยู่รอดหลังการเชื่อมต่อใหม่ กฎส่วนตัวที่จำเป็นมีอยู่ในอิมเมจ และการแชร์แปลงชื่อได้และตอบสนองบนพอร์ต 445 หากข้อใดในสามข้อแรกเป็นเท็จ ให้ปล่อยอแดปเตอร์ไว้ที่สาธารณะและแก้ปัญหาการเข้าถึงด้วยกฎที่จำกัด