เชื่อมต่อ OpenVPN ได้แล้วแต่ ping หรือการแชร์ SMB ใช้ไม่ได้? ตรวจสอบสามด่าน

อุโมงค์ขึ้นมาแล้ว ไคลเอนต์ได้รับที่อยู่ และไม่มีอะไรใน LAN ระยะไกลตอบกลับ ping ล้มเหลว การแชร์ไม่เปิด และบันทึกของ VPN ดูสะอาดเพราะจากมุมมองของมันเซสชันยังปกติ ระหว่างเซสชันนั้นกับไฟล์บนเซิร์ฟเวอร์มีด่านอิสระสามด่าน คือ นโยบายการส่งต่อ พอร์ตที่บริการต้องการ และชื่อที่คุณพิมพ์แทนที่อยู่

แต่ละด่านล้มเหลวด้วยอาการต่างกัน และมีเพียงด่านแรกเท่านั้นที่อยู่บนเซิร์ฟเวอร์ VPN

การส่งต่อคือนโยบายบนเชน FORWARD

การรับฟังของ OpenVPN เกิดขึ้นที่ INPUT จึงเป็นเหตุให้อุโมงค์เชื่อมต่อได้ขณะที่ทุกแพ็กเก็ตที่มุ่งไปยัง LAN ถูกทิ้ง ปริมาณ traffิกที่เข้ามาที่ tun0 และออกผ่านอินเทอร์เฟซ LAN จะผ่าน FORWARD และโฮสต์ที่มีนโยบาย DROP โดยปริยายตรงนั้นจะทิ้งมันอย่างเงียบ ๆ ก่อนจะแตะอะไรอื่น ให้ตรวจสอบทั้ง sysctl และเชน: sysctl net.ipv4.ip_forward และ iptables -L FORWARD -v -n.

อนุญาตทิศทางที่คุณต้องการและคำตอบที่เกี่ยวข้อง เช่น กฎ accept จากอินเทอร์เฟซของอุโมงค์ไปยังอินเทอร์เฟซ LAN พร้อมกฎ stateful สำหรับ traffิก established และ related หาก LAN อยู่หลังเราเตอร์อีกตัว เราเตอร์นั้นต้องมีเส้นทางกลับไปยังกลุ่มไคลเอนต์หรือ source NAT บนเซิร์ฟเวอร์ VPN ยืนยันเส้นทางนั้นด้วย ping เดียวก่อนเพิ่มกฎอื่น เพราะกฎที่ไม่สามารถเข้าถึงได้จะไม่ปรากฏในตัวนับเลย

SMB ต้องการมากกว่าหนึ่งพอร์ต

การแชร์ไฟล์ไม่ใช่บทสนทนา TCP 445 เพียงครั้งเดียว การค้นหาใช้ UDP 137 และ 138 เซสชัน NetBIOS แบบเก่าใช้ TCP 139 และเซสชัน SMB สมัยใหม่ใช้ TCP 445 กฎที่เปิดเพียง 445 ทำให้เกิดกรณีที่น่าหงุดหงิดคือไดรฟ์ที่แมปไว้ใช้งานได้แต่การเรียกดูเครือข่ายไม่ได้ หรือกลับกัน

การถ่ายโอนขนาดใหญ่ผ่านอุโมงค์ก็เจอปัญหา MSS ที่ดูเหมือนการแชร์เสีย SYN ที่ประกาศขนาดเซกเมนต์เต็มของ LAN จะถูกทิ้งเพราะ MTU ที่เล็กกว่าของอุโมงค์ และการเชื่อมต่อจะค้างหลังการจับมือ การจำกัด MSS บนเส้นทางส่งต่อ iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu ช่วยขจัดการหยุดชะงักแบบนั้น ตรวจสอบด้วยการคัดลอกไฟล์ไม่กี่เมกะไบต์แทนการแสดงรายการโฟลเดอร์ เพราะคำตอบเล็ก ๆ ผ่านได้แม้การถ่ายโอนขนาดใหญ่จะไม่ผ่าน

อะแดปเตอร์ของอุโมงค์ปรากฏเป็นโปรไฟล์เครือข่ายใหม่

Windows จัดประเภทอะแดปเตอร์แต่ละตัวเป็นโปรไฟล์เครือข่าย และอะแดปเตอร์อุโมงค์ใหม่มักไปอยู่ใน Public ซึ่งกฎการแชร์ไฟล์และเครื่องพิมพ์ถูกบล็อก นั่นเป็นการตัดสินใจของไฟร์วอลล์บนโฮสต์ที่เซิร์ฟเวอร์ไฟล์ ไม่ใช่ปัญหาเส้นทางบนเซิร์ฟเวอร์ VPN เปลี่ยนหมวดหมู่อย่างตั้งใจด้วย Set-NetConnectionProfile -InterfaceAlias "Ethernet 3" -NetworkCategory Private หลังจากยืนยันว่านโยบายอนุญาต เพราะหมวดหมู่ยังเปลี่ยนว่ากฎขาเข้าใดมีผลด้วย

โปรไฟล์เดียวกันนี้อธิบาย ping ที่ล้มเหลวขณะที่ TCP 445 สำเร็จ เพราะคำขอ echo ถูกทิ้งใน Public โดยปริยาย

ชื่อไม่ได้ข้ามอุโมงค์ที่กำหนดเส้นทางได้เอง

การแปลงชื่อ NetBIOS และการค้นหาในเครื่องพึ่งพาการกระจายสัญญาณที่อุโมงค์แบบกำหนดเส้นทางไม่รองรับ ดังนั้นการพิมพ์ชื่อย่อของเซิร์ฟเวอร์จึงล้มเหลวขณะที่ที่อยู่ใช้งานได้ และการแชร์ดูเหมือนเสียทั้งที่เสียเพียงการค้นหา เพิ่มระเบียน DNS สำหรับเซิร์ฟเวอร์ในตัวแก้ไขที่อุโมงค์แจกให้ หรือใช้ที่อยู่ในทางลัด

หากการติดตั้งยังพึ่ง WINS ให้กำหนดค่าที่ไคลเอนต์แทนการหวังว่าจะมี traffิกกระจายสัญญาณ ทดสอบด้วยที่อยู่ก่อน เพื่อไม่ให้ความล้มเหลวของชื่อถูกเข้าใจผิดว่าเป็นความล้มเหลวของไฟร์วอลล์

ทดสอบทีละชั้นและอ่านความล้มเหลวแรก

ไล่จากล่างขึ้นบน ping เกตเวย์ของอุโมงค์ ping โฮสต์ใน LAN ด้วยที่อยู่ จากนั้นเปิดพอร์ตของบริการด้วย Test-NetConnection -ComputerName 10.8.0.5 -Port 445 และหลังจากนั้นจึงยืนยันตัวตนกับการแชร์ ขั้นแรกที่ล้มเหลวคือชั้นที่ต้องแก้ และทุกขั้นถัดไปเป็นเพียงเสียงรบกวนจนกว่าขั้นนั้นจะผ่าน บันทึกขั้นแรกที่ล้มเหลวไว้ก่อนเปลี่ยนสิ่งใด เพราะการเปลี่ยนแปลงครั้งที่สองจะบดบังผลของครั้งแรก

หากเซิร์ฟเวอร์ VPN ไม่ใช่เราเตอร์ของ LAN ยืนยันเส้นทางขากลับบนเราเตอร์นั้น ก่อนเพิ่มกฎบนเซิร์ฟเวอร์ หากไม่มี คำขอจะไปถึงโฮสต์และคำตอบจะออกตามเส้นทางปริยายไปยังอินเทอร์เน็ต ซึ่งจากฝั่งไคลเอนต์ดูเหมือนการทิ้งของไฟร์วอลล์ทุกประการ

แยกบัญชีสำหรับการแชร์ออกจากข้อมูลเข้าสู่ระบบ VPN ในบันทึกของคุณ เพราะอุโมงค์ที่สำเร็จไม่ได้บอกอะไรเกี่ยวกับสิทธิ์ของไฟล์ การเปิด SMB สู่อินเทอร์เน็ตเพื่อเลี่ยงกฎที่ขาดไปไม่ใช่ทางแก้