SMB แชร์ล้มเหลวเฉพาะผ่าน VPN: ปัญหาลายเซ็นหรือซับเน็ตทับซ้อน?
แชร์ที่ทำงานบน LAN อาจล้มเหลวเฉพาะผ่านอุโมงค์ แยกการปฏิเสธลายเซ็น ซับเน็ตที่ทับซ้อน และเซสชัน SMB ที่ค้างอยู่
ไดรฟ์ที่แมปไว้ซึ่งทำงานในออฟฟิศแต่หมดเวลาเมื่ออยู่บ้านแทบไม่ให้ข้อมูลที่เป็นประโยชน์ใด ๆ ด้วยตัวเอง อุโมงค์กำลังส่งแพ็กเก็ตอยู่แน่ชัด ไม่อย่างนั้นจะไม่มีอะไรไปถึงเซิร์ฟเวอร์ สิ่งที่ล้มเหลวคือหนึ่งในสามชั้น: ชื่อถูกแปลงเป็นที่อยู่ผิด ไคลเอนต์ปฏิเสธที่จะลงลายเซ็นเซสชัน หรือเซสชันเก่าอยู่ได้นานกว่าการเชื่อมต่อที่หอบมันไว้ แต่ละอย่างมีการซ่อมต่างกัน และสองในสามอยู่ฝั่งไคลเอนต์
สามความล้มเหลวสวมข้อผิดพลาดเดียวกัน
อักษรไดรฟ์ไม่ได้บอกว่าชั้นไหนแตก และข้อความข้อผิดพลาดมักกว้างพอที่จะใช้ได้กับทั้งสาม แยกด้วยสองคำถามเร็ว: เซิร์ฟเวอร์ตอบที่อยู่ IP ของตัวเองหรือไม่ และพอร์ต 445 รับการเชื่อมต่อหรือไม่
คำตอบเหล่านั้นให้ตารางตัดสินใจแทนการเดา ถ้า IP ทำงานแต่ชื่อไม่ทำงาน ชี้ไปที่การแปลงชื่อ ถ้าทั้งสองทำงานแต่การลงชื่อเข้าใช้ถูกปฏิเสธ ชี้ไปที่ลายเซ็น ถ้าทั้งสองทำงานแต่การอ่านไฟล์ค้างหลังอุโมงค์ขาด ชี้ไปที่เซสชันเก่า
| Symptom | Layer to inspect |
|---|---|
| IP works, hostname times out | DNS or subnet overlap |
| TCP 445 opens, logon refused | SMB signing policy |
| Hangs after reconnect | Session state and timers |
ไล่ตามลำดับนั้น เพราะชื่อที่แปลงไปยังโฮสต์ผิดทำให้ทุกการทดสอบหลังจากนั้นไร้ความหมาย
แปลงชื่อก่อนแตะต้องแชร์
ถ้าเซิร์ฟเวอร์ตอบที่ที่อยู่ของมันแต่ชื่อแชร์หมดเวลา อุโมงค์กำลังทำหน้าที่ของมันและไคลเอนต์กำลังมองผิดที่ ในการเข้าถึงระยะไกล มีสองสาเหตุอธิบายส่วนใหญ่ของเรื่องนี้
อย่างแรกคือที่อยู่ทับซ้อน เมื่อออฟฟิศใช้ 192.168.70.0/24 และเราเตอร์ที่บ้านแจกช่วงเดียวกัน ชื่อโฮสต์ที่แปลงเป็น 192.168.70.20 อาจชี้ไปยังอุปกรณ์ในเครื่องแทนเซิร์ฟเวอร์หลังอุโมงค์ Windows อาจส่งคำขอในเครื่อง ปฏิเสธเส้นทาง หรือแปลงไปยังเครื่องพิมพ์ที่บังเอิญมีที่อยู่นั้น การซ่อมคือเปลี่ยนเลขฝั่งหนึ่ง ไม่ใช่เพิ่มเส้นทางอีกเส้น
อย่างที่สองคือขอบเขต DNS อะแดปเตอร์ VPN ที่ไม่มีเซิร์ฟเวอร์ DNS ภายใน หรือมีเซิร์ฟเวอร์ที่เข้าถึงไม่ได้ผ่านอุโมงค์ ปล่อยให้ชื่อสั้นไปยังตัวแปลงสาธารณะ อ่านรายการ DNS ของอะแดปเตอร์และถามชื่อภายในโดยตรงก่อนแตะต้องแชร์:
> ipconfig /all | findstr /i "DNS Servers"
> nslookup files.corp.internal
Server: 10.90.0.2
Address: 10.90.0.2
Name: files.corp.internal
Address: 10.90.0.15ถ้าการค้นหานั้นคืนที่อยู่ที่คาดไว้ การแปลงชื่อก็จบ และปัญหาอยู่สูงขึ้นไปในสแตก
อ่านข้อกำหนดลายเซ็นทั้งสองฝั่ง
เซิร์ฟเวอร์ที่เข้าถึงได้แต่ปฏิเสธทุกการลงชื่อเข้าใช้เป็นสัญญาณของนโยบายไม่ตรงกัน ไม่ใช่ความล้มเหลวของเครือข่าย Windows อาจบังคับลายเซ็น SMB ฝั่งไคลเอนต์ และเซิร์ฟเวอร์หรือ NAS ที่ไม่ลงลายเซ็นก็ทำเซสชันให้สมบูรณ์ไม่ได้ ไม่ว่าอุโมงค์จะแข็งแรงเพียงใด
คุณอ่านการตั้งค่าไคลเอนต์ได้โดยไม่ต้องค้นในตัวแก้ไขนโยบาย:
> Get-SmbClientConfiguration | Select-Object RequireSecuritySignature
RequireSecuritySignature
-------------------------
True
> Get-SmbConnectionค่าที่ตรงกันฝั่งเซิร์ฟเวอร์อยู่ในคอนฟิกูเรชัน SMB ของเซิร์ฟเวอร์ และทั้งสองต้องตรงกัน ในกรณีที่รายงานมามีครั้งหนึ่ง ไคลเอนต์เปิดข้อกำหนดไว้ด้วยนโยบายท้องถิ่น ขณะที่เซิร์ฟเวอร์ไม่ลงลายเซ็นเลย การปิดข้อกำหนดนั้นแล้วรัน gpupdate /force ทำให้แชร์กลับมาทันที นี่คือขั้นวินิจฉัยเพื่อยืนยันสาเหตุ ไม่ใช่การแก้ถาวร
ควรเปิดลายเซ็นทั้งสองฝั่งเมื่อเซิร์ฟเวอร์รองรับ การเปลี่ยนการตั้งค่าความปลอดภัยเพื่อให้แชร์ทำงานควรบันทึกพร้อมค่าเดิมและเหตุผล เพื่อไม่ให้ใครต้องค้นพบมันใหม่ในการตรวจสอบครั้งถัดไป
ล้างเซสชันเก่าก่อนปรับตัวจับเวลา
แชร์ที่ค้างเฉพาะหลัง VPN หลุดและเชื่อมต่อใหม่มักถือเซสชันที่เซิร์ฟเวอร์ทิ้งไปแล้ว เซิร์ฟเวอร์ปิดเซสชัน SMB ที่ไม่ได้ใช้งานตามตัวจับเวลา Autodisconnect ใต้ LanmanServer\Parameters ซึ่งโดยค่าเริ่มต้นคือ 15 นาที ขณะที่ไคลเอนต์มี SessTimeout ของตัวเองใต้ LanmanWorkstation\Parameters การขาดช่วงที่นานกว่าค่าเหล่านั้นทำให้แต่ละฝั่งมีภาพเซสชันต่างกัน
ทำซ้ำตามลำดับที่แน่นอนเพื่อให้ผลลัพธ์มีความหมาย: เชื่อมต่ออุโมงค์ เปิดแชร์ ตัดอุโมงค์สองนาที ฟื้นคืน แล้วลองอ่านไฟล์ ถ้าการเมานต์ฟื้นเอง ปล่อยตัวจับเวลาไว้ ถ้าค้างจนกว่าจะเมานต์ใหม่ เชื่อมต่อแชร์ใหม่หลังจากอุโมงค์ขึ้นแล้ว แทนการเมานต์ก่อนที่มันจะมีอยู่ และตรวจว่าตัวช่วยเมานต์ลองใหม่หรือไม่
การเพิ่มเวลาหมดอายุเป็นขั้นสุดท้ายที่สมเหตุสมผลสำหรับลิงก์ที่ไม่เสถียร แต่มันรักษาอาการ ไคลเอนต์ที่รอเซสชันที่เซิร์ฟเวอร์ลืมไปแล้วนานขึ้นก็ยังคงรอ
ปิดท้ายด้วยการอ่านไฟล์หนึ่งไฟล์ผ่านการเมานต์ แล้วตัดและฟื้นอุโมงค์อีกครั้ง การทดสอบการยอมรับนั้นครอบคลุมทั้งสามชั้นพร้อมกัน และเป็นการทดสอบเดียวที่ตรงกับสิ่งที่ผู้ใช้ทำจริง