จำกัดขอบเขตกฎ SNAT ของ OpenVPN ก่อนที่จะทำให้ nginx พัง

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

ยืนยันว่าคอนเทนเนอร์สามารถสร้างอุปกรณ์ tun ได้

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

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

ตัดสินใจว่า MASQUERADE ทำอะไรบนอินเทอร์เฟซนี้

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

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

iptables -t nat -A POSTROUTING -o venet0 -s 10.8.0.0/24 -j SNAT --to-source 203.0.113.10
iptables -A FORWARD -i tun0 -j ACCEPT
iptables -A FORWARD -o tun0 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

หากไม่มีกฎส่งต่อ การแปลยังเกิดขึ้นและเคอร์เนลยังคงปฏิเสธการส่งต่อ การรวมกันนี้สร้างสภาวะสับสนซึ่งตัวนับบนกฎ NAT เพิ่มขึ้นในขณะที่ไคลเอนต์ไม่ได้รับอะไรเลย สองบรรทัด FORWARD ก็ต้องอยู่ก่อนกฎ drop แบบกว้างใด ๆ ในเชนเดียวกัน ลำดับเป็นส่วนหนึ่งของคอนฟิก ไม่ใช่รายละเอียดการนำไปใช้

จำกัดกฎให้เหลือพูลเดียวและอินเทอร์เฟซเดียว

อาการที่สองมีสาเหตุต่างออกไป: กฎ POSTROUTING ที่ไม่มีข้อจำกัดต้นทางและไม่มีข้อจำกัดขาออก กฎเช่นนี้เขียนแพ็กเก็ตทุกใบที่ออกจากโฮสต์ใหม่

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

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

ทำให้กฎคงอยู่ถาวรและค้นหาว่าใครเป็นเจ้าของกฎเหล่านี้

กฎที่เพิ่มด้วยมือจะหายไปเมื่อรีบูต จึงบันทึกด้วย iptables-save หรือจัดการผ่าน netfilter-persistent ในที่ที่ติดตั้งไว้ ยืนยันว่าการคืนค่าทำงานก่อน OpenVPN เริ่ม แล้วรีบูตหนึ่งครั้งโดยเจตนาแทนการค้นพบช่องโหว่ระหว่างเหตุการณ์

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

ตรวจสอบด้วยตัวนับและโฟลว์ที่ดักจับได้หนึ่งรายการ

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

บนเซิร์ฟเวอร์ อ่านตัวนับแพ็กเก็ตบนกฎ NAT และ FORWARD ด้วย iptables -t nat -L -v -n และสังเกตโฟลว์หนึ่งรายการในการดักจับ ถ้าที่อยู่ของไคลเอนต์ปรากฏในการดักจับและไม่มีคำตอบตามมา ช่องว่างอยู่บนเส้นทางขากลับหรือในการกรองของผู้ให้บริการ ไม่ใช่ในโปรไฟล์ไคลเอนต์ เปรียบเทียบต้นทางที่ดักจับได้กับที่อยู่ที่กฎแปลไป เพราะความไม่ตรงกันหมายความว่ากฎอื่นตรงก่อน หนึ่งโฟลว์ที่สังเกตได้ตัดสินได้มากกว่าการอ่านคอนฟิกหนึ่งหน้า

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