Git 403 dengan VPN Disambungkan: Cari Pihak yang Menjawab

Ia berfungsi pada Wi-Fi pejabat dan gagal pada hotspot telefon, dengan VPN disambungkan dalam kedua-dua kes. Git memulangkan 403 dan ralat itu tiga baris panjangnya. Godaan ialah menganggap hotspot sebagai punca dan menukar tetapan rangkaian sehingga sesuatu berubah. HTTP 403 bermaksud pelayan memahami permintaan itu dan menolaknya, jadi soalan yang berguna ialah pelayan yang mana, dan langkah seterusnya yang berguna ialah perbandingan yang menukar satu perkara pada satu masa.

Baca status sebelum rangkaian

403 bukan kegagalan carian, tamat masa TCP, atau jabat tangan TLS yang tidak pernah selesai. Ia ialah keputusan, dibuat oleh sesuatu yang menghuraikan permintaan anda.

Sehingga anda tahu apa yang membuat keputusan itu, setiap perubahan rangkaian yang anda cuba ialah tekaan dengan cerita yang masuk akal.

Siapa boleh menjawab dengan 403?

Aplikasi repositori hanyalah satu calon. Proksi, gerbang atau perkhidmatan penapisan boleh duduk di hadapannya dan menjawab dahulu, dan klien melihat status yang sama dalam kedua-dua keadaan. Simpan status, pengepala berkaitan dan badan ralat yang telah disunting, kemudian kaitkan dengan log perkhidmatan yang dibenarkan. URL jauh dan titik akhir yang sebenarnya dicapai juga boleh berbeza melalui DNS atau konfigurasi proksi, jadi periksa alamat yang dikonfigurasikan dan proses yang membuat permintaan.

Jika penolakan itu tidak pernah sampai ke repositori, lognya akan senyap, dan kesenyapan itu ialah bukti.

Bandingkan satu pemboleh ubah pada satu masa

Perbandingan hotspot berguna kerana ia menyempitkan masalah, bukan kerana ia membuktikan punca. Dua rangkaian boleh berbeza dalam pengalamatan, keluarga IP, proksi, rundingan TLS dan dasar keluar pada masa yang sama.

Tukar satu perkara bagi setiap percubaan dan catat yang lain. Jadual di bawah ialah minimum yang saya simpan dalam nota semasa melakukan ini:

Satu baris yang berbeza antara larian yang berfungsi dan yang gagal ialah tempat jam berikutnya pergi.

Penyelesaian sementara ialah bukti, bukan penjelasan

Memaksa keluarga alamat lain boleh menukar destinasi, laluan atau perantara yang dipilih, jadi ia boleh mengubah hasil tanpa membuktikan bahawa IPv6 tidak serasi dengan repositori. Versi TLS yang dirundingkan secara berbeza ialah pemerhatian dalam kategori yang sama. Kedua-duanya tidak membenarkan semakan sijil dimatikan atau sambungan dilemahkan. Ikut dasar dan log komponen yang menolak sehingga keputusan sebenar dan bukan berhenti pada perubahan pertama yang berkesan.

Penyelesaian sementara yang anda tidak dapat jelaskan akan gagal lagi di tempat lain.

Tulis laporan yang akan diperbaiki

Berikan kepada pemilik pihak yang menjawab operasi yang sama, dua laluan, dan komponen yang berkata tidak. Buang pengepala kebenaran, kelayakan terbenam dan butiran repositori peribadi sebelum berkongsi apa-apa.

Laporan yang berguna adalah ringkas, boleh dihasilkan semula, dan menamakan lapisan dan bukan gejala.

Semakan yang saya jalankan, mengikut urutan

Sahkan URL jauh dan titik akhir yang diselesaikan, kemudian tangkap status dan pengepala daripada larian yang gagal. Ulang operasi yang sama pada rangkaian kedua dan bezakan kedua-dua rekod.

Kemudian bawa perbezaan itu kepada komponen yang menjawab:

• Konfigurasi proksi pada klien dan pada rangkaian.
• Dasar keluar atau penapisan di hadapan repositori.
• Skop token atau akaun, termasuk tamat tempoh dan syarat SSO.
• Kebenaran repositori untuk identiti yang diwakili token itu.

Semantik status itu sendiri terdapat dalam RFC 9110, dan ia wajar dipetik apabila anda menulis laporan.