ไคลเอนต์ OpenVPN แบบบริดจ์ไม่มีอินเทอร์เน็ต? ตรวจสอบกฎ NAT

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

หลักฐานคือตัวนับ ไม่ใช่รายการในตาราง

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

iptables -t nat -L POSTROUTING -v -n

อ่านตัวนับข้างการจับคู่อินเทอร์เฟซก่อน หากช่วงต้นทางถูกแต่ด้านออกผิด การแก้ไขคือคำเดียวในกฎ ไม่ใช่กฎใหม่ทั้งข้อ

หาชื่อที่เคอร์เนลบันทึกจริง

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

ip -brief link

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

เขียนกฎใหม่ให้ชี้ไปที่อุปกรณ์อุโมงค์

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

iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o tap0 -j MASQUERADE

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

การอ่านเชน forward พร้อมตัวนับใช้คำสั่งเดียวและตัดความเป็นไปได้ที่เหลือไปครึ่งหนึ่งก่อนคุณจะแตะกฎอื่น

ทำไมการ์ดจริงจึงไม่เคยตรงกัน

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

ปัญหาต่อมาที่ผู้คนเจอมาจากโครงสร้างเดียวกัน: การกรองเฟรมบนบริดจ์เป็นกลไกแยกจากการกรอง IP หากต้องการจำกัดในระดับเฟรม มัน เป็นเรื่องของการกรองบริดจ์ ไม่ใช่กฎในตาราง IP.

พิสูจน์ให้ครบวงจรแล้วทำให้ถาวร

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

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

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