สวิตช์ตัดการเชื่อมต่อสำหรับไซด์คาร์ VPN: สกัดกั้นทราฟฟิกเมื่อมันออกไป
การแชร์เนมสเปซของคอนเทนเนอร์ VPN ไม่ได้หยุดแอปเมื่ออุโมงค์ตาย เพิ่มนโยบายขาออกที่ชัดเจนและทดสอบการรีสตาร์ต ไม่ใช่แค่การตัดการเชื่อมต่อ
คอนเทนเนอร์แอปพลิเคชันที่แชร์เนมสเปซเครือข่ายของคอนเทนเนอร์ VPN ไม่มีอินเทอร์เฟซของตัวเอง จึงเป็นเรื่องง่ายที่จะคิดว่ามันส่งอะไรไม่ได้เมื่ออุโมงค์ล่ม ข้อสันนิษฐานนั้นผิดในโหมดความล้มเหลวที่สำคัญ หากโปรเซส VPN ตายในขณะที่เนมสเปซยังอยู่ แอปจะยังคงถือซ็อกเก็ตของตนและเนมสเปซยังคงมีเส้นทางของตน และทราฟฟิกจะดำเนินต่อไปบนเส้นทางที่ยังติดตั้งอยู่ สวิตช์ตัดการเชื่อมต่อที่แท้จริงคือ นโยบายการกรองที่ชัดเจนพร้อมการทดสอบวงจรชีวิตของรันไทม์ ไม่ใช่การพึ่งพาตอนเริ่มระบบ
ทำไมการแชร์เนมสเปซจึงไม่ใช่สวิตช์ตัดการเชื่อมต่อ
การแชร์เนมสเปซหมายความว่าแอปใช้อินเทอร์เฟซ ที่อยู่ และตารางเส้นทางของคอนเทนเนอร์ VPN มันขจัดเส้นทางอิสระของแอปไปยังเครือข่ายตราบเท่าที่เนมสเปซที่แชร์ยังสมบูรณ์ และไม่ได้บอกอะไรเลยเกี่ยวกับสิ่งที่เนมสเปซนั้นจะทำเมื่ออุโมงค์หายไป
เงื่อนไขการพึ่งพาของ Compose สามารถเลื่อนการเริ่มต้นของแอปออกไปได้จนกว่าการพึ่งพาจะแข็งแรง สิ่งนั้นครอบคลุมเพียงช่วงเวลาหนึ่งและไม่ครอบคลุมความล้มเหลวในภายหลัง จึงเป็น เครื่องมือจัดลำดับการเริ่มต้น ไม่ใช่ไฟร์วอลล์ขาออกที่ต่อเนื่อง.
เกิดอะไรขึ้นจริงเมื่อคอนเทนเนอร์ออกไป
แยกแยะสามเหตุการณ์ โปรเซส VPN ภายในคอนเทนเนอร์อาจตายในขณะที่คอนเทนเนอร์ยังทำงานอยู่ คอนเทนเนอร์อาจหยุดหรือถูกลบ ซึ่งทำลายเนมสเปซ คอนเทนเนอร์อาจถูกสร้างใหม่ ซึ่งสร้างเนมสเปซใหม่และกฎใหม่
ในกรณีแรกเนมสเปซยังอยู่ เส้นทางเริ่มต้นอาจยังชี้ไปที่อินเทอร์เฟซกายภาพ และแอปยังคงส่งโดยตรง ในกรณีที่สองแอปที่พึ่งพามักสูญเสียการเชื่อมต่อทั้งหมด เพราะเนมสเปซของมันหายไป ในกรณีที่สามแอปอาจเชื่อมต่อใหม่กับเนมสเปซใหม่ก่อนที่อุโมงค์จะพร้อม แต่ละกรณีต้องใช้การทดสอบที่ต่างกัน และการออกแบบที่ครอบคลุมเฉพาะการตัดการเชื่อมต่ออย่างเป็นระเบียบก็ครอบคลุมกรณีที่น่าสนใจน้อยที่สุด
สร้างนโยบายขาออกที่ชัดเจน
เขียนนโยบายไว้ภายในเนมสเปซที่แชร์เพื่อให้มีผลกับแพ็กเก็ตของแอป รูปแบบคือการทิ้งโดยค่าเริ่มต้นพร้อมข้อยกเว้นแคบ ๆ: loopback อินเทอร์เฟซของอุโมงค์ และที่อยู่กับพอร์ตของปลายทางที่เฉพาะเจาะจงซึ่งการขนส่งของอุโมงค์ต้องการ
ข้อยกเว้นของปลายทางต้องมีอยู่ก่อนที่อุโมงค์จะขึ้น มิฉะนั้นไคลเอนต์ VPN จะไปถึงเซิร์ฟเวอร์ของตนไม่ได้ นี่คือเหตุผลที่ชุดกฎอนุญาตการขนส่งภายนอกอย่างชัดเจน แทนที่จะอนุญาตอินเทอร์เฟซกายภาพโดยทั่วไป เพิ่มกฎ IPv6 ด้วยหากเนมสเปซมีการเชื่อมต่อ IPv6 เพราะนโยบายที่ครอบคลุมเฉพาะ IPv4 จะเปิดตระกูลที่อยู่อีกตระกูลไว้
DNS ก็เป็นส่วนหนึ่งของนโยบาย หากแอปแก้ชื่อผ่านตัวแก้ที่เข้าถึงได้เฉพาะภายในอุโมงค์ กฎการทิ้งจะทำให้การแก้ชื่อหยุดชะงักเมื่ออุโมงค์ลง และนั่นคือพฤติกรรมที่ถูกต้องสำหรับสวิตช์ตัดการเชื่อมต่อ ตัดสินใจอย่างตั้งใจว่านั่นคือสิ่งที่คุณต้องการหรือไม่
ทดสอบวงจรชีวิต ไม่ใช่แค่การตัดการเชื่อมต่อ
ส่งคำขอใหม่ที่ไม่เป็นอันตรายในขณะที่อุโมงค์แข็งแรง จากนั้นฆ่าโปรเซส VPN แล้วส่งอีกครั้ง ทำซ้ำหลังคอนเทนเนอร์หยุด หลังรีสตาร์ต และหลังการสร้างใหม่ คำขอใหม่สำคัญเพราะการเชื่อมต่อที่มีอยู่แล้วอาจอยู่รอดจากการเปลี่ยนกฎที่บล็อกการเชื่อมต่อใหม่
อย่าพึ่งการตรวจสอบสุขภาพหรือการค้นหา IP ขาออกเป็นกลไกในการบล็อก การตรวจสอบเพียงสังเกตสถานะและรายงานมัน นโยบายต่างหากที่ควบคุมทราฟฟิก ทั้งสองอย่างเป็นส่วนหนึ่งของการติดตั้งเดียวกัน และไม่ใช่สิ่งทดแทนกัน
บันทึกกฎไว้เพื่อให้การทดสอบอยู่รอดจากการอัปเดต
เขียนผลลัพธ์ที่คาดหวังของแต่ละกรณีความล้มเหลวลงในเอกสารการติดตั้ง พร้อมกฎที่นำไปใช้ บันทึกนั้นทำให้การทดสอบชุดเดียวกันรันได้หลังการอัปเดตอิมเมจหรือการอัปเกรดรันไทม์ เมื่อพฤติกรรมของเนมสเปซหรือเส้นทางเริ่มต้นอาจเปลี่ยนโดยไม่มีใครแก้ไขไฟล์ compose
แยกเส้นทางภายนอกที่จำเป็นของปลายทาง VPN ออกจากทราฟฟิกขาออกของแอปที่ไม่จำกัด และเก็บ DNS กับ IPv6 ไว้ในขอบเขตที่ตั้งใจ นโยบายที่อนุญาตอินเทอร์เฟซกายภาพทั้งหมดเพื่อความสะดวกหมายความว่าสวิตช์ตัดการเชื่อมต่อหายไป เอกสารเครือข่ายของ Docker อธิบายการจัดวางเนมสเปซที่แชร์ซึ่งนโยบายนั้นสร้างขึ้น และนั่นคือแหล่งอ้างอิงที่ต้องตรวจเมื่อพฤติกรรมของรันไทม์เป็นที่น่าสงสัย