การแจ้งเตือนการเข้าสู่ระบบ VPN: เหตุการณ์ใดควรเป็นตัวกระตุ้นจริง ๆ
ความสำเร็จในการพิสูจน์ตัวตน อุโมงค์ที่สร้างขึ้น และ RADIUS accounting Start เป็นข้ออ้างที่แตกต่างกันสามข้อ เลือกข้อที่ผู้รับของคุณลงมือได้ แล้วจึงเชื่อมโยงเข้าด้วยกัน
ความสำเร็จในการพิสูจน์ตัวตน อุโมงค์ที่สร้างขึ้น และ RADIUS accounting Start เป็นข้ออ้างที่แตกต่างกันสามข้อ และอีเมลการเข้าสู่ระบบจะมีความหมายก็ต่อเมื่อคุณเลือกข้อใดข้อหนึ่งเท่านั้น การออกแบบการแจ้งเตือน VPN ส่วนใหญ่ผสมทั้งสามเข้าด้วยกันและสร้างกล่องจดหมายที่ไม่มีใครเชื่อถือ การตัดสินใจขึ้นอยู่กับว่าใครอ่านการแจ้งเตือนและเขาทำอะไรได้ในห้านาทีถัดไป หากทำผิดพลาด การแจ้งเตือนจะกลายเป็นเสียงรบกวนที่ซ่อนเหตุการณ์เดียวที่คุณต้องการ
สามคำถามเป็นตัวกำหนดสิ่งที่กระตุ้น
ถามว่าใครจะได้รับ สิ่งที่เขาจะทำ และการลงมือต้องเร็วเพียงใด ทีมรักษาความปลอดภัยที่เฝ้าดูการนำข้อมูลรับรองไปใช้ในทางที่ผิดต้องการรูปแบบล้มเหลวแล้วสำเร็จจากบัญชีเดียวภายในไม่กี่นาที ทีมปฏิบัติการที่เฝ้าดูขีดความสามารถต้องการระยะเวลาเซสชันและเหตุผลของการตัดการเชื่อมต่อ ไม่ใช่การเข้าสู่ระบบ ฝ่ายช่วยเหลือต้องการตัวตนของเซสชันเพื่อจับคู่กับตั๋วงาน
คำตอบเหล่านั้นชี้ไปที่เหตุการณ์ที่แตกต่างกัน และไม่มีกฎใดกฎเดียวที่ตอบโจทย์ทั้งสามข้อ หากการลงมือของผู้รับคือ «โทรหาผู้ใช้» การพิสูจน์ตัวตนก็เพียงพอ หากการลงมือคือ «ปล่อยใบอนุญาต» หรือ «ตรวจสอบว่าอุโมงค์รับส่งข้อมูลจริงหรือไม่» มีเพียงการสร้างอุโมงค์หรือ accounting Start เท่านั้นที่ใช้ได้ หากการลงมือคือ «ออกใบแจ้งหนี้ตามเวลา» คุณต้องใช้บันทึก Stop ไม่ใช่การเข้าสู่ระบบ
เขียนคำตอบเป็นประโยคเดียวก่อนกำหนดค่าสิ่งใด «อีเมลนี้บอกวิศวกรที่เข้าเวรว่าบัญชี X เปิดอุโมงค์จากเครือข่าย Y เมื่อเวลา Z เพื่อให้เขาตรวจสอบได้ว่ามีการใช้หน้าต่างบำรุงรักษาหรือไม่» หากคุณเติมช่องไม่ได้ครบทุกช่อง แสดงว่ายังไม่ได้เลือกสิ่งที่กระตุ้น
จับคู่เหตุการณ์กับข้ออ้างที่คุณกำลังสร้าง
| Record | What it proves | What it leaves open |
|---|---|---|
| Rejected credentials | The attempt failed at the credential step | Whether it was a stale client or a real person |
| Access-Accept | Credentials passed for this attempt | Anything about tunnel state or policy |
| Policy match record | A rule matched the request | Whether later steps completed |
| Tunnel established | The gateway accepted a session | Whether traffic flowed or the user got an address |
| Accounting Start | User service began at the accounting layer | Whether the application behind it worked |
| Accounting Stop | That session was closed, with a reason field | Whether the reason is meaningful on your release |
ตารางซ่อนความขึ้นต่อกันไว้ แต่ละแถวจะเชื่อถือได้ก็ต่อเมื่อเกตเวย์ส่งออกอย่างเชื่อถือได้และตัวรวบรวมของคุณเก็บฟิลด์ที่คุณต้องการ อ่านนิยามเหตุการณ์ของเวอร์ชันที่คุณใช้งานจริง เพราะชื่อ «เซสชันถูกสร้าง» เปลี่ยนไประหว่างเวอร์ชัน และความหมายเปลี่ยนบ่อยกว่าชื่อ เมื่อนิยามคลุมเครือ ให้ขอไฟล์บันทึกเซสชันแทนการเดาจากป้ายชื่อ
การถือว่า Access-Accept คือการเสร็จสิ้นของทุกอย่างที่ตามมาเป็นความผิดพลาดที่พบบ่อยที่สุด มันเป็นคำตัดสินเกี่ยวกับข้อมูลรับรอง ไม่ใช่เซสชัน ความผิดพลาดในทางกลับกันคือการอ่านการตรงกับนโยบายว่าเป็นหลักฐานของการอนุญาต ทั้งที่กฎอาจตรงกันและขั้นตอนถัดไปก็ยังล้มเหลวได้
หนึ่งเซสชัน หนึ่งการแจ้งเตือน
บัญชีเดียว อุปกรณ์หลายเครื่อง การส่งซ้ำและการเชื่อมต่อใหม่ อีเมลต่อเหตุการณ์จะผิดทั้งสองทาง คือทำซ้ำเซสชันหนึ่งขณะที่แยกอีกเซสชันออกจากกัน ตั้งคีย์การแจ้งเตือนที่เกตเวย์บวกตัวระบุเซสชัน และถือชื่อบัญชีเป็นคุณลักษณะไม่ใช่คีย์ ผู้ใช้ที่มีแล็ปท็อปและโทรศัพท์ถืออุโมงค์สองอันพร้อมกันได้ และทั้งสองสมควรมีบรรทัดของตัวเอง
บันทึกการบัญชีที่ส่งซ้ำเป็นเรื่องปกติ ดังนั้นลบรายการซ้ำตามรหัสเซสชันและตราเวลาก่อนแสดงข้อความ เซสชันต่อเนื่องจากอุปกรณ์เดียวกันควรแยกจากกัน และการเชื่อมต่อใหม่ระหว่างหน้าต่างบำรุงรักษาควรยังมองเห็นได้แทนที่จะรวมเข้ากับเซสชันก่อนหน้า หากตัวรวบรวมของคุณเขียนตราเวลาใหม่ตอนนำเข้า ให้ลบรายการซ้ำตามฟิลด์ของบันทึกต้นฉบับ ไม่ใช่ฟิลด์ที่จัดเก็บไว้
การไม่มีบันทึก Stop คือความไม่แน่นอน ไม่ใช่เซสชันถาวร การรีบูตเกตเวย์ ตัวรวบรวมล่ม และ UDP หาย ล้วนทิ้งช่องว่าง ดังนั้นการแจ้งเตือนต้องมีเส้นทางการกระทบยอดที่สอบถามตารางเซสชันที่ยังทำงานอยู่ก่อนที่ใครจะสรุปว่าอุโมงค์ยังเปิดอยู่
แยกการตรวจสอบออกจากการแจ้งเตือน
กระแสการตรวจสอบและกระแสการแจ้งเตือนมีหน้าที่ต่างกัน เก็บบันทึกดิบไว้ รวมถึงบัญชี เกตเวย์ รหัสเซสชัน ตราเวลา และเหตุผลการสิ้นสุด แม้ในขณะที่อีเมลปกติถูกจัดกลุ่ม ถูกระงับ หรือถูกส่งไปยังรายชื่อเข้าเวรขนาดเล็ก เกณฑ์ความรุนแรงเป็นตัวกรองการนำส่ง ไม่ใช่การเลือกเหตุการณ์ในวงจรชีวิตที่คุณต้องการประกาศ
ส่งบริบทขั้นต่ำที่ผู้รับต้องใช้เพื่อค้นหาบันทึกที่ได้รับการป้องกัน ชื่อบัญชี ที่อยู่ภายใน และรายละเอียดเซสชันเป็นข้อมูลอ่อนไหว และอีเมลที่ส่งต่อได้ดีก็คืออีเมลที่รั่วไหลได้ดี
จากนั้นพิสูจน์ให้ครบวงจร ทำการเข้าสู่ระบบและออกจากระบบปกติ การเชื่อมต่อใหม่ สองเซสชันพร้อมกัน และการทำให้การนำส่งล้มเหลวโดยบังคับ แล้วติดตามเหตุการณ์หนึ่งรายการจากเกตเวย์ผ่านตัวรวบรวมไปจนถึงข้อความที่นำส่งแล้ว หากอีเมลมาถึงโดยไม่มีรหัสเซสชัน สัญญาก็ไม่ครบถ้วน หากอีเมลสองฉบับอธิบายเซสชันเดียว การเชื่อมโยงก็เสียหาย ทั้งสองปัญหาไม่ปรากฏเมื่อสิ่งที่คุณทดสอบมีเพียงการนำส่งอีเมลทำงานได้