ใครเป็นเจ้าของที่อยู่ เส้นทาง DNS และไฟร์วอลล์บน VPN Linux?

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

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

อุปกรณ์และที่อยู่ของมัน

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

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

เส้นทางและกฎนโยบาย

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

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

DNS เป็นเจ้าของแยกเสมอ

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

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

สถานะไฟร์วอลล์ และใครเป็นผู้คืนค่า

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

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

วงจรชีวิต: บูต เชื่อมต่อใหม่ ถอดประกอบ

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

สำหรับการสังเกต ip monitor link address route แสดงการเปลี่ยนแปลงของเคอร์เนลขณะที่เกิดขึ้น แต่รายงานเหตุการณ์ไม่ใช่เจตนา: เส้นทางที่ถูกลบไม่ได้บอกอะไรเกี่ยวกับโปรเซสที่ลบมัน จับคู่กับแผนที่ความเป็นเจ้าของ แล้วการปิดที่สับสนจะกลายเป็นรายชื่อผู้สมัครสั้น ๆ

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