ข้อผิดพลาด pool ทับซ้อนของ Docker ไม่ใช่ปัญหาเส้นทาง VPN

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

สองข้อผิดพลาดที่ดูคล้ายกัน

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

อาการขณะรันเป็นคำถามเรื่องการเข้าถึง คอนเทนเนอร์ที่ตอบเมื่อวานตอนนี้ไม่ตอบ และมีบางอย่างเปลี่ยนในตารางเส้นทางของโฮสต์ คอนเทนเนอร์ยังคงถือที่อยู่ของมัน คำถามคือที่อยู่นั้นใช้เส้นทางใด

ทั้งสองเป็นปัญหาของแผนที่อยู่ มีเพียงอันเดียวที่เป็นปัญหาของ Docker

อ่าน pool ที่จัดสรรไว้ก่อน

แสดงรายการเครือข่ายและตรวจสอบเครือข่ายที่อาจตัดกัน ซับเน็ตอยู่ในคอนฟิก IPAM และคอนเทนเนอร์ที่เชื่อมต่อถูกแสดงแยกต่างหาก:

docker network ls
docker network inspect EXISTING_NETWORK

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

ipv4_address แบบคงที่บนบริการคือที่อยู่ของคอนเทนเนอร์หนึ่งตัว ไม่ใช่คำจำกัดความของ pool การเปลี่ยนมันไม่ได้ลบการทับซ้อน เพราะการทับซ้อนเกิดระหว่างซับเน็ตของเครือข่าย ไม่ใช่ระหว่างคอนเทนเนอร์ Docker เอกสารอ้างอิง network-create กำหนดให้ซับเน็ตไม่ทับซ้อนสำหรับการจัดสรรผ่านบริดจ์ตามปกติ และอธิบายวิธีเลือกอย่างชัดเจน

เลือกคำนำหน้าที่อยู่รอดผ่าน VPN

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

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

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

เลิกใช้หรือเปลี่ยนเครือข่ายอย่างตั้งใจ

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

หากเครือข่ายที่เลิกใช้แล้วครอบครองการจัดสรรที่ขัดแย้ง ให้ตรวจสอบว่าใครเชื่อมต่ออยู่ก่อนลบ docker network rm ปฏิเสธตราบใดที่ยังมี endpoint ที่ใช้งานอยู่ และ docker stop รับชื่อหรือ ID ของคอนเทนเนอร์ไม่ใช่ชื่อเครือข่าย การหยุดคอนเทนเนอร์ก็ไม่ได้ลบคำจำกัดความเครือข่ายที่ถือ pool อยู่

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

pool เริ่มต้นช่วยได้เพียงการจัดสรรครั้งถัดไป

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

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

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

ลำดับงาน: อ่าน pool ที่จัดสรร เลือกคำนำหน้าที่หลีกเลี่ยงทั้ง Docker และปลายทาง VPN สร้างเครือข่ายใหม่โดยตั้งใจ แล้วทดสอบคำขอหนึ่งครั้งโดยอุโมงค์ขึ้นอยู่