เว็บไซต์โหลดได้ผ่าน VPN แต่ apt ไปไม่ถึงคลังเก็บแพ็กเกจ

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

เรื่องเดียวที่คุ้มค่าจะพิสูจน์ก่อนคือการตัดสินใจเรื่องใดที่ล้มเหลว

อ่านข้อผิดพลาดก่อนที่จะไปแตะการตั้งค่า

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

คัดลอกบรรทัดที่แน่นอนและชื่อคลังเก็บที่มันระบุไว้ก่อนที่คุณจะเปลี่ยนอะไร ความจำเลื่อนลอยว่า „หมดเวลา“ คือสิ่งที่เปลี่ยนการวินิจฉัยสิบนาทีให้กลายเป็นทั้งบ่าย

APT เก็บการตั้งค่าพร็อกซี่ของตัวเอง

APT อ่าน /etc/apt/apt.conf.d/ ไฟล์ apt.conf หลัก และไฟล์ใดก็ตามที่ APT_CONFIG ระบุ มันไม่อ่านโปรไฟล์พร็อกซี่ของเดสก์ท็อป การตั้งค่าเครือข่ายของ GNOME หรือส่วนขยายของเบราว์เซอร์ ส่วนชั้นรับส่งนั้นเคารพตัวแปรสภาพแวดล้อมของพร็อกซี่ ซึ่งเป็นเหตุผลว่าทำไม export https_proxy=... ที่ใช้งานได้ในเชลล์ของคุณไม่ได้พิสูจน์อะไรเกี่ยวกับตัวจับเวลาที่ทำงานในสภาพแวดล้อมอื่น

ถ่ายสิ่งที่โปรเซสที่ล้มเหลวมองเห็นจริง ๆ: apt-config dump | grep -i proxy

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

ตั้งพร็อกซี่ในที่ที่เจ้าของการกำหนดค่าคาดว่าจะอยู่

สำหรับพร็อกซี่แบบชัดแจ้งที่ผู้ดูแลระบบอนุมัติแล้ว เศษไฟล์เล็ก ๆ ในไฟล์ใหม่ก็เพียงพอ:

Acquire::http::Proxy "http://proxy.corp.example:3128/";
Acquire::https::Proxy "http://proxy.corp.example:3128/";
Acquire::http::Proxy::archive.example.internal "DIRECT";

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

เพิ่มเศษไฟล์เป็นไฟล์ใหม่ที่มีหมายเลข เช่น /etc/apt/apt.conf.d/95proxy การเขียนทับไฟล์ของดิสทริบิวชันหมายความว่าการอัปเดตแพ็กเกจครั้งต่อไปจะย้อนการเปลี่ยนแปลงของคุณอย่างเงียบ ๆ

ข้อมูลรับรองอยู่นอก URI

เอกสารอ้างอิงชั้นรับส่งของ APT ชี้ไปที่ apt_auth.conf สำหรับการยืนยันตัวตน และนั่นคือที่ที่ชื่อผู้ใช้กับรหัสผ่านควรอยู่ การฝังมันไว้ใน URI ของพร็อกซี่จะทำให้มันไปปรากฏในรายการโปรเซส ประวัติเชลล์ และการถ่ายการกำหนดค่าทุกครั้งที่แปะลงในตั๋ว ไฟล์การยืนยันตัวตนต้องมีสิทธิ์ที่เข้มงวด เพราะมันคือที่เก็บข้อมูลรับรอง

ตรวจดูสคีมาด้วย คลังเก็บแบบ HTTPS ยังเข้าถึงได้ผ่านพร็อกซี่แบบ HTTP ชั้นรับส่งเป็นการเลือกแยกจากสคีมาของ URI ของมิเรอร์

ศูนย์ซอฟต์แวร์แบบกราฟิกเป็นส่วนหน้าที่แยกต่างหาก หากมันใช้ PackageKit หรือแบ็กเอนด์แบบ snap เศษไฟล์ APT ก็ไม่ได้เปลี่ยนอะไรสำหรับมัน ดังนั้นให้ยืนยันว่าโปรเซสใดเป็นผู้สร้างคำขอที่ล้มเหลว

ยืนยันเส้นทาง ไม่ใช่แค่รหัสออก

เมื่อเศษไฟล์เข้าที่แล้ว ให้เฝ้าดูคำขอแทนที่จะเชื่อผลลัพธ์สีเขียว apt-get -o Debug::Acquire::http=true update พิมพ์ความพยายามเชื่อมต่อ พร็อกซี่ที่มันเลือก และรหัสตอบกลับ ซึ่งแยกพร็อกซี่ที่ผิดออกจากพร็อกซี่ที่ปฏิเสธคุณ

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

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