ทุก peer ของ OpenVPN ต้องมีบรรทัด remote หรือไม่? ไม่ทั้งหมด
remote ระบุว่าแพ็กเก็ตแรกไปที่ไหน ไม่ได้เลือกบทบาทไคลเอนต์ เซิร์ฟเวอร์ หรือ TLS อ่านรูปแบบก่อนคัดลอกไปทั้งสองฝั่ง
การกำหนดค่า peer สองชุดถูกนำมาเปรียบเทียบเคียงกัน ชุดหนึ่งมีบรรทัด remote และอีกชุดไม่มี และข้อสรุปคือชุดหนึ่งเสียหาย ข้อสรุปนั้นผิดบ่อยพอที่จะคุ้มค่าแก่การแยกแยะ คำสั่งนี้อธิบายว่าแพ็กเก็ตแรกควรถูกส่งไปที่ใด มันไม่ได้เลือกว่ากระบวนการทำหน้าที่เป็นไคลเอนต์ที่เริ่มต้นหรือเป็นเกตเวย์ที่รออยู่ และไม่ได้ตัดสินว่าฝั่งใดพิสูจน์ตัวตนของตนต่ออีกฝั่ง
remote ระบุอะไรจริง ๆ
รายการ remote ระบุโฮสต์ อาจระบุพอร์ตและการขนส่ง และอาจระบุหลายรายการเช่นนี้เพื่อลองตามลำดับ
การไม่มีรายการดังกล่าวมีความหมายที่ชัดเจนไม่ใช่คลุมเครือ: กระบวนการรออยู่และไม่ดำเนินการกับแพ็กเก็ตจากที่อยู่ใด ๆ เว้นแต่ peer นั้นจะพิสูจน์ตัวตน ดังนั้นเกตเวย์ที่ให้บริการผู้ใช้ที่เคลื่อนที่ย่อมไม่มีเหตุผลจะระบุชื่อใครล่วงหน้า
อ่านรายการนี้ในฐานะความสัมพันธ์ของที่อยู่ การที่ปลายทางไกลจะเชื่อถือได้หรือไม่นั้น ตอบด้วยใบรับรองและตัวเลือกการตรวจสอบ ไม่ใช่ด้วยการที่มีที่อยู่ถูกเขียนลงไป
สามรูปแบบเป็นตัวกำหนดคำตอบ
ไคลเอนต์ที่เคลื่อนที่ต้องมีปลายทาง เพราะต้องเริ่มต้นและไม่รู้ว่าเกตเวย์อยู่ที่ใดหากไม่มีปลายทาง เกตเวย์หลายไคลเอนต์ไม่ต้องมีปลายทางรายผู้ใช้ เพราะไคลเอนต์เข้ามาและพิสูจน์ตัวตน ลิงก์สอง peer ที่ตั้งใจสร้างโดยมีปลายที่รู้จักอาจมีปลายทางที่ฝั่งเดียว ทั้งสองฝั่ง หรือไม่มีเลย ขึ้นอยู่กับว่าฝั่งใดเริ่มต้น
การวางที่อยู่ไคลเอนต์แบบตายตัวลงในเกตเวย์ทั่วไปคือข้อผิดพลาดที่เกิดจากการมองข้ามหมวดหมู่เหล่านั้น มันได้ผลกับ peer รายเดียวที่บันทึกที่อยู่ไว้ และทำให้คนอื่น ๆ เข้าใจผิด
ไม่มีสิ่งใดในคำสั่งนี้เปลี่ยนการกำหนดค่าให้เป็นเซิร์ฟเวอร์หลายไคลเอนต์ และไม่มีสิ่งใดในการมีอยู่ของมันขัดขวางบทบาทเซิร์ฟเวอร์ เอกสารอ้างอิง OpenVPN 2.6 เก็บรายละเอียดอาร์กิวเมนต์ทางเลือกและพฤติกรรมเมื่อไม่มี remote แยกจากกัน ซึ่งเป็นเบาะแสว่าทั้งสองเป็นอิสระต่อกันเพียงใด
| Arrangement | Needs a destination |
|---|---|
| Roaming client | Yes, which gateway to contact |
| Multi-client gateway | No, peers authenticate on arrival |
| Two known peers | Depends on which side initiates |
บทบาทการขนส่งเป็นแกนอื่น
ใน TCP ฝั่งหนึ่งรอและอีกฝั่งหมุนหมายเลข สิ่งเหล่านี้เป็นคำสั่งแยกจากปลายทาง และการผสมกันทำให้ได้คู่ที่ทั้งคู่รอหรือทั้งคู่หมุนหมายเลข
ยังมีบทบาทตัวกรองต้นทางของ TCP ซึ่งเป็นเหตุผลที่ข้อความแบน ๆ ว่าเซิร์ฟเวอร์ไม่เคยมี remote ได้นั้นผิด
ใน UDP ไม่มีการเชื่อมต่อที่ต้องสร้าง ดังนั้นทั้งสองปลายจึงใช้การขนส่ง UDP ที่สอดคล้องกัน และคำสั่งเพียงบอกว่าเล็งไปที่ใด การเปลี่ยนที่อยู่โดย peer ที่พิสูจน์ตัวตนแล้วจะจัดการด้วยพฤติกรรมเฉพาะ ไม่ใช่ด้วยการเพิ่มรายการอีก การทำให้การขนส่งถูกต้องเป็นเงื่อนไขเบื้องต้นที่ปลายทางจะมีความหมาย และการสับสนระหว่างสองสิ่งนี้ทำให้เกิดการกำหนดค่าที่ดูสมเหตุสมผลและไม่เคยจบแฮนด์เชก
ทำไมการไม่มี remote ไม่ใช่ประตูเปิด
กระบวนการที่ไม่มีปลายทางยังคงปฏิเสธทราฟฟิกจาก peer ที่ไม่ได้พิสูจน์ตัวตน และนั่นคือส่วนที่ผู้คนมองข้ามเมื่ออ่านบรรทัดที่หายไปว่าเป็นผู้รับฟังที่เปิดให้ทุกคน
การพิสูจน์ตัวตนและปลายทางเป็นอิสระต่อกัน และสิ่งแรกคือสิ่งที่มีความหมายต่อความไว้วางใจ
ข้อผิดพลาดตรงกันข้ามอันตรายกว่า ที่อยู่ต้นทางแบบตายตัวอาจรู้สึกเหมือนการควบคุมการเข้าถึงเพราะเจาะจงและตรวจสอบง่าย แต่ไม่ได้พิสูจน์สิ่งใดเกี่ยวกับว่าใครอยู่อีกฝั่ง ควรคงการตรวจสอบใบรับรองและคงการตรวจสอบตัวตนที่ผูกใบรับรองกับบทบาทของมันไว้ การแทนที่ด้วยการจับคู่ที่อยู่คือการแลกการควบคุมจริงกับภาพลักษณ์ของมัน
เขียนสิ่งที่การกำหนดค่าสมมติไว้
สำหรับแต่ละฝั่ง บันทึกสามสิ่ง: แพ็กเก็ตแรกไปถึง peer อย่างไร ฝั่งใดรับการขนส่งได้ และแต่ละฝั่งตรวจสอบอะไรเกี่ยวกับอีกฝั่ง
สมมติฐานเหล่านั้นคือการออกแบบ คำสั่งเป็นเพียงการสะกดของมัน
หากสองไฟล์ต่างกัน ให้ตรวจสอบว่าพวกมันแสดงสมมติฐานที่ต่างกันหรือไม่ แทนที่จะสมมติว่าอันหนึ่งผิด คู่ไฟล์ที่สมมาตรไม่จำเป็นและไม่เพียงพอสำหรับอุโมงค์ที่ทำงานได้ และความไม่สมมาตรก็มักเป็นส่วนที่ทำให้โทโพโลยีทำงานได้