Situs web termuat lewat VPN, tetapi apt tidak menjangkau repositori
Peramban yang berjalan lewat VPN tidak mengatakan apa pun tentang setelan proksi apt. Baca tahap yang gagal, cetak konfigurasi yang berlaku, lalu setel proksi yang dibaca apt.
VPN tersambung, wiki internal termuat di peramban, dan apt update masih menggantung pada cermin yang tidak dapat dijangkau. Dalam gambaran itu tidak ada yang rusak di terowongan. Peramban dan pengelola paket membuat dua keputusan proksi yang terpisah, dan hanya satu di antaranya yang dikonfigurasi.
Keputusan mana yang gagal adalah satu-satunya hal yang layak dipastikan lebih dulu.
Baca galatnya sebelum menyentuh setelan
Setiap tahap meninggalkan pesan yang berbeda. Nama yang tidak pernah terurai adalah DNS, koneksi yang tidak pernah selesai adalah perutean atau tembok api, 407 yang muncul seketika adalah autentikasi proksi, keluhan soal sertifikat adalah verifikasi TLS, dan peringatan tanda tangan adalah metadata repositori. Kelima kegagalan itu butuh lima perbaikan berbeda, dan satu baris proksi yang ditempel di atas masalah DNS hanya memindahkan kemacetannya.
Salin baris yang persis dan repositori yang disebutnya sebelum mengubah apa pun. Ingatan samar „tadi kehabisan waktu“ adalah yang mengubah diagnosis sepuluh menit menjadi satu sore penuh.
APT menyimpan setelan proksinya sendiri
APT membaca /etc/apt/apt.conf.d/, apt.conf utama, dan berkas apa pun yang disebut APT_CONFIG. Ia tidak membaca profil proksi desktop, setelan jaringan GNOME, atau ekstensi peramban. Transportnya memang menghormati variabel lingkungan proksi, karena itu export https_proxy=... yang berhasil di shell Anda tidak membuktikan apa pun soal pewaktu yang berjalan di lingkungan lain.
Cetak apa yang benar-benar dilihat proses yang gagal: apt-config dump | grep -i proxy.
Jalankan itu sebagai pengguna tempat operasi yang gagal berjalan. Jika root membaca kumpulan berkas yang berbeda, atau pewaktu systemd dimulai dengan lingkungan lain, hasil cetaknya akan berbeda, dan perbedaan itulah jawaban Anda. Dua nilai proksi yang saling bertentangan lebih buruk daripada satu nilai yang hilang, karena transport mengikuti kecocokan paling spesifik yang ditemukannya.
Setel proksi di tempat yang diharapkan pemilik konfigurasi
Untuk proksi eksplisit yang disetujui administrator, potongan kecil di berkas baru sudah cukup:
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 adalah bagian yang dilewatkan sebagian besar contoh. Kunci per host mengalahkan nilai umum, sehingga cermin internal yang terjangkau lewat terowongan bisa melewati proksi sementara sisanya tetap lewat situ. DIRECT adalah nilai yang didokumentasikan untuk itu, bukan string kosong.
Tambahkan potongan itu sebagai berkas bernomor baru, misalnya /etc/apt/apt.conf.d/95proxy. Menimpa berkas distribusi berarti pembaruan paket berikutnya akan mengembalikan perubahan Anda tanpa suara.
Kredensial tetap di luar URI
Rujukan transport APT menunjuk ke apt_auth.conf untuk autentikasi, dan di sanalah nama pengguna serta kata sandi seharusnya berada. Menyematkannya di URI proksi menempatkannya di daftar proses, riwayat shell, dan setiap cetakan konfigurasi yang ditempel ke tiket. Berkas autentikasi perlu izin yang ketat, karena ia adalah penyimpanan kredensial.
Periksa juga skemanya. Repositori HTTPS masih dapat dijangkau lewat proksi HTTP; transport adalah pilihan terpisah dari skema URI cermin.
Pusat perangkat lunak grafis adalah antarmuka terpisah. Jika ia memakai PackageKit atau backend snap, potongan APT tidak mengubah apa pun untuknya, jadi pastikan proses mana yang membuat permintaan yang gagal.
Pastikan jalurnya, bukan hanya kode keluarnya
Setelah potongan terpasang, amati permintaannya alih-alih memercayai hasil yang hijau. apt-get -o Debug::Acquire::http=true update mencetak percobaan koneksi, proksi yang dipilih, dan kode respons, yang memisahkan proksi yang salah dari proksi yang menolak Anda.
Lalu uji kasus yang seharusnya tidak berhasil. Putuskan VPN dan pastikan cermin internal berhenti menjawab; jika masih mengunduh, ada yang merutekan di sekitar terowongan atau tembolok lama yang melayani Anda. Pastikan jalur yang diizinkan masih memverifikasi TLS dan masih memeriksa tanda tangan repositori, karena proksi yang memeriksa lalu lintas bukan alasan untuk mematikan keduanya. Pastikan juga bahwa klien yang tidak terautentikasi mendapat penolakan yang jelas alih-alih batas waktu yang senyap.
Simpan potongan yang berfungsi dan keluaran yang gagal bersama-sama di catatan perubahan. Orang berikutnya yang menabrak kemacetan yang sama akan mengenali selisih dua baris itu lebih cepat daripada penjelasan apa pun.