เกตเวย์ VPN ของคุณยังต้องมีวิธีติดตั้งอัปเดต

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

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

เอาต์พุตภายในเครื่องไม่ใช่การส่งต่อไคลเอนต์

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

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

ระบุขั้นตอนที่ล้มเหลว

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

getent hosts deb.debian.org
curl -sSI https://deb.debian.org/debian/dists/stable/Release | head -n 1
apt-get -o Debug::Acquire::https=true update

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

อ่านรายการแหล่งก่อนเพิ่มกฎ

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

เอกสาร การขนส่ง HTTP ใน APT ครอบคลุมการตั้งค่าพร็อกซีตามสภาพแวดล้อมและเฉพาะ APT รวมถึงการเลือกตามโฮสต์ และการขนส่ง HTTPS มีการตั้งค่าการตรวจสอบของตัวเอง เส้นทางที่เบราว์เซอร์ใช้และเส้นทางที่ตัวจัดการแพ็กเกจใช้เป็นเส้นทางที่แยกจากกัน แม้อยู่บนเครื่องเดียวกัน

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

เลือกเส้นทางบำรุงรักษาเพียงเส้นเดียวและยึดเส้นทางนั้น

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

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

ตรวจสอบโดยไม่ทำให้การตรวจสอบอ่อนแอลง

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

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

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