ทำไมการแมปพอร์ต VPN ของ Docker ของคุณจึงไปไม่ถึง OpenVPN
พอร์ตโฮสต์ พอร์ตคอนเทนเนอร์ และการขนส่งเป็นสามการตัดสินใจแยกกัน ติดตามความพยายาม UDP หนึ่งครั้งผ่านทุกขอบเขตก่อนแตะใบรับรอง
คอนเทนเนอร์ของคุณสามารถฟังบน UDP 1195 ขณะที่โฮสต์เผยแพร่ 1194 และนั่นถูกต้องตราบเท่าที่การแมปบอกเช่นนั้น ตัวเลขสร้างตารางแปล: ไคลเอนต์หมุนพอร์ตโฮสต์ Docker เขียนปลายทางใหม่เป็นพอร์ตคอนเทนเนอร์ และ OpenVPN ตอบบนพอร์ตที่การกำหนดค่าของมันเองระบุ ความไม่ตรงกันที่จุดเชื่อมใดจุดหนึ่งทำให้เกิดความล้มเหลวเงียบที่ดูเหมือนไฟร์วอลล์ ใบรับรองและไซเฟอร์อยู่ปลายน้ำและไม่สามารถซ่อมแซมได้
ติดตามแพ็กเก็ตหนึ่งผ่านจากไคลเอนต์ไปยังโปรเซสก่อนเปลี่ยนสิ่งใดเกี่ยวกับการรับรองความถูกต้อง
สามตัวเลข หนึ่งการเชื่อมต่อ
ตัวเลขสามตัวคือปลายทางระยะไกลที่ไคลเอนต์ใช้ การแมปที่เผยแพร่บนโฮสต์ และตัวรับฟังภายในคอนเทนเนอร์ ไม่จำเป็นต้องเท่ากัน แต่ต้องต่อกันเป็นลูกโซ่ ตัวเลขที่เท่ากันเป็นกรณีพิเศษที่บังเอิญเป็นกรณีทั่วไปที่สุด จึงง่ายที่จะเขียนความไม่ตรงกันครั้งเดียวและยากที่จะเห็นในภายหลัง
เขียนลูกโซ่เป็นบรรทัดเดียวก่อนดีบัก: ที่อยู่และพอร์ตของไคลเอนต์ การแมปโฮสต์ ตัวรับฟังคอนเทนเนอร์ การขนส่ง ข้อบกพร่องในลูกโซ่จะปรากฏเป็นตัวเลขที่โผล่สองครั้งด้วยค่าที่ต่างกัน
| Location | Example |
|---|---|
| Remote client destination | Host address, UDP 1194 |
| Published mapping | Host UDP 1194 to container UDP 1195 |
| Container listener | OpenVPN on UDP 1195 |
ไวยากรณ์สั้นบอกอะไรจริง ๆ
ในรูปแบบสั้น ด้านซ้ายคือพอร์ตโฮสต์และด้านขวาคือพอร์ตคอนเทนเนอร์ และส่วนต่อท้ายด้วยสแลชเลือกการขนส่ง ถ้าละเว้นส่วนต่อท้าย Docker จะถือว่าการแมปเป็น TCP ดังนั้นตัวรับฟัง UDP ที่อยู่หลังการแมปที่ไม่มีโปรโตคอลคือตัวรับฟังที่ไม่มีใครเข้าถึงได้ ค่าเริ่มต้นนั้นมีเอกสารกำกับและยังทำให้คนที่จับคู่ตัวเลขได้แล้วคิดว่าเสร็จสิ้นต้องประหลาดใจ
รูปแบบยาวกำหนดที่อยู่ผูกและโปรโตคอลอย่างชัดเจน ซึ่งคุ้มกับบรรทัดเพิ่มเติมสำหรับทุกสิ่งที่สุดท้ายออกสู่เครือข่าย อ่านการแมปที่เผยแพร่กลับมาแทนที่จะเชื่อไฟล์ที่สร้างมัน
ports:
- 1194:1195/udpแพ็กเก็ตอาจหยุดที่ใด
คำขออาจถูกทิ้งก่อน Docker ใน Docker หรือที่ตัวรับฟัง ก่อน Docker อาจมีไฟร์วอลล์คลาวด์หรือเราเตอร์ที่ส่งต่อเอง และอุปกรณ์นั้นต้องการพอร์ตที่หันไปทางโฮสต์และการขนส่งที่ถูกต้อง ภายใน Docker การแมปไปยังพอร์ตคอนเทนเนอร์ผิดจะส่งต่อไปยังซ็อกเก็ตที่ปิดอยู่
จากนั้นตัวรับฟัง: การกำหนดค่า OpenVPN ระบุพอร์ตและโปรโตคอล และไคลเอนต์ที่มาถึงพอร์ตอื่นภายในคอนเทนเนอร์ไม่ถึงสิ่งใด การทดสอบบริการ UDP ด้วย TCP ไม่พิสูจน์สิ่งใดในทุกขั้นตอนนี้ ดังนั้นใช้การขนส่งที่ไคลเอนต์จะใช้
ที่อยู่ผูกเป็นตัวกำหนดการเข้าถึง
การแมปที่เผยแพร่ซึ่งผูกกับ loopback เข้าถึงได้จากโฮสต์เท่านั้น ส่วนที่ผูกกับทุกอินเทอร์เฟซเข้าถึงได้ทุกที่ที่ไฟร์วอลล์อนุญาต ทั้งสองดูเหมือนกันในไฟล์ Compose ที่ละเว้นที่อยู่ และค่าเริ่มต้นของ Docker คือแบบกว้าง
ตัดสินใจว่าการติดตั้งต้องการเปิดเผยแบบใด แล้วเขียนอย่างชัดเจน การทดสอบภายในที่เชื่อมต่อผ่าน loopback และไคลเอนต์ระยะไกลที่เชื่อมต่อไม่ได้อาจเป็นคำอธิบายที่ถูกต้องของคอนเทนเนอร์เดียวกันทั้งคู่
อ่านสถานะที่กำลังทำงาน
ตรวจสอบการแมปจริงของคอนเทนเนอร์ที่กำลังทำงานและตัวรับฟังในเนมสเปซเครือข่ายของมัน ไฟล์ Compose อาจถูกแก้ไขหลังจากคอนเทนเนอร์เริ่มทำงาน เมทาดาทาของอิมเมจอาจประกาศพอร์ตโดยไม่เผยแพร่ และคอนเทนเนอร์ที่สองอาจถือพอร์ตโฮสต์อยู่แล้ว การประกาศพอร์ตในอิมเมจไม่ใช่การเผยแพร่ และทั้งสองอย่างก็ไม่เหมือนกับการฟัง
สามสถานะที่ต่างกัน สามคำสั่งที่ต่างกัน และมีเพียงคำสั่งสุดท้ายที่เกี่ยวกับ OpenVPN
เมื่อการแมปถูกต้อง
เมื่อแพ็กเก็ตไปถึง OpenVPN บันทึกของมันคือที่ที่จะอ่านเกี่ยวกับ TLS และการรับรองความถูกต้อง การสร้างใบรับรองใหม่เพื่อซ่อมแพ็กเก็ตที่ไม่เคยมาถึงเป็นงานสูญเปล่าที่เพิ่มตัวแปรที่สอง เก็บบันทึกการแมปไว้ข้างโปรไฟล์ไคลเอนต์เพื่อให้คนถัดไปอ่านบรรทัดเดียวแทนที่จะค้นพบตัวเลขทั้งสามใหม่ การจับแพ็กเก็ตหนึ่งครั้งฝั่งโฮสต์ตัดสินว่าจุดเชื่อมใดในสามจุดผิด และมีค่าใช้จ่ายน้อยกว่าการสร้างใบรับรองใหม่
กรณีที่อธิบายที่นี่คือการเผยแพร่ผ่านบริดจ์ เครือข่ายโฮสต์และที่อยู่คอนเทนเนอร์ที่กำหนดเส้นทางข้ามการแปล ดังนั้นตัวเลขเดียวกันจึงหมายถึงสิ่งอื่นในการออกแบบเหล่านั้น