Laman web dimuatkan melalui VPN, tetapi apt tidak sampai ke repositori

VPN bersambung, wiki dalaman dimuatkan dalam pelayar, dan apt update masih tergantung pada cermin yang tidak dapat dicapainya. Dalam gambaran itu tiada apa yang rosak pada terowong. Pelayar dan pengurus pakej telah membuat dua keputusan proksi yang berasingan, dan hanya satu daripadanya dikonfigurasikan.

Keputusan mana yang gagal ialah satu-satunya perkara yang wajar dipastikan dahulu.

Baca ralat sebelum menyentuh tetapan

Setiap peringkat meninggalkan mesej yang berbeza. Nama yang tidak pernah diselesaikan ialah DNS, sambungan yang tidak pernah selesai ialah penghalaan atau firewall, 407 yang muncul serta-merta ialah pengesahan proksi, aduan tentang sijil ialah pengesahan TLS, dan amaran tandatangan ialah metadata repositori. Kelima-lima kegagalan itu memerlukan lima pembaikan berbeza, dan baris proksi yang ditampal di atas masalah DNS hanya memindahkan tersangkut itu.

Salin baris yang tepat dan repositori yang dinamakannya sebelum mengubah apa-apa. Ingatan kabur „ia tamat masa“ ialah yang menukar diagnosis sepuluh minit menjadi satu petang penuh.

APT menyimpan tetapan proksinya sendiri

APT membaca /etc/apt/apt.conf.d/, apt.conf utama dan mana-mana fail yang dinamakan oleh APT_CONFIG. Ia tidak membaca profil proksi desktop, tetapan rangkaian GNOME atau sambungan pelayar. Pengangkutan memang mematuhi pemboleh ubah persekitaran proksi, sebab itulah export https_proxy=... yang berfungsi dalam shell anda tidak membuktikan apa-apa tentang pemasa yang berjalan dalam persekitaran lain.

Dump apa yang sebenarnya dilihat oleh proses yang gagal: apt-config dump | grep -i proxy.

Jalankan itu sebagai pengguna yang menjalankan operasi yang gagal. Jika root membaca set fail yang lain, atau pemasa systemd bermula dengan persekitaran lain, dump akan berbeza, dan perbezaan itulah jawapan anda. Dua nilai proksi yang bercanggah lebih buruk daripada satu nilai yang hilang, kerana pengangkutan mengikut padanan paling khusus yang ditemuinya.

Tetapkan proksi di tempat yang dijangka oleh pemilik konfigurasi

Untuk proksi eksplisit yang diluluskan oleh pentadbir, serpihan kecil dalam fail baharu sudah memadai:

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

Baris ketiga ialah bahagian yang kebanyakan contoh tinggalkan. Kunci setiap hos mengatasi nilai umum, jadi cermin dalaman yang boleh dicapai melalui terowong boleh melangkau proksi sementara semua yang lain masih melaluinya. DIRECT ialah nilai yang didokumenkan untuk itu, bukan rentetan kosong.

Tambahkan serpihan itu sebagai fail bernombor baharu, contohnya /etc/apt/apt.conf.d/95proxy. Menimpa fail edaran bermakna kemas kini pakej seterusnya akan mengembalikan perubahan anda secara senyap.

Kelayakan kekal di luar URI

Rujukan pengangkutan APT menunjuk kepada apt_auth.conf untuk pengesahan, dan di situlah nama pengguna serta kata laluan sepatutnya. Membenamkannya dalam URI proksi meletakkannya dalam senarai proses, sejarah shell dan setiap dump konfigurasi yang ditampal ke dalam tiket. Fail pengesahan memerlukan kebenaran yang ketat, kerana ia ialah stor kelayakan.

Periksa juga skema. Repositori HTTPS masih boleh dicapai melalui proksi HTTP; pengangkutan ialah pilihan berasingan daripada skema URI cermin.

Pusat perisian grafik ialah bahagian hadapan yang berasingan. Jika ia menggunakan PackageKit atau backend snap, serpihan APT tidak mengubah apa-apa untuknya, jadi pastikan proses mana yang membuat permintaan yang gagal.

Pastikan laluan, bukan hanya kod keluar

Setelah serpihan berada di tempatnya, perhatikan permintaan itu daripada mempercayai keputusan hijau. apt-get -o Debug::Acquire::http=true update mencetak cubaan sambungan, proksi yang dipilih dan kod respons, yang memisahkan proksi yang salah daripada proksi yang menolak anda.

Kemudian uji kes yang sepatutnya tidak berfungsi. Putuskan VPN dan pastikan cermin dalaman berhenti menjawab; jika ia masih memuat turun, ada sesuatu yang menghala ke sekeliling terowong atau cache lama yang melayani anda. Pastikan laluan yang dibenarkan masih mengesahkan TLS dan masih memeriksa tandatangan repositori, kerana proksi yang memeriksa trafik bukan alasan untuk mematikan kedua-duanya. Pastikan juga klien yang tidak disahkan menerima penolakan yang jelas dan bukan tamat masa yang senyap.

Simpan serpihan yang berfungsi dan output yang gagal bersama-sama dalam rekod perubahan. Orang seterusnya yang menemui tersangkut yang sama akan mengenali perbezaan dua baris itu lebih pantas daripada mana-mana penjelasan.