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

โซนอยู่ได้จนกว่าอินเทอร์เฟซจะถูกสร้างขึ้นใหม่

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

ตรรกะเดียวกันอธิบายพฤติกรรมตอนรีบูต การผูกแบบรันไทม์ไม่รอดจากการรีสตาร์ต และการผูกแบบถาวรใช้ได้เฉพาะกับอุปกรณ์ที่ firewalld คิดว่าเป็นของตน

ก่อนจะเปลี่ยนอะไร ให้หาว่าคอมโพเนนต์ใดเป็นผู้กำหนดโซน

อ่านสามสิ่งก่อนจะเปลี่ยนอะไร

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

บันทึกชื่ออุปกรณ์จริงในแต่ละขั้นด้วย เพราะอุโมงค์ที่ลงบน tun0 วันนี้อาจลงบน tun1 พรุ่งนี้

การผูกที่บันทึกไว้กับชื่อทั่วไปไม่ใช่การตรวจสอบตัวตน และการจดสองนาทีประหยัดการเดาหนึ่งชั่วโมง

เมื่อ NetworkManager เป็นเจ้าของการเชื่อมต่อ

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

การเปลี่ยนคุณสมบัตินั้นอาจส่งผลต่อการเชื่อมต่อที่ใช้งานอยู่ทันที

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

เมื่อ firewalld เป็นเจ้าของการผูก

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

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

อย่า โยนอินเทอร์เฟซเข้าไปใน trusted เพียงเพื่อให้แอปพลิเคชันทำงาน

ทดสอบการโหลดใหม่ การเชื่อมต่อใหม่ และการรีบูต

การเปลี่ยนแปลงจะเสร็จก็ต่อเมื่อผ่านทั้งสามอย่าง

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

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

เขียนเจ้าของ ค่า และผลลัพธ์ที่คาดหวังลงใน runbook แล้วการกำหนดครั้งถัดไปจะอธิบายได้

บทความที่เกี่ยวข้อง