การแชร์เครือข่ายของคอนเทนเนอร์ VPN: เกิดอะไรขึ้นกับ DNS

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

ขั้นตอนที่ 1: ทดสอบจากแอป ไม่ใช่จากโฮสต์

เรียกค้นหาภายในคอนเทนเนอร์ที่มีปัญหา ไม่ใช่บนโฮสต์และไม่ใช่ในเบราว์เซอร์ docker exec app-container getent hosts db.internal ตอบคำถามเดียวที่สำคัญ: ตัวแก้ไขชื่อของโปรเซสนี้คืนค่าอะไร

ถ้าโฮสต์แก้ชื่อได้แต่คอนเทนเนอร์แก้ไม่ได้ คุณพบข้อบกพร่องแล้ว ทุกอย่างหลังจากนี้คือการเลือกวิธีที่รองรับเพื่อซ่อมมัน

ขั้นตอนที่ 2: อ่านแบบจำลองที่รันไทม์รองรับ

เอกสารเครือข่ายของ Docker บันทึกข้อจำกัดของแฟล็ก DNS สำหรับคอนเทนเนอร์ที่แชร์โหมดเครือข่ายของคอนเทนเนอร์อื่น ใน Compose network_mode: service:vpn ผูกแอปเข้ากับเนมสเปซของคอนเทนเนอร์ VPN และต่อบริการ dns การตั้งค่าไม่ได้ทำงานเหมือนบริการปกติ การแก้ชื่อที่คุณได้คือสิ่งที่เนมสเปซที่แชร์มี.

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

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

ขั้นตอนที่ 3: ติดตามคำค้นจนถึงผู้รับ

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

หน้าเช็ก IP ในเบราว์เซอร์บอกไม่ได้ว่าคำค้นชื่อไปที่ไหน มันบอกว่าการเชื่อมต่อ HTTP หนึ่งครั้งไปที่ไหน

ขั้นตอนที่ 4: ซ่อมสองกลุ่มความล้มเหลวต่างกัน

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

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

ขั้นตอนที่ 5: ทดสอบซ้ำหลังสร้างใหม่

เปลี่ยนการกำหนดค่าผ่านกลไกที่รันไทม์รองรับ แล้วสร้างคอนเทนเนอร์ใหม่แทนการแก้ไขไฟล์ภายในคอนเทนเนอร์ที่กำลังทำงาน ทดสอบชื่อส่วนตัวใหม่ ชื่อสาธารณะใหม่ และคำขอของแอปที่ตามหลังการค้นหา /etc/resolv.conf การแก้ไขภายในคอนเทนเนอร์หายไปเมื่อสร้างใหม่ และจะทำให้คุณเชื่อว่าการซ่อมได้ผลทั้งที่ไม่ได้ผล

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