เข้า LAN ผ่าน OpenVPN ไม่ได้? ตรวจโซน เส้นทาง และทางกลับ

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

ตัวกรองใดเห็นแพ็กเก็ตที่มุ่งไปยัง LAN

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

OpenWrt ทำให้การแยกนี้ตรวจสอบได้ และความแตกต่างนี้คุ้มค่าอ่านสักครั้ง โซนที่สิ้นสุดอุโมงค์ต้องมีกฎส่งต่อไปยังโซน LAN ขณะที่กฎขาเข้าควบคุมเฉพาะบริการบนตัวเราเตอร์เอง หน้าเว็บผู้ดูแลที่ใช้งานได้ควบคู่กับ LAN ที่ตายแล้วเป็นผลลัพธ์ปกติของกฎส่งต่อที่หายไปนั้น

uci show firewall | grep -E "zone\[[0-9]+\]\.(name|input|forward|output)"

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

ทำไมอุโมงค์แบบแยกส่วนจึงต้องมีคำนำหน้าที่ถูกส่ง

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

push "route 192.168.50.0 255.255.255.0"

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

ip route show | grep 192.168.50

คู่หูแบบไซต์ถึงไซต์ต้องการมากกว่าการส่ง คำนำหน้าใดอยู่ข้างหลังคู่นั้น เซิร์ฟเวอร์ต้องเรียนรู้ ซึ่งบรรทัด iroute ในไฟล์ client-config-dir ของมันทำหน้าที่นั้น และตารางของมันเองก็ต้องมีเส้นทางที่ตรงกันเข้าสู่อุโมงค์

คำตอบต้องมีที่อยู่ที่มันไปถึงได้

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

tcpdump -ni tun0 host 192.168.50.20

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

บันไดที่จบในที่ที่ถูกต้อง

การตรวจสอบสี่ข้อระบุชั้น และแต่ละข้อเป็นคำสั่งเดียวไม่ใช่การตัดสิน รันตามลำดับและหยุดที่ความล้มเหลวแรก ลำดับสำคัญกว่าคำสั่ง เพราะขั้นที่ผ่านในภายหลังซ่อนเหตุผลที่ขั้นก่อนหน้าล้มเหลว

ping -c1 10.8.0.1
ping -c1 192.168.50.20
nc -vz 192.168.50.20 445
getent hosts nas.local

ชื่ออยู่ในตอนท้ายของบันได ไม่เคยอยู่ตอนต้น แชร์ที่ตอบในชื่อ 192.168.50.20 แต่ไม่ตอบในชื่อ nas.local บ่งชี้ถึงการแปลงชื่อหรือคำต่อท้ายการค้นหา และการแก้ไขไฟร์วอลล์ไม่สามารถเปลี่ยนอย่างใดอย่างหนึ่ง

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