อะแดปเตอร์ OpenVPN บน Windows หลุดบ่อย? ตรวจสอบ IP ซ้ำ

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

ความแตกต่างนี้สำคัญ เพราะทุกขั้นตอนการแก้ปัญหาที่มุ่งไปที่การกำหนดค่าอุโมงค์จะมองข้ามที่อยู่ซ้ำทางฝั่งเซิร์ฟเวอร์

เริ่มจากบันทึกเหตุการณ์ของ Windows ไม่ใช่บันทึกของไคลเอนต์

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

ดึงเหตุการณ์ล่าสุดออกมาและเปรียบเทียบเวลากับรอบการต่ออายุของอะแดปเตอร์: Get-WinEvent -FilterHashtable @{LogName='System'; Id=4198,4199} -MaxEvents 40 | Format-Table TimeCreated,Id,Message -Wrap ความขัดแย้งทุกสิบห้าวินาทีตรงกับไคลเอนต์ที่ลองที่อยู่เดิมซ้ำกับเจ้าของที่ยังตอบอยู่ ส่วนความขัดแย้งครั้งเดียวตอนเชื่อมต่อชี้ไปที่การชนกันเพียงครั้งเดียว ไม่ว่าจะกรณีใด คำถามถัดไปคือใครยังถือที่อยู่

การจัดวางสามแบบทำให้สองโฮสต์ใช้ที่อยู่เดียว

ถามเซิร์ฟเวอร์ว่าใครถือที่อยู่ตามความเห็นของมัน แล้วถามเครือข่ายว่าใครตอบที่อยู่นั้น grep -H ifconfig-push /etc/openvpn/ccd/* แสดงรายการที่อยู่อุโมงค์ที่ตรึงไว้ทั้งหมดและใบรับรองที่เป็นเจ้าของ ip -4 neigh show dev tap0 แสดงสิ่งที่บริดจ์เรียนรู้ในชั้นที่สอง การเปรียบเทียบสองรายการนี้พบรายการซ้ำส่วนใหญ่ได้ในเวลาไม่ถึงหนึ่งนาที

การจัดวางสามแบบอธิบายได้เกือบทั้งหมด: รายการใน client-config-dir ตรึงที่อยู่หนึ่งสำหรับใบรับรองสองใบ ส่วน tap ที่เชื่อมด้วยบริดจ์ให้เครื่องหนึ่งได้ที่อยู่ที่โฮสต์อื่นมีอยู่แล้วแบบคงที่ หรือไฟล์สัญญาเช่าที่เก่าเกินไปคืนที่อยู่ที่ไคลเอนต์ที่ยังเชื่อมต่ออยู่คิดว่าเป็นของตน กรณีที่สามเจ้าเล่ห์ที่สุด เพราะ ifconfig-pool-persist ใช้ที่อยู่ซ้ำสำหรับไคลเอนต์ที่รู้จักโดยเจตนา

ทำให้ที่อยู่ไม่ซ้ำแทนที่จะแย่งกัน

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

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

รีสตาร์ทตามลำดับที่ถูกต้องและยืนยันว่าแต่ละที่อยู่มีเจ้าของรายเดียว

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

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

เฝ้าดูตลอดรอบการต่ออายุเต็มรอบก่อนปิดตั๋ว

การอ่านที่สะอาดครั้งเดียวไม่ได้พิสูจน์อะไร เฝ้าดูอะแดปเตอร์อย่างน้อยสิบนาทีและบังคับให้เชื่อมต่อใหม่ตรงกลาง: Get-NetIPAddress -InterfaceAlias "OpenVPN*" | Select-Object IPAddress,AddressState ที่อยู่ควรอยู่รอดจากการเชื่อมต่อใหม่และคงอยู่ในสถานะที่ต้องการ

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

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