Git 403 saat VPN terhubung: temukan siapa yang menjawab
403 adalah jawaban, bukan putusan tentang VPN. Kenali komponen mana yang menolak permintaan, lalu bandingkan satu variabel setiap kali antar jaringan dan catat apa yang berubah.
Ini berhasil di Wi-Fi kantor dan gagal di hotspot ponsel, dengan VPN terhubung pada kedua kasus. Git mengembalikan 403 dan galatnya tiga baris. Godaannya adalah menganggap hotspot sebagai penyebab dan mengubah pengaturan jaringan sampai ada yang bergerak. HTTP 403 berarti sebuah server memahami permintaan dan menolaknya, jadi pertanyaan yang berguna adalah server yang mana, dan langkah berikutnya yang berguna adalah perbandingan yang mengubah satu hal setiap kali.
Baca status sebelum jaringan
403 bukan kegagalan pencarian, bukan timeout TCP, dan bukan jabat tangan TLS yang tidak pernah selesai. Itu adalah keputusan, yang diambil oleh sesuatu yang mengurai permintaan Anda.
Sampai Anda tahu apa yang mengambil keputusan itu, setiap perubahan jaringan yang Anda coba adalah dugaan dengan cerita yang masuk akal.
Siapa yang bisa menjawab dengan 403?
Aplikasi repositori hanyalah satu kandidat. Proksi, gateway, atau layanan penyaring dapat berada di depannya dan menjawab lebih dulu, dan klien melihat status yang sama pada kedua kasus. Simpan status, header yang relevan, dan isi galat yang sudah dibersihkan, lalu korelasikan dengan log layanan yang diotorisasi. URL jarak jauh dan endpoint yang benar-benar dicapai juga bisa berbeda karena DNS atau konfigurasi proksi, jadi periksa alamat yang dikonfigurasi dan proses yang membuat permintaan.
Jika penolakan tidak pernah mencapai repositori, lognya akan diam, dan keheningan itu adalah bukti.
Bandingkan satu variabel setiap kali
Perbandingan hotspot berguna karena mempersempit masalah, bukan karena membuktikan penyebab. Dua jaringan bisa berbeda pada saat yang sama dalam pengalamatan, keluarga IP, proksi, negosiasi TLS, dan kebijakan keluar.
Ubah satu hal per percobaan dan catat sisanya. Tabel di bawah ini adalah minimum yang saya simpan dalam catatan saat melakukannya:
| Keep constant | Record when it changes |
|---|---|
| Repository, operation and credentials | Resolved address and IP family |
| Git process and configuration | Proxy use and the responding component |
| Intended VPN profile | Actual route and exit seen by the service |
Satu baris yang berbeda antara jalan yang berhasil dan yang gagal adalah tempat jam berikutnya pergi.
Solusi sementara adalah bukti, bukan penjelasan
Memaksa keluarga alamat lain dapat mengubah tujuan, rute, atau perantara yang dipilih, jadi itu dapat mengubah hasil tanpa membuktikan bahwa IPv6 tidak kompatibel dengan repositori. Versi TLS lain yang dinegosiasikan adalah pengamatan dalam kategori yang sama. Keduanya tidak membenarkan menonaktifkan pemeriksaan sertifikat atau melemahkan koneksi. Ikuti kebijakan dan log komponen yang menolak sampai keputusan sebenarnya, alih-alih berhenti pada perubahan pertama yang berhasil.
Solusi sementara yang tidak dapat Anda jelaskan akan gagal lagi di tempat lain.
Tulis laporan yang akan diperbaiki
Berikan kepada pemilik komponen yang menjawab operasi yang sama, dua jalur, dan komponen yang menolak. Hapus header otorisasi, kredensial tersemat, dan detail repositori privat sebelum membagikan apa pun.
Laporan yang berguna itu singkat, dapat direproduksi, dan menyebut lapisan alih-alih gejala.
Pemeriksaan yang saya jalankan, secara berurutan
Pastikan URL jarak jauh dan endpoint yang sudah diresolusi, lalu tangkap status dan header dari jalan yang gagal. Ulangi operasi yang sama di jaringan kedua dan bandingkan kedua catatan.
Lalu bawa perbedaan itu ke komponen yang menjawab:
- Konfigurasi proksi pada klien dan pada jaringan.
- Kebijakan keluar atau penyaringan di depan repositori.
- Cakupan token atau akun, termasuk kedaluwarsa dan ketentuan SSO.
- Izin repositori untuk identitas yang diwakili token.
Semantik statusnya sendiri ada di RFC 9110, dan itu layak dikutip saat Anda menulis laporan.