การประกาศพอร์ตของ Docker และแหล่ง VPN: สองจุดที่คุณมองข้าม

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

ความเชื่อผิด: อนุญาตเซิร์ฟเวอร์ VPN แล้วจบ

VPN แบบกำหนดเส้นทางสามารถรักษาที่อยู่ทันเนลของไคลเอนต์ไว้จนถึงโฮสต์ Docker เกตเวย์ที่ทำการแปลแหล่งที่มาสามารถแทนที่ที่อยู่นั้นด้วยของตัวเอง การออกแบบทั้งสองแบบถูกต้องตามกฎ และให้แหล่งที่มาแตกต่างกันสำหรับการกระทำเดียวกันของผู้ใช้

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

แหล่งที่มา: พูลไคลเอนต์หรือเกตเวย์ที่แปลแล้ว

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

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

พอร์ต: DNAT เปลี่ยนหมายเลขที่คุณจับคู่

ในการประกาศผ่านบริดจ์ Linux ปกติด้วย iptables ของ Docker การแมปโฮสต์จาก 8443 ไปยังพอร์ตคอนเทนเนอร์ 443 จะถูกแปลก่อนที่ฟิลเตอร์ส่งต่อจะทำงาน แพ็กเก็ตมาถึงฟิลเตอร์ด้วยพอร์ตปลายทาง 443 กฎที่ตรงกับ 8443 ณ จุดนั้นจะไม่ทำงานเลย แม้ไคลเอนต์จะพิมพ์ 8443

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

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

เชน: DOCKER-USER ไม่ใช่ INPUT

คู่มือ iptables ของ Docker วางนโยบายการส่งต่อของผู้ใช้ไว้ในเชน DOCKER-USER ซึ่งถูกประเมินก่อนกฎการส่งต่อของ Docker เอง กฎที่คัดลอกจากบริการบนโฮสต์ไปยังเชน INPUT จะกรองทราฟฟิกที่ส่งถึงโฮสต์ ไม่ใช่ทราฟฟิกที่ส่งต่อไปยังคอนเทนเนอร์ ความผิดพลาดนี้สร้างกฎที่ดูถูกต้องและไม่มีผลใด ๆ ต่อเส้นทางของคอนเทนเนอร์

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

ตรวจสอบด้วยการเชื่อมต่อใหม่

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

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