เส้นทางใน OpenVPN ควรอยู่ที่ใด: ฝั่งไคลเอนต์หรือฝั่งเซิร์ฟเวอร์
เส้นทางเปล่าในคอนฟิกของเซิร์ฟเวอร์เปลี่ยนเซิร์ฟเวอร์ ไม่ใช่ไคลเอนต์ เลือกไฟล์ของไคลเอนต์ push แบบทั่วทั้งระบบ หรือ push สำหรับไคลเอนต์รายตัว แล้วตรวจสอบว่าอะไรมาถึง
คุณเพิ่ม route 10.60.0.0 255.255.255.0 ลงในคอนฟิกของเซิร์ฟเวอร์ รีสตาร์ท เชื่อมต่อแล็ปท็อปใหม่ และซับเน็ตก็ยังเข้าถึงไม่ได้จากแล็ปท็อปเครื่องนั้น บรรทัดนั้นถูกยอมรับ บริการเริ่มทำงานอย่างสะอาด และไม่มีอะไรในล็อกที่ดูผิดปกติ สิ่งที่เกิดขึ้นคือเส้นทางถูกติดตั้งบนเครื่องที่คุณแก้ไข: เกตเวย์เชื่อแล้วว่าสามารถไปถึงคำนำหน้านั้นได้ ขณะที่ไคลเอนต์ไม่ได้รับแจ้งอะไรเลย ตำแหน่งคือคำถามทั้งหมด และมีสี่ตำแหน่งที่บรรทัดเดียวกันสามารถอยู่ได้
สี่ตำแหน่งและใครได้รับแต่ละตำแหน่ง
เส้นทางสามารถเพิ่มได้โดยคอนฟิกของไคลเอนต์เอง เสนอให้ทุกไคลเอนต์ผ่าน push แบบทั่วทั้งระบบ เสนอให้ไคลเอนต์รายเดียวผ่านไฟล์เฉพาะไคลเอนต์ หรือเขียนลงในบริบทการกำหนดเส้นทางของเซิร์ฟเวอร์เอง
สี่กรณีนี้ใช้ไวยากรณ์แทบเหมือนกันและให้ผลลัพธ์ที่ต่างกันอย่างสิ้นเชิง สามกรณีแรกส่งผลต่อสิ่งที่ไคลเอนต์ส่งเข้าอุโมงค์ ส่วนกรณีที่สี่ส่งผลต่อวิธีที่เซิร์ฟเวอร์เข้าถึงเครือข่าย ซึ่งมีประโยชน์เมื่อเซิร์ฟเวอร์เองต้องการเส้นทางและเป็นอันตรายเมื่อถูกเข้าใจผิดว่าเป็นการกระจาย
ตัดสินใจว่าต้องการแบบใดในสี่แบบก่อนเขียนบรรทัด แล้วยืนยันผู้รับ
| Placement | Effect | Receiver |
|---|---|---|
| Client profile route | Installed by the client at connect | That client only |
Global push "route ..." | Sent to every client that accepts pushed options | All pulling clients |
| Client-specific push | Sent to the matching client context | One identity |
| Server config route, no push | Added to the server's own table | The gateway itself |
ทำไมเส้นทางเซิร์ฟเวอร์แบบเปล่าถึงทำให้คนประหลาดใจ
คอนฟิกของเซิร์ฟเวอร์เป็นที่แรกที่ผู้ดูแลระบบดู และคำสั่งเส้นทางที่นั่นอ่านราวกับคำแถลงเกี่ยวกับเครือข่าย VPN ซึ่งไม่ใช่ OpenVPN ถือว่ามันเป็นการติดตั้งเส้นทางภายในเครื่องที่รันเดมอน ซึ่งเป็นประเภทการเปลี่ยนแปลงเดียวกับที่คุณจะทำด้วย ip route แล้วลืมไป
การกระจายต้องให้เส้นทางถูก push และ push ต้องให้ไคลเอนต์ดึงไป ไคลเอนต์ที่เริ่มโดยปิดตัวเลือกที่ดึงมาจะเพิกเฉยต่อข้อเสนอทั้งหมด ตรวจสอบทั้งสองปลายของการจับมือนั้นก่อนเขียนไฟล์เซิร์ฟเวอร์ใหม่ เพราะล็อกของเซิร์ฟเวอร์จะไม่บ่น: ฝั่งของมันได้ส่งข้อเสนอไปแล้ว เส้นทางที่ยอมรับยังมีผลเฉพาะการเชื่อมต่อครั้งถัดไป ไม่เคยมีผลในเซสชันที่คุณอยู่แล้ว
เมื่อคุณเห็นทั้งสองเป็นการดำเนินการแยกกัน ความล้มเหลวก็ไม่ลึกลับอีกต่อไป: เซิร์ฟเวอร์ไปถึงคำนำหน้าได้ ไคลเอนต์ไปไม่ถึง และทั้งสองประโยคเป็นความจริงในเวลาเดียวกัน
ไฟล์เฉพาะไคลเอนต์และตัวตนที่มันจับคู่
ไฟล์เฉพาะไคลเอนต์ถูกตั้งชื่อตามตัวตนที่เซิร์ฟเวอร์ตรวจสอบแล้ว ซึ่งโดยค่าเริ่มต้นคือชื่อสามัญของใบรับรอง ชื่อการเชื่อมต่อที่อ่านง่ายในไคลเอนต์เดสก์ท็อปไม่ใช่ค่านั้น และความไม่ตรงกันจะสร้างไฟล์ที่ไม่เคยถูกอ่าน
ตรวจสอบไดเรกทอรีที่เซิร์ฟเวอร์ใช้จริง แล้วยืนยันว่าชื่อไฟล์ตรงกับตัวตนที่ตรวจสอบแล้วอย่างแม่นยำ รวมถึงตัวพิมพ์ใหญ่และเล็ก
grep -n 'client-config-dir' /etc/openvpn/server/server.conf
ls -l /etc/openvpn/ccd/ภายในไฟล์นั้นยังต้อง push เส้นทาง เพราะบริบทเฉพาะไคลเอนต์คือชุดตัวเลือกที่ใช้กับเซสชันของไคลเอนต์นั้น ไม่ใช่ตารางกำหนดเส้นทางภายในเครื่อง เส้นทางเปล่าที่นั่นมีปัญหาเดียวกับเส้นทางเปล่าในไฟล์ทั่วไป
ไฟล์ของไคลเอนต์เองและเครื่องมือที่เป็นเจ้าของ
เส้นทางที่วางในคอนฟิกของไคลเอนต์จะถูกติดตั้งเมื่อไคลเอนต์นั้นเชื่อมต่อและถูกลบเมื่อตัดการเชื่อมต่อ ซึ่งเป็นวงจรชีวิตที่ถูกต้องสำหรับปลายทางแบบคงที่
หากตัวจัดการเครือข่ายเป็นเจ้าของโปรไฟล์ มันอาจนำเข้าตัวเลือกเหล่านั้นครั้งเดียวแล้วเก็บสำเนาของตัวเอง การแก้ไขไฟล์ที่ดาวน์โหลดมาภายหลังไม่เปลี่ยนอะไร ซึ่งเป็นสาเหตุทั่วไปของ "เส้นทางมีอยู่แต่ไม่ถูกใช้"
ตรวจสอบโปรไฟล์ที่ใช้งานอยู่แทนไฟล์ที่คุณดาวน์โหลด และตรวจสอบการตั้งค่าที่นำเข้าซึ่งตัวจัดการแสดง จากนั้นเชื่อมต่อและถามระบบว่าเส้นทางใดที่ที่อยู่เฉพาะใช้ แทนที่จะถือว่าอุโมงค์ชนะเพราะเส้นทางมีอยู่ในไฟล์ข้อความ
ตรวจสอบที่ไคลเอนต์ แล้วตรวจสอบเส้นทางขากลับ
ถามตารางกำหนดเส้นทางของไคลเอนต์เองเกี่ยวกับปลายทาง ไม่ใช่ของเซิร์ฟเวอร์ การค้นหาฮอสต์เดียวภายในคำนำหน้าก็เพียงพอที่จะแสดงอินเทอร์เฟซและฮอปถัดไปที่จะใช้
ip route get 10.60.0.10หากการค้นหาชี้ไปที่อุโมงค์ การกระจายทำงานแล้วและปัญหาที่เหลืออยู่ที่อื่น หากชี้ไปที่เกตเวย์เริ่มต้น แสดงว่าเส้นทางไม่ได้ถูกติดตั้ง ถูกกรองด้วยตัวเลือกฝั่งไคลเอนต์ หรือเป็นของโปรไฟล์ที่ไคลเอนต์ไม่ได้ใช้
สมมติว่าการกระจายทำงานแล้วและยังไม่มีอะไรตอบสนอง: ให้ตรวจสอบการส่งต่อบนเกตเวย์ เส้นทางขากลับของอีกฝั่ง และไฟร์วอลล์ใด ๆ ระหว่างกัน เส้นทางเลือกเส้นทาง มันไม่ได้ให้สิทธิ์เข้าถึง