อุโมงค์แยกส่วนกับนโยบายบริษัท: กฎไหนชนะ

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

ก่อนจะเถียงเรื่องเช็กบ็อกซ์ ให้หาว่านโยบายมีอยู่เพื่อปกป้องคุณสมบัติใด

คุณสมบัติที่อยู่เบื้องหลังกฎ

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

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

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

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

ทำการตรวจสอบตามลำดับ

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

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

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

ขอข้อยกเว้นที่แคบ

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

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

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

ทำให้ข้อยกเว้นอยู่รอดได้

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

resolvectl query intranet.corp.example
curl -sS -o /dev/null -w '%{http_code}
' https://intranet.corp.example/status

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

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