ทำไมการตอบกลับ UDP ของ OpenVPN จึงออกมาจากที่อยู่ผิด

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

สิ่งที่ไคลเอนต์เห็นเมื่อต้นทางเปลี่ยน

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

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

ตัวเลือก multihome ทำอะไรจริง

คำสั่งนี้เขียนเป็น multihome ในไฟล์กำหนดค่า และเขียนเป็น --multihome บนบรรทัดคำสั่ง และมันทำให้เซิร์ฟเวอร์ UDP ตอบกลับจากที่อยู่ที่แพ็กเก็ตของไคลเอนต์ไปถึง เคอร์เนลส่งที่อยู่ปลายทางเดิมเป็นข้อมูลเสริมตอนรับ และ OpenVPN ใช้ค่านั้นเป็นต้นทางของการตอบกลับ ด้วยเหตุนี้เซิร์ฟเวอร์ที่ฟังอยู่บนที่อยู่ทั่วไป local 0.0.0.0 สำหรับ IPv4 หรือค่าที่เทียบเท่าใน IPv6 จึงทำงานราวกับว่าไคลเอนต์แต่ละรายไปถึงตัวรับฟังเฉพาะของตน ไคลเอนต์ที่เข้ามาทางที่อยู่สาธารณะได้รับการตอบกลับจากที่อยู่สาธารณะ และไคลเอนต์บนที่อยู่ภายในได้รับการตอบกลับจากที่อยู่นั้น ไม่มีสิ่งอื่นบนเส้นทางแพ็กเก็ตเคลื่อนไหว เส้นทาง กฎตัวกรอง และการกำหนดค่าอุโมงค์ยังคงเหมือนเดิมทุกประการ

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

เมื่อที่อยู่ภายในแบบคงที่เป็นค่าเริ่มต้นที่ผิด

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

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

พิสูจน์ต้นทางของการตอบกลับจากภายนอก

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

tcpdump -ni any udp port 1194
ss -lunp 'sport = :1194'
ip route get 203.0.113.10 from 198.51.100.20

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

การกำหนดเส้นทาง การค้นพบ และการกรองยังคงแยกจากกัน

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

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