วิธีตรวจสอบว่าอุโมงค์ VPN บน Linux ทำงานจริงหรือไม่

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

แฟล็กของลิงก์บอกถึงอุปกรณ์ ไม่ใช่เส้นทาง

การตรวจสอบที่ทุกคนคัดลอกกันมองหาที่อยู่ฮาร์ดแวร์ที่เป็นศูนย์ล้วน กลเม็ดนั้นแยกอินเทอร์เฟซจริงออกจากตัวแทนในไดรเวอร์บางตัว และไม่พิสูจน์อะไรในตัวอื่น เพราะอุปกรณ์ tun ไม่มี MAC ให้รายงานตั้งแต่แรก ip -brief link show tun0 ให้แฟล็กแทน: UP หมายถึงผู้ดูแลเปิดอุปกรณ์แล้ว และ LOWER_UP หมายถึงไดรเวอร์ถือว่าลิงก์ใช้งานได้ เมื่ออ่านรวมกันแล้วบอกว่าอุปกรณ์มีอยู่และไม่ได้ถูกปิดในระดับผู้ดูแล ไม่มีตัวใดบอกว่าแพ็กเก็ตมีที่ให้ไป

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

ถามว่าแพ็กเก็ตจะไปที่ไหน

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

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

ตาราง 220 เล่าเรื่องของ IPsec

strongSwan ติดตั้งเส้นทางสำหรับตัวเลือกที่เจรจาแล้วในตาราง 220 เมื่อเปิดการติดตั้งเส้นทาง ip route list table 220 จึงแยกสิ่งที่เจรจาแล้วออกจากสิ่งที่กำหนดเส้นทางแล้ว ตารางว่างข้างการเชื่อมต่อที่โหลดอยู่หมายถึง SA ของ IKE และ CHILD ขึ้นมาแล้ว แต่ไม่มีทราฟฟิกใดถูกส่งเข้าไป ตรวจสอบ ip xfrm state ควบคู่ไปด้วย เพราะมันแสดงรายการสมาคมความปลอดภัยที่ติดตั้งและปลายทางของมัน

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

สถานะของผู้จัดการและสถานะของดีมอนเป็นสองรายการที่ต่างกัน

NetworkManager แสดงเฉพาะการเชื่อมต่อที่มันเป็นเจ้าของ nmcli -t -f NAME,TYPE connection show --active ไม่คืนอะไรสำหรับอุโมงค์ที่เริ่มโดยตรงด้วย wg-quick หรือโดยดีมอน OpenVPN

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

กำหนดขั้นถัดไปด้วยการตรวจสอบที่มันต้องใช้

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

ฮุกดีกว่าการโพลต์เมื่อไคลเอนต์มีให้ --up และ --down ของ OpenVPN ทำงานหลังอินเทอร์เฟซเปลี่ยนสถานะ ซึ่งขจัดความแข่งกันได้ทั้งหมด แต่มันทำงานด้วยสิทธิ์ที่ดีมอนเก็บไว้ หาก OpenVPN ลดลงไปยังบัญชีที่ไม่มีสิทธิ์ผ่าน user และ group ฮุกก็ทำงานในฐานะบัญชีนั้น การรีสตาร์ตบริการของระบบจึงต้องใช้ sudo เพื่ออนุญาตคำสั่งนั้นโดยเฉพาะ มอบการลองใหม่ให้ผู้จัดการบริการแทนลูป cron: นโยบายรีสตาร์ตแบบมีขอบเขตพร้อมขีดจำกัดการเริ่มทำให้อุโมงค์ที่เสียหายปรากฏ ขณะที่ลูปไม่จำกัดซ่อนมันไว้ตลอดไป