ทดสอบ kill switch: วัดช่องว่าง ไม่ใช่แค่การเชื่อมต่อใหม่

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

สองข้อสังเกต สองคำตัดสินแยกกัน

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

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

สร้างโพรบที่วัดเวลาได้

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

while true; do
  printf '%s ' "$(date +%H:%M:%S)"
  curl -sS -o /dev/null -w '%{http_code} %{time_total}\n' --max-time 2 https://example.com || echo "curl-exit-$?"
  sleep 1
done

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

เขียนผลลัพธ์ลงไฟล์และเก็บไว้ ประวัติบนหน้าจอเทอร์มินัลไม่ใช่หลักฐาน และส่วนที่น่าสนใจมักเป็นสามบรรทัดตรงกลาง

ทำให้เกิดความล้มเหลวจริง ไม่ใช่แบบเรียบร้อย

การตัดการเชื่อมต่อจากเมนูของไคลเอนต์เองทดสอบเส้นทางแบบร่วมมือ ซึ่งไคลเอนต์มีเวลาติดตั้งกฎการบล็อกของตน การฆ่ากระบวนการแทน หรือตัดลิงก์ชั้นล่างลง จะทำให้ทดสอบเส้นทางที่ความล้มเหลวจริงใช้

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

อ่านบันทึกเพื่อดูว่าทราฟฟิกที่ได้รับอนุญาตหน้าตาเป็นอย่างไร

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

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

ss -tunp | grep -E 'ESTAB|SYN-SENT'
ip route get 198.51.100.7
resolvectl status | sed -n '1,20p'

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

บันทึกผลลัพธ์ในรูปแบบที่อยู่รอดหลังการอัปเดต

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

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