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

ขั้นตอนที่ 1: หาว่าไคลเอนต์ใดเป็นเจ้าของทางออก

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

ip route get 1.1.1.1
ip route show default
route print

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

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

ขั้นตอนที่ 2: ตรวจสอบตัวแปลงชื่อและพรีฟิกซ์ที่ทับซ้อนกัน

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

resolvectl status
Get-DnsClientServerAddress
dig +short intranet.corp.example

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

หยุดตรงนี้หากพรีฟิกซ์ทับซ้อนกัน ทุกอย่างหลังจากนี้ในรายการถือว่าไม่ทับซ้อนกัน

ขั้นตอนที่ 3: เลือกรูปแบบการแยกที่คงอยู่

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

sudo ip netns add vpn2
sudo ip netns exec vpn2 ip link show
sudo ip netns exec vpn2 curl -sI https://intranet.corp.example/

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

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

ขั้นตอนที่ 4: ตรวจสอบเครือข่ายทั้งสองจากเซสชันเดียวกัน

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

curl -sI https://intranet.corp.example/
curl -sI https://files.personal.example/
ip route get 10.20.30.40

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

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

บทความที่เกี่ยวข้อง