ไคลเอนต์ VPN ตัวที่สองทำให้ตัวแรกพัง: ค้นหาทรัพยากรที่ใช้ร่วมกัน

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

ไล่ดูสี่ชั้นตามลำดับ

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

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

เริ่มจากบริการที่ไม่ยอมทำงานสองครั้ง

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

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

จากนั้นถามว่าใครเป็นเจ้าของพอร์ต

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

Get-NetUDPEndpoint -LocalPort 500,4500 | Select-Object LocalAddress,LocalPort,OwningProcess
netstat -ano | findstr :500
sudo lsof -nP -iUDP:500
ss -lunp | grep -E ':500|:4500'

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

ไดรเวอร์ฟิลเตอร์อยู่ใต้เส้นทางของคุณ

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

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

ตัดสินใจว่าผลิตภัณฑ์ใดเป็นเจ้าของการบูต แล้วบันทึกไว้

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

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