OpenVPN: local กับที่อยู่ของอุโมงค์ สองซ็อกเก็ตที่ต่างกัน

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

ข้อผิดพลาด bind ระบุที่อยู่โลคอล

เมื่อ OpenVPN รายงานว่าผูกที่อยู่โลคอลไม่ได้ มันกำลังพูดถึงซ็อกเก็ตขนส่ง: ปลายทาง UDP หรือ TCP ที่พาการเชื่อมต่อแบบเข้ารหัสไปยัง peer

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

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

local กับ remote เลือกอะไรจริง ๆ

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

ไม่มีคำสั่งใดในสองตัวนี้เกี่ยวข้องกับที่อยู่ภายในอุโมงค์

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

ip -brief address show
ip route get 203.0.113.10

ที่อยู่ภายในมาจากเซิร์ฟเวอร์

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

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

อินเทอร์เฟซที่ต้องอ่านก็ต่างกัน พารามิเตอร์ ifconfig และคอนฟิกพูลอธิบายด้านใน ขณะที่ remote, local, proto และ nobind อธิบายด้านนอก การแยกรายการสองชุดนี้อธิบายตัวอย่างที่สับสนแทบทุกตัวอย่างที่คุณจะพบในฟอรัม เพราะเหตุนี้ คู่มือ OpenVPN 2.6 จึงบันทึกไว้ในส่วนแยกกัน

กับดัก: อุโมงค์แบบเต็มที่ดักการขนส่งของตัวเอง

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

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

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

นิสัยที่ป้องกันความสับสน

อ่านทุกที่อยู่ในโปรไฟล์และตัดสินว่ามันอยู่ชั้นไหนก่อนแก้ไข

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

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