ไดรฟ์ที่แมปผ่าน VPN ของไซต์: DNS, SMB และพาธ UNC
การค้นหาในเครือข่ายไม่ข้ามลิงก์ที่กำหนดเส้นทาง แต่พาธ UNC ที่มีชื่อข้ามได้ ชี้ DNS ไปที่เซิร์ฟเวอร์ เปิด SMB ทั้งสองทิศทาง แล้วจึงแมปไดรฟ์
หน้าเครือข่ายใน Explorer แสดงอุปกรณ์ที่ประกาศตัวเองในเซกเมนต์ท้องถิ่น และอุโมงค์ที่กำหนดเส้นทางไม่ได้พาข้อประกาศเหล่านั้นไปเลย นี่คือเหตุผลที่เซิร์ฟเวอร์อาจเข้าถึงได้อย่างสมบูรณ์ในขณะที่หน้าต่างตรงหน้าผู้ใช้ยังว่างอยู่ พาธ UNC ที่มีชื่อไม่ขึ้นกับการค้นหาเลย และทางแก้คือทำให้ชื่อresolveได้และพอร์ตตอบสนอง หน้าต่างว่างเป็นอาการของชั้นที่ผิด ไม่ใช่แชร์ที่เสีย
การค้นหาไม่เหมือนกับการเข้าถึง
Windows ค้นหาเครื่องใกล้เคียงผ่านโปรโตคอลที่ออกแบบมาสำหรับโดเมนแบบ broadcast แล้วนำสิ่งที่พบมาแสดงเป็นรายการเพื่อความสะดวก ไม่มีสิ่งใดในรายการนั้นที่จำเป็นสำหรับการเข้าถึงไฟล์ผ่าน SMB ไคลเอนต์ที่รู้ชื่อเซิร์ฟเวอร์และเข้าถึง TCP 445 ได้จะเปิดแชร์ ไม่ว่าเครื่องจะปรากฏในเครือข่ายหรือไม่ก็ตาม
ทั้งสองชั้นล้มเหลวอย่างเป็นอิสระจากกัน ดังนั้น "ฉันมองไม่เห็น" และ "ฉันเปิดไม่ได้" สมควรได้รับการทดสอบที่แตกต่างกัน การดูรายการบอกเกี่ยวกับการค้นหา การเปิดพาธบอกเกี่ยวกับบริการ
ตั้งชื่อเซิร์ฟเวอร์ก่อนแมปแชร์
เผยแพร่เซิร์ฟเวอร์ไฟล์ใน DNS ด้วยที่อยู่ที่มันมีอยู่อีกด้านหนึ่ง และชี้ไซต์ไคลเอนต์ไปยัง resolver ที่ตอบสำหรับโซนนั้นได้ ชื่อแบบ fully qualified ช่วยเลี่ยงการพึ่งพารายการค้นหาคำต่อท้ายในเครื่อง ซึ่งเป็นสาเหตุปกติที่ชื่อสั้นใช้ได้ในไซต์หนึ่งแต่ล้มเหลวในอีกไซต์
หากสภาพแวดล้อมใช้ Active Directory การแก้ชื่อก็เป็นส่วนหนึ่งของการพิสูจน์ตัวตนด้วย: ไคลเอนต์ต้องเข้าถึงโดเมนคอนโทรลเลอร์สำหรับ Kerberos และนาฬิกาที่คลาดเคลื่อนมากจะทำให้การแลกตั๋วล้มเหลว นี่เป็นปัญหาที่ต่างจากการเข้าถึง SMB และดูเหมือนข้อผิดพลาดของข้อมูลรับรอง ทดสอบโดเมนคอนโทรลเลอร์ก่อนพิมพ์รหัสผ่านใหม่
| Layer | What it needs | Symptom when missing |
|---|---|---|
| Name resolution | A DNS answer for the server name | Path cannot be found, ping by IP still works |
| Transport | TCP 445 open in both directions | Connection times out or is refused |
| Authentication | A reachable domain controller and correct clock | Access is denied after the port connects |
| Authorization | Share permission and filesystem permission | The share opens but the folder is inaccessible |
กำหนดเส้นทางและกรองทั้งสองทิศทาง
อุโมงค์ระหว่างไซต์ต้องมีคำนำหน้าปลายทางในตารางเส้นทางท้องถิ่นและคำนำหน้าท้องถิ่นในตารางปลายทาง และไฟร์วอลล์แต่ละด้านต้องอนุญาตทราฟฟิกที่เข้ามา การกำหนดค่าแบบทางเดียวทำให้เกิดการเชื่อมต่อที่เปิดขึ้นแต่ไม่ตอบสนองเลย ซึ่งผู้ใช้อธิบายว่าแชร์ช้า ตรวจสอบตัวนับของอุโมงค์เองก่อน หากแพ็กเก็ตออกไปแล้วไม่มีอะไรกลับมา ให้ดูเส้นทางขากลับหรือตัวกรองปลายทาง
ใน WireGuard ไอพีที่อนุญาตของเพียร์และเส้นทางของระบบปฏิบัติการต้องสอดคล้องกับการออกแบบนั้น อุโมงค์นำแพ็กเก็ตไป ไม่ได้ จัดหาเรกคอร์ด DNS หรือสิทธิ์ของแชร์ ในด้านใดด้านหนึ่ง
สร้างกฎไฟร์วอลล์จากเครือข่ายต้นทางจริงที่จะเชื่อมต่อ และบันทึกข้อยกเว้นไว้ หากการออกแบบแปลที่อยู่ที่ใดที่หนึ่งในเส้นทาง กฎต้องใช้ต้นทางที่แปลแล้ว และที่อยู่เดิมของไคลเอนต์จะไม่ปรากฏในบันทึกอีก
พิสูจน์ตัวตน แล้วจึงแมปไดรฟ์
ไล่ลงตามชั้นด้วยคำสั่งแทนหน้าต่าง Explorer:
Resolve-DnsName -Name files.corp.example -Type A
Test-NetConnection -ComputerName files.corp.example -Port 445
net use Z: \\files.corp.example\Projects /persistent:noคำสั่งที่สองพิสูจน์เส้นทาง TCP ไม่ใช่สิทธิ์ในการอ่านอะไร คำสั่งที่สามคือที่ซึ่งการพิสูจน์ตัวตนและการอนุญาตถูกใช้ และความล้มเหลวตรงนั้นควรส่งคุณไปยังสิทธิ์ของแชร์และระบบไฟล์ ไม่ใช่กลับไปที่เราเตอร์
รักษาการลงนาม SMB และนโยบายการพิสูจน์ตัวตนที่มีอยู่ไว้ การเปิด SMB1 อีกครั้งหรือส่ง broadcast การค้นหาผ่านอุโมงค์ไม่จำเป็นสำหรับพาธที่ระบุชัดเจน และ TCP 445 ควรอยู่บนเส้นทางส่วนตัวไม่ใช่บนการส่งต่อที่หันสู่อินเทอร์เน็ต ให้ผู้ใช้มีทางลัดที่จัดการหรือไดรฟ์ที่แมปไปยังชื่อที่อนุมัติ แล้วหน้าเครือข่ายที่ว่างก็ไม่สำคัญอีก