VPN หลุดเป็นช่วง ๆ: ต้องบันทึกอะไรทุกครั้ง

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

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

กำหนดฟิลด์ก่อนความล้มเหลวครั้งแรก

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

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

ปล่อยช่องว่างให้เป็นช่องว่าง แม่แบบที่บังคับให้ตอบเชิญชวนให้แต่งเติม และบริบทที่แต่งขึ้นแย่กว่าที่ว่าง

บันทึกห้าข้อเท็จจริงเดิมตอนเกิดความล้มเหลว

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

date -Is
journalctl -u wg-quick@wg0 --since "-2 min" --no-pager
wg show wg0 latest-handshakes transfer
ip route get 203.0.113.10
ping -c 3 -W 2 192.0.2.1

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

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

หาขั้นตอนที่พัง

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

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

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

เปรียบเทียบทีละเงื่อนไข

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

เก็บการรันที่ล้มเหลวไว้ในบันทึก การลบมันเพื่อเลือกอันที่ใช้งานได้คือการทิ้งหลักฐานเดียวของขอบเขตที่คุณกำลังหา

แชร์เฉพาะส่วนตัดตอน ไม่ใช่โปรไฟล์

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

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