Git macet tanpa VPN? OpenSSH menandai paket dengan IPQoS

Kloning dari kantor berhasil, kloning yang sama lewat hotspot ponsel berhasil, dan kloning yang sama dari jaringan hotel menggantung sampai VPN dinyalakan. Jabat tangan SSH selesai dan sesi menjadi diam pada transfer sungguhan pertama. Satu baris yang ditambahkan ke konfigurasi klien menyembuhkan git dan ssh sekaligus. Ketika satu pengaturan klien memperbaiki beberapa alat sekaligus, kesalahannya ada pada apa yang dikirim klien, bukan pada tautan yang dipakainya untuk mengirim.

Baca gejalanya sebagai perbedaan rute

Terowongan yang menyembuhkan masalah jarang merupakan perbaikan. Ia menukar rute, operator, dan perangkat tengah, sementara laptop tetap menghasilkan paket yang persis sama. Jika satu rute salah menangani header dan rute lain meneruskannya tanpa perubahan, perbedaannya ada pada kebijakan perangkat tengah, bukan pada klien. Di sini terowongan adalah saksi, bukan solusi.

Titik tempat sesi mati mempersempitnya lebih jauh. Tidak ada yang gagal pada pencarian nama atau pada pertukaran kunci yang tampak seperti ini. Sesi yang mengautentikasi, mencetak banner, lalu membeku pada penulisan besar pertama sudah membuktikan bahwa perutean, penamaan, dan kredensial semuanya berfungsi.

Klien mencap satu byte QoS pada setiap soket SSH

Setiap koneksi OpenSSH mulai versi 7.8 membawa nilai di header IP yang boleh dipakai router untuk memprioritaskan lalu lintas. Sesi terminal mendapat satu nilai dan salinan massal mendapat nilai lain, dengan teori bahwa manusia yang mengetik lebih pantas mendapat perlakuan baik daripada transfer berkas. Sebagian besar jaringan mengabaikan petunjuk itu sepenuhnya, karena itulah ia luput selama bertahun-tahun. Sebagian kecil driver Wi-Fi, operator seluler, dan konsentrator VPN menindaklanjutinya, dan beberapa di antaranya bertindak buruk.

Ketika nilai itu ditulis ulang atau dibuang di tengah aliran, koneksi tidak gagal, ia berhenti maju. Pengiriman ulang naik, jendela runtuh, dan aplikasi tidak melaporkan apa pun karena tidak ada yang menghasilkan galat. Keheningan itulah sebabnya orang menyebut gejalanya sebagai macet, bukan sebagai kegagalan.

Pastikan dulu versi klien dengan ssh -V. Apa pun pada versi 7.8 atau lebih tinggi membawa perilaku ini secara bawaan.

Tiga perintah yang memisahkan ini dari MTU dan DNS

Dua penyebab serupa patut disingkirkan sebelum menyunting berkas konfigurasi apa pun. Kerusakan MTU meloloskan pertukaran kecil dan membeku pada paket besar pertama, sedangkan kerusakan penamaan tidak pernah menghasilkan sesi sama sekali.

ssh -o IPQoS=none -v [email protected]
ssh -G [email protected] | grep -i ipqos
sudo tcpdump -ni any -vv "tcp port 22"

Perintah pertama mengulang operasi yang gagal dengan penandaan dimatikan, dan jalannya yang berhasil adalah bukti tunggal terkuat yang tersedia. Perintah kedua mencetak konfigurasi yang benar-benar akan diterapkan klien ke tujuan itu, yang menangkap entri usang dalam berkas yang Anda lupakan. Perintah ketiga menunjukkan byte TOS di kedua arah saat transfer macet, dan pola yang menarik adalah adanya nilai pada rute rusak dan tidak ada pada rute yang berfungsi.

Lakukan tangkapan di laptop, bukan di server, karena pengirim yang menetapkan nilai dan kedua arah dapat mengubahnya. Bandingkan rute yang berfungsi dan rute yang gagal dengan tangkapan yang sama, dan perbedaannya muncul tanpa menebak.

Taruh pengecualian dalam satu berkas, satu host setiap kali

Pengecualian semestinya berada di samping host yang dikenainya, dengan komentar yang menjelaskan mengapa ia ada.

Host gitlab.example.internal
    IPQoS none
    # direct route rewrites the marking; the tunnel route passes it

Cakupannya lebih penting daripada nilainya. Entri wildcard mematikan perilaku di mana-mana, membuang petunjuk yang membantu di jaringan yang berperilaku baik, dan tidak menyisakan siapa pun yang bisa mengatakan kapan ia muncul. Entri per host mudah dibaca, dapat dibalik, dan sepele untuk dihapus setelah jaringan diperbaiki. Gunakan berkas pengguna untuk akal-akalan pribadi dan berkas terkelola ketika seluruh armada membutuhkan pengecualian yang sama.

Jelaskan dengan tegas apa yang tidak dicakup pengecualian. Ia berlaku untuk SSH, jadi remote HTTPS, cermin paket, dan peramban semuanya berada di luarnya, dan kegagalan pada salah satunya membutuhkan buktinya sendiri. Pada rantai lewat bastion, setiap lompatan memakai konfigurasi klien, dan lompatan yang macet itulah yang layak dibatasi.

Tutup lingkarannya dengan pemilik jaringan

Serahkan temuannya sebagai empat fakta: versi klien, rute yang diuji, klien VPN yang dipakai, dan arah mana yang membawa penandaan. Keempatnya cukup bagi pemilik jaringan untuk mereproduksi perlakuan itu dan memutuskan apakah itu disengaja.

Jika pengecualian tidak menyembuhkan kemacetan, hapuslah. Akal-akalan yang bertahan dari eksperimen gagal menjadi cerita rakyat, dan orang berikutnya menghabiskan satu jam membuktikan bahwa itu tidak melakukan apa-apa. Jika ia menyembuhkan kemacetan, jalur itu tetap salah bagi setiap alat lain yang melewatinya, dan perbaikannya menjadi tanggung jawab siapa pun yang mengoperasikan perangkat tengah.

Perubahan di klien adalah tambalan sementara dengan tanggal kedaluwarsa. Tuliskan tanggal itu di komentar.