การอัปเดตเกตเวย์ VPN ล้มเหลว: อ่านขั้นตอนก่อนเปิดทางออก
การอัปเดตที่ล้มเหลวระบุชื่อขั้นตอน ไม่ใช่พอร์ตที่หายไป จับคู่ข้อความกับเจ้าของ อ่านเส้นทางพร็อกซี แล้วจึงตัดสินใจนโยบายการบำรุงรักษาอย่างตั้งใจ
การปฏิเสธที่จะติดตั้งการอัปเดตความปลอดภัยนั้นห่างจากการกลายเป็นปัญหาของคนอื่นเพียงสัปดาห์เดียวที่แย่ และเกตเวย์ที่รับไคลเอนต์คือที่ที่ง่ายที่สุดในการสร้างนิสัยนี้ สาเหตุปกติไม่ใช่เส้นทางที่หายไปแต่เป็นการตัดสินใจที่หายไป: ไม่มีใครบอกว่าโฮสต์เองควรเข้าถึงที่เก็บได้อย่างไรเมื่อการส่งต่อไคลเอนต์ถูกจำกัดอย่างจงใจ การตัดสินใจนั้นต้องทำอย่างชัดเจน และต้องแคบกว่าการปิดนโยบายขาออกทั้งบ่าย
สี่ขั้นตอน สี่เจ้าของที่ต่างกัน
ความล้มเหลวในการอัปเดตคือขั้นตอนที่มีชื่อ ไม่ว่าข้อความจะบอกหรือไม่ และแต่ละขั้นตอนเป็นของเจ้าของที่ต่างกัน ชื่อที่แก้ไม่ได้คือคำถามของตัวแก้ไข การเชื่อมต่อที่หมดเวลาคือคำถามของการขนส่ง พร็อกซี หรือปลายทางไกล ข้อผิดพลาดระบุตัวตน TLS คือคำถามของความไว้วางใจ และข้อมูลเมตาของที่เก็บที่ถูกปฏิเสธคือคำถามของลายเซ็น สี่ขั้นตอน สี่เจ้าของ และกฎพอร์ตตอบได้เพียงหนึ่งในนั้นเสมอ
| The failure text mentions | Which component owns it | What you check first | What you must not change |
|---|---|---|---|
| a name that will not resolve | the resolver policy for this host | which resolver is used, and whether its path is permitted | nothing in the firewall: no repository packet has left yet |
| a connection that times out | routing, proxy or the far end | the destination, port and proxy the manager actually attempts | the egress policy, before you know that destination |
| a TLS identity mismatch | trust configuration and the server's identity | the chain the manager is presented with | verification settings, which only hide the mismatch |
| rejected archive metadata | the repository's signing metadata | whether the source carries valid, trusted metadata | the signature check, which is not a routing question |
ปิงและการแปลงชื่อเป็นสองการทดสอบที่ผู้คนใช้ก่อน และทั้งสองตอบคำถามที่ไม่มีใครถาม การตอบกลับแบบ echo ใช้โปรโตคอลต่างจากการเชื่อมต่อกับที่เก็บ และการค้นหาที่สำเร็จจะหยุดที่การแปลงชื่อโดยไม่ทดสอบการดึงข้อมูล ทั้งสองอย่างอาจผ่านในขณะที่ธุรกรรมจริงล้มเหลว และทั้งสองอาจล้มเหลวด้วยเหตุผลที่ไม่เกี่ยวข้องกับเส้นทาง
อ่านเส้นทางที่ผู้จัดการใช้จริง
ตรวจสอบ URI ต้นทางที่กำหนดค่าไว้และรูปแบบพร็อกซีที่ใช้จริง แทนที่จะสมมติอย่างใดอย่างหนึ่ง กฎที่เขียนสำหรับ HTTP ธรรมดาไม่ใช่การซ่อมแซมเมื่อที่เก็บพูด HTTPS และองค์กรที่บังคับใช้พร็อกซีได้เลือกเส้นทางแล้ว ตัวจัดการแพ็กเกจเคารพตัวแปรสภาพแวดล้อมและการกำหนดค่าของตนเอง และการตั้งค่าเฉพาะโฮสต์สามารถแทนที่การตั้งค่าส่วนกลางได้ สิ่งที่เบราว์เซอร์แบบโต้ตอบทำไม่จำเป็นต้องเป็นสิ่งที่ผู้จัดการทำ
apt-get update -o Debug::Acquire::http=true
apt-config dump | grep -i proxy
env | grep -i proxyเอกสารการขนส่งของ APT อธิบายว่าการตั้งค่าใดใช้กับสคีมา URI ใด และการเลือกเฉพาะโฮสต์เขียนอย่างไร เก็บเอาต์พุตของคำสั่งไว้กับตั๋ว เพราะมันแยกปัญหาพร็อกซีออกจากเส้นทางที่หายไปได้เร็วกว่าผลลัพธ์ปิงจำนวนเท่าใดก็ตาม บันทึกปลายทาง พอร์ต และโปรโตคอลที่แน่นอนที่ผู้จัดการพยายาม และให้การเปลี่ยนแปลงไฟร์วอลล์ขึ้นอยู่กับบันทึกนั้นแทนที่อยู่กระจกที่คาดเดาซึ่งล้าสมัยภายในไม่กี่เดือน
เลือกนโยบายการบำรุงรักษา ไม่ใช่ข้อยกเว้น
นโยบายสามอย่างป้องกันได้: บำรุงรักษาผ่านอุโมงค์ ผ่านพร็อกซีอัปเดตที่จัดการ หรือผ่านเส้นทางตรงที่ได้รับอนุญาตอย่างแคบ แต่ละอย่างสื่อถึงการจัดวางตัวแก้ไขที่สอดคล้องกัน สิ่งที่ป้องกันไม่ได้คือข้อยกเว้นที่กลายเป็นเส้นทางสำรองไร้ขีดจำกัดอย่างเงียบ ๆ ทุกครั้งที่อุโมงค์ล่ม
เขียนนโยบายที่เลือกพร้อมเจ้าของ เพราะผู้ปฏิบัติงานคนถัดไปจะพบกฎไม่ใช่เหตุผลเบื้องหลัง ใช้สิทธิ์ผ่านไฟร์วอลล์ที่มีอยู่และเจ้าของเครือข่าย แทนการล้างกฎหรือเพิ่มผู้จัดการนโยบายคนที่สองสำหรับโฮสต์เดียว ครอบคลุมตระกูลที่อยู่และปลายทางบริการที่แหล่งจริงใช้ และทบทวนรายการเมื่อที่เก็บย้าย
ตรวจสอบโดยไม่ทำให้ความไว้วางใจอ่อนแอ
การขนส่งที่สำเร็จไม่ใช่การอนุญาตให้ผ่อนการตรวจสอบ: การพิสูจน์ตัวตนของที่เก็บและตัวตนของเซิร์ฟเวอร์ TLS เป็นการตรวจสอบสองอย่างที่ต่างกัน และการปิดอย่างใดอย่างหนึ่งทำให้ข้อผิดพลาดหายไปพร้อมกับเปลี่ยนสิ่งที่โฮสต์จะยอมรับ พร็อกซีที่ดักจับเป็นการตัดสินใจด้านความไว้วางใจของเจ้าของเครือข่าย ไม่ใช่เหตุผลในการปิดการตรวจสอบในเครื่อง และข้อมูลรับรองของที่เก็บไม่ควรอยู่ในการวินิจฉัยที่แชร์ เพราะบันทึกละเอียดเป็นที่ที่รั่วไหลได้ง่ายที่สุด
ยอมรับการเปลี่ยนแปลงด้วยการดึงข้อมูลเมตาที่ควบคุมได้ตามด้วยธุรกรรมแพ็กเกจหนึ่งรายการที่อนุมัติแล้ว จากนั้นทดสอบว่าเกิดอะไรขึ้นเมื่ออุโมงค์ล่ม เส้นทางการบำรุงรักษาที่ขยายกว้างขึ้นอย่างเงียบ ๆ ระหว่างเหตุขัดข้องนั้นแย่กว่าเส้นทางที่ล้มเหลวแบบปิด และผลลัพธ์ควรเป็นเส้นทางการอัปเดตที่มีเจ้าของระบุชื่อและขอบเขตจำกัด