เข้าถึง NAS ผ่าน VPN ไม่ได้: ที่อยู่ เส้นทางตอบกลับ หรือบริการ?
อุโมงค์ส่วนตัวต้องมีเส้นทางไปยัง NAS เส้นทางตอบกลับ และบริการที่ได้รับอนุญาต ตัดสินใจว่าสิ่งใดในสามอย่างล้มเหลวก่อนเปลี่ยนข้อมูลรับรอง
อุโมงค์เชื่อมต่อขึ้น ไคลเอนต์ได้รับที่อยู่ และ NAS ไม่ตอบสนองเลย อาการเดียวนี้ครอบคลุมความล้มเหลวสามอย่างที่ไม่เกี่ยวข้องกัน และลำดับที่คุณทดสอบจะเป็นตัวกำหนดว่าจะใช้เวลาซ่อมนานเท่าใด การกำหนดที่อยู่มาก่อน เพราะซับเน็ตที่ทับซ้อนอาจส่งคำขอของคุณไปยังอุปกรณ์แปลกหน้า เส้นทางตอบกลับมาเป็นอันดับสอง เพราะคำขอที่มาถึงโดยไม่มีคำตอบดูเหมือนบริการที่ปิดอยู่ทุกประการ บริการและสิทธิ์มาสุดท้าย และหลังพิสูจน์สองอย่างแรกแล้วเท่านั้น
ความล้มเหลวสามอย่างที่อ่านเป็นเข้าถึงไม่ได้ทั้งหมด
การเลือกที่อยู่ การกำหนดเส้นทางตอบกลับ และการอนุญาตบริการให้ข้อความที่มองเห็นเหมือนกัน: ไม่มีอะไรเกิดขึ้น ทั้งสามมีหลักฐาน ผู้รับผิดชอบ และวิธีแก้ที่ต่างกัน การแยกทั้งสามออกจากกันจึงเป็นงานทั้งหมด ping ที่ล้มเหลวพิสูจน์ได้น้อยเมื่ออยู่ลำพัง และการถูกปฏิเสธ TCP ที่สำเร็จกลับเป็นข่าวดี
| Observation | Most likely conclusion |
|---|---|
| Route to the NAS address leaves the wrong interface | Overlapping or missing private route |
| Request visible on the server, no reply seen | Return path, gateway forwarding or translation |
| TCP connection refused rather than dropped | Reachable host, service not listening or filtered |
| TCP works, login or file access fails | Share permission, account or protocol version |
อ่านตารางเป็นลำดับการทดสอบ ไม่ใช่รายการสาเหตุ แต่ละแถวจำกัดแถวถัดไป เพราะการถูกปฏิเสธพิสูจน์แล้วว่าการกำหนดที่อยู่และเส้นทางตอบกลับทำงาน การใช้เวลายี่สิบนาทีในกฎไฟร์วอลล์ก่อนตรวจว่าเส้นทางเลือกอินเทอร์เฟซใดเป็นวิธีที่พบบ่อยที่สุดในการเสียเวลาช่วงบ่าย ทำงานจากบนลงล่างและหยุดที่แถวแรกที่ตรง
เงื่อนไขแรก: ที่อยู่นั้นเป็นอุปกรณ์ที่ถูกต้องหรือไม่
จดซับเน็ตของ NAS และช่วงที่ VPN มอบให้ไคลเอนต์ แล้วเปรียบเทียบทั้งสองกับเครือข่ายที่แล็ปท็อปของคุณอยู่ตอนนี้ ในแนวทางนี้ NAS อยู่ที่ 10.40.7.25 และพูล VPN คือ 10.40.9.0/24 ซึ่งเป็นสองช่วงส่วนตัวแยกกันภายในแผนไซต์เดียว ครัวเรือนที่ใช้ 192.168.0.0/24 หรือ 10.0.0.0/24 มีโอกาสชนกับช่วงใดช่วงหนึ่งมากกว่ามาก
เมื่อเครือข่ายท้องถิ่นและเครือข่าย NAS ทับซ้อนกัน ไคลเอนต์จะส่งทราฟฟิกนั้นไปยังเกตเวย์ของตัวเองและอาจไปถึงอุปกรณ์ที่ไม่เกี่ยวข้องซึ่งบังเอิญมีที่อยู่เดียวกัน ตรวจสอบเส้นทางก่อนพิมพ์ข้อมูลรับรองลงในสิ่งใดก็ตามที่ตอบสนอง
ip -4 route get 10.40.7.25
traceroute -n -m 5 10.40.7.25คำสั่งแรกบอกอินเทอร์เฟซและเกตเวย์ที่เคอร์เนลจะใช้ ส่วนคำสั่งที่สองแสดงฮอปแรกที่ตอบสนองจริง หากทั้งสองไม่ตรงกัน ให้เชื่อการค้นหาเพราะนั่นคือเส้นทางที่แพ็กเก็ตจะไป รายการฮอปที่หยุดก่อนถึง NAS หนึ่งฮอปก็เป็นการค้นพบ ไม่ใช่ความล้มเหลว การค้นหาที่แก้ไปยังอะแดปเตอร์จริงแทนที่จะเป็นอุโมงค์จะยุติการตรวจสอบ ณ จุดนี้
เงื่อนไขที่สอง: คำตอบกลับมาหรือไม่
ไคลเอนต์ต้องมีเส้นทางไปยัง NAS และเครือข่าย NAS ต้องมีเส้นทางตอบกลับไปยังพูล VPN การส่งต่อที่เกตเวย์ กฎไฟร์วอลล์ และการแปลที่อยู่โดยเจตนาต่างก็มีผลต่อคู่นี้ บันทึกของ strongSwan เกี่ยวกับการส่งต่อ อธิบายทางเลือกของเส้นทางตอบกลับและการแปลสำหรับซับเน็ตส่วนตัวที่อยู่หลังเกตเวย์
เมื่อคำขอมาถึงและคำตอบออกไปทางเกตเวย์อื่น ไม่มีการเปลี่ยน DNS ใดซ่อมความไม่สมมาตรนี้ได้ การดักจับทั้งสองด้านจะชี้ขาดได้ในครั้งเดียว และยังแสดงว่าการแปลเขียนที่มาใหม่ซึ่ง NAS ตอบหรือไม่ ผู้ดูแลระบบรับผิดชอบขอบเขตนี้ อนุญาตเฉพาะบริการที่จำเป็นและช่วงไคลเอนต์ VPN และบันทึกว่าเลือกการกำหนดเส้นทางหรือการแปล
เงื่อนไขที่สาม: บริการอยู่ที่นั่นและได้รับอนุญาตหรือไม่
หน้าจัดการและบริการแชร์ไฟล์เป็นปลายทางต่างกันบนเครื่องเดียวกัน และอย่างหนึ่งอาจรับการเชื่อมต่อได้ในขณะที่อีกอย่างถูกไฟร์วอลล์ของโฮสต์ การตั้งค่าบริการ หรือสิทธิ์การแชร์ปิดกั้น อุปกรณ์ที่ตอบด้วยการปฏิเสธได้พิสูจน์สองเงื่อนไขแรกแล้ว ซึ่งทำให้เงื่อนไขที่สามแคบลงมาก
ทดสอบด้วยบัญชีที่ต้องการไฟล์จริง ไม่ใช่บัญชีผู้ดูแลที่ใช้ตอนติดตั้ง เพราะสิทธิ์ผู้ดูแลไม่สามารถซ่อมเส้นทางที่หายไปได้ และเส้นทางก็ให้สิทธิ์การแชร์ไม่ได้ ชื่อก็อยู่ในขอบเขตนี้ด้วย ชื่อ NAS ที่ค้นพบที่บ้านมักขึ้นกับ multicast ท้องถิ่นซึ่งอุโมงค์ที่กำหนดเส้นทางไม่พาไป ดังนั้นลองชื่อโฮสต์ส่วนตัวที่ผู้ผลิตเอกสารไว้หรือที่อยู่เองเพื่อแยกการตั้งชื่อออกจากการเข้าถึง
ทดสอบจากภายนอกเครือข่าย NAS แล้วค่อยขยายอย่างช้าๆ
การทดสอบบน LAN เดียวกันซ่อนทุกส่วนที่ไม่สมบูรณ์ของเส้นทางระยะไกล ด้วยเหตุนี้ความพยายามระยะไกลครั้งแรกที่สำเร็จจึงสมควรได้รับการบันทึกในบันทึกการเปลี่ยนแปลง ทำการตรวจจากไคลเอนต์ที่เข้าถึง NAS ผ่านอุโมงค์เท่านั้น และเก็บข้อความข้อผิดพลาดดั้งเดิมของแต่ละครั้ง
nc -vz 10.40.7.25 445
smbclient -L 10.40.7.25 -U guestเมื่อเส้นทางทำงานแล้ว ให้ถ่ายโอนไฟล์ที่ไม่เป็นอันตรายและยืนยันพฤติกรรมการอ่านหรือเขียนที่คุณต้องการจริง หากการถ่ายโอนขนาดใหญ่ติดขัดในขณะที่ขนาดเล็กสำเร็จ ปัญหาที่เหลือคือการจัดการขนาดแพ็กเก็ตหรือความเสถียรของการเชื่อมต่อ ไม่ใช่การกำหนดที่อยู่
อย่าเปิดพอร์ตแชร์ไฟล์หรือการจัดการสู่อินเทอร์เน็ตเพื่อเลี่ยงปัญหาที่อธิบายไม่ได้ ซ่อมเส้นทางส่วนตัว รักษาซอฟต์แวร์ NAS ให้ได้รับการสนับสนุน และทดสอบการกู้คืนทุกสิ่งที่คุณสำรองข้อมูลผ่านมันก่อนจะพึ่งพาแบ็กอัปนั้น