การลบระเบียน VPN ที่ค้างเก่าออกจากฐานข้อมูล resolvconf

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

ยืนยันว่า resolvconf เป็นเจ้าของสถานะ

ระบุเจ้าของก่อน เพราะอาการเดียวกันภายใต้ systemd-resolved ต้องใช้คำสั่งอื่นและการซ่อมแซมที่ต่างออกไป แพ็กเกจ resolvconf เก็บฐานข้อมูลไว้ใต้ /run/resolvconf และชี้ /etc/resolv.conf ไปยังไฟล์ที่สร้างจากฐานข้อมูลนั้น การอ่านสองอย่างจะตัดสินคำถามนี้ คือเป้าหมายของซิมลิงก์ และแพ็กเกจติดตั้งและทำงานอยู่หรือไม่ เป้าหมายใต้ /run/systemd/resolve หมายถึงการออกแบบอีกแบบหนึ่ง ซึ่งไม่มีสิ่งใดด้านล่างนี้ใช้บังคับ

dpkg -l resolvconf | tail -1
ls -l /etc/resolv.conf
systemctl is-active resolvconf.service

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

ฐานข้อมูลเก็บข้อมูลนำเข้า ไม่ใช่คำตอบ

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

sudo resolvconf --list
sudo resolvconf -i

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

คัดลอกคีย์จากผลลัพธ์แทนที่จะสร้างใหม่ รายการไม่ได้ชื่อ tun0 เพียงเพราะสคริปต์เก่าใช้ชื่อนั้น

พิสูจน์ว่าระเบียนไม่มีเจ้าของ

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

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

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

ตรวจสอบการลบและการเขียนใหม่

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

sudo resolvconf -d "RECORD_KEY_FROM_THE_LIST"
sudo resolvconf --list
resolvectl query host.corp.example || getent hosts host.corp.example

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

resolvconf -u รันเฉพาะสคริปต์อัปเดตเหล่านั้นเท่านั้น มันไม่เคยระบุหรือลบระเบียนที่ล้าสมัย และการสร้างใหม่จากข้อมูลนำเข้าที่เก่าจะสร้างไฟล์ที่ไม่ต้องการเดิมขึ้นมาอีก

ฮุกตัดการเชื่อมต่อที่ถูกฆ่าทิ้งระเบียนไว้

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

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

จากนั้นฝึกวงจรชีวิต เชื่อมต่อ ตัดการเชื่อมต่อ แสดงรายการอีกครั้ง การที่รายการหายไปเองคือหลักฐานเดียวว่าการซ่อมแซมนั้นคงอยู่