สองที่อยู่บริการบนไคลเอนต์ OpenVPN หนึ่งตัว: iroute และ lo

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

นามแฝงเป็นเรื่องท้องถิ่น ความเป็นเจ้าของอยู่ระยะไกล

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

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

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

เพิ่มที่อยู่บนไคลเอนต์อย่างถาวร

วางที่อยู่บริการบน loopback พร้อมคำนำหน้าโฮสต์ เพื่อให้โฮสต์ถือเป็นอินพุตท้องถิ่นไม่ใช่ซับเน็ตที่ต้องเข้าถึง ip address add 10.66.0.10/32 dev lo ทำเช่นนั้นสำหรับที่อยู่หนึ่ง และการทำคำสั่งซ้ำสำหรับที่อยู่ที่สองจำลองบริการสองอย่าง

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

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

เรียกร้องมันในไฟล์ CCD ที่ฮับอ่านจริง

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

รายละเอียดสองอย่างทำลายสิ่งนี้อย่างเงียบ ๆ ชื่อไฟล์ต้องตรงกับชื่อที่เซิร์ฟเวอร์ใช้จริง ซึ่งแตกต่างเมื่อ username-as-common-name อยู่ในเกม และ iroute มีผลเฉพาะในโหมด TUN ที่กำหนดค่าไดเรกทอรีการกำหนดค่าไคลเอนต์ไว้ ดังนั้นบรรทัดเดียวกันจึงไม่ทำอะไรในการติดตั้งแบบบริดจ์ เพิ่มบรรทัดในไฟล์ที่มีอยู่แทนการแทนที่ เพราะมันอาจมีที่อยู่คงที่หรือตัวเลือก push อยู่แล้ว เอกสารอ้างอิง OpenVPN 2.6 อธิบายทั้งไดเรกทอรีและคำสั่งความเป็นเจ้าของ

เคอร์เนลของฮับเองก็ต้องมีเส้นทางไปยังปลายทางเหล่านั้น เพื่อให้ทราฟฟิกที่สร้างในเครื่องเข้าสู่กระบวนการทันเนล route 10.66.0.10 255.255.255.255 ในการกำหนดค่าเซิร์ฟเวอร์ครอบคลุมทราฟฟิกที่เซิร์ฟเวอร์สร้างเอง ขณะที่ไคลเอนต์อื่นต้องการ push "route 10.66.0.10 255.255.255.255" เพื่อเรียนรู้ปลายทางด้วยตนเอง

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

ตรวจสอบนโยบายอินพุตและเส้นทางตอบกลับ

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

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

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

ทดสอบที่อยู่และความเป็นเจ้าของแยกจากกัน

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

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