การตรวจสอบ VPN ของ Azure Site: จับคู่สถานะอุโมงค์กับโพรบจริง

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

เริ่มจากอาการที่ล้มเหลว ไม่ใช่จากอุโมงค์

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

ต้องแยกสามสถานะให้ได้: อุโมงค์ล่ม อุโมงค์ขึ้นแต่บริการล้มเหลว และแหล่งตรวจสอบเองไม่พร้อมใช้งาน

วางโพรบไว้ที่ผู้ใช้อยู่

สำหรับแอปจากสาขาไปยัง Azure ให้รันการทดสอบสังเคราะห์จากโฮสต์ในเครือข่ายเวิร์กโหลดของสาขา และชี้ไปยังจุดเข้า HTTPS ส่วนตัวที่ผู้ใช้เข้าถึงจริง โพรบที่เริ่มจากเกตเวย์ใช้ที่อยู่ต้นทางอื่นและมักใช้เส้นทางนโยบายอื่น จึงอาจผ่านได้ขณะที่ผู้ใช้ทุกคนล้มเหลว Azure Connection Monitor รองรับการตรวจ TCP, ICMP และ HTTP พร้อมกลุ่มทดสอบและเกณฑ์ และแหล่งภายในองค์กรมีข้อกำหนดเอเจนต์ที่ต่างจากฝั่ง Azure ตรวจสอบการตั้งค่าที่รองรับในปัจจุบันแทนการคัดลอกสูตรตรวจสอบแบบคลาสสิกที่เลิกใช้แล้วจากบล็อก

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

เลือกการตรวจที่ตรงกับบริการ

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

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

นำทั้งสองสัญญาณเข้า Elastic โดยไม่ประดิษฐ์ขึ้นเอง

เกตเวย์ VPN ส่งเมตริกแพลตฟอร์ม เช่น ไบต์ขาเข้าและขาออกของอุโมงค์ และตัวนับแพ็กเก็ตที่หล่น และสามารถส่งบันทึกการวินิจฉัยในหมวดหมู่ที่รวมเหตุการณ์อุโมงค์และ IKE ผลลัพธ์ของ Connection Monitor มาทาง Azure Monitor เป็นเมตริก และทางเวิร์กสเปซ Log Analytics เป็นบันทึก ไม่มีสิ่งใดปรากฏในดัชนี Elastic ด้วยตัวเอง เลือกไปป์ไลน์ที่รองรับหนึ่งสำหรับเมตริกและอีกหนึ่งสำหรับบันทึก โดยปกติคืออินพุต Azure Event Hub หรือการผสานรวม Azure Monitor และตรวจสอบว่าการผสานรวมที่ติดตั้งไว้รับอะไรจริงก่อนเชื่อรูปแบบดัชนี

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

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

แจ้งเตือนที่ความแตกต่าง ไม่ใช่ที่สี

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

แดชบอร์ดที่เต็มไปด้วยตัวอย่างที่ผ่านของเมื่อวานไม่ควรถูกอ่านว่าเป็นเส้นทางที่แข็งแรงในวันนี้

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