Adakah Git tersangkut tanpa VPN? OpenSSH menanda paket dengan IPQoS
OpenSSH menanda paketnya dengan nilai QoS secara lalai. Di tempat laluan membuang tanda itu, push tersangkut sehingga terowong menukar laluan yang dilalui paket.
Klona dari pejabat berfungsi, klona yang sama melalui hotspot telefon berfungsi, dan klona yang sama dari rangkaian hotel tergantung sehingga VPN dihidupkan. Jabat tangan SSH tamat dan sesi menjadi senyap pada pemindahan sebenar yang pertama. Satu baris yang ditambah pada konfigurasi klien menyembuhkan git dan ssh sekali gus. Apabila satu tetapan klien membaiki beberapa alat sekali gus, kesalahannya ada pada apa yang klien hantar, bukan pada pautan yang digunakannya untuk menghantar.
Baca gejala itu sebagai perbezaan laluan
Terowong yang menyembuhkan masalah jarang merupakan pembaikan. Ia menukar laluan, pembawa dan peranti tengah, sementara komputer riba terus menghasilkan paket yang sama. Jika satu laluan salah mengendalikan pengepala dan satu lagi membiarkannya berlalu tanpa diubah, perbezaannya terletak pada dasar peranti tengah, bukan pada klien. Di sini terowong ialah saksi, bukan penyelesaian.
Titik di mana sesi mati menyempitkannya lagi. Tiada apa yang gagal pada carian nama atau pada pertukaran kunci kelihatan seperti ini. Sesi yang mengesahkan identiti, mencetak sepanduk dan kemudian membeku pada penulisan besar pertama sudah membuktikan bahawa penghalaan, penamaan dan kelayakan semuanya berfungsi.
Klien mengecap satu bait QoS pada setiap soket SSH
Setiap sambungan OpenSSH dari 7.8 dan seterusnya membawa nilai dalam pengepala IP yang boleh digunakan oleh penghala untuk mengutamakan trafik. Sesi terminal mendapat satu nilai dan salinan pukal mendapat nilai lain, atas teori bahawa manusia yang menaip wajar mendapat layanan lebih baik daripada pemindahan fail. Kebanyakan rangkaian mengabaikan petunjuk itu sepenuhnya, sebab itulah ia tidak disedari selama bertahun-tahun. Sebilangan kecil pemacu Wi-Fi, pengendali mudah alih dan penumpu VPN bertindak atasnya, dan sesetengahnya bertindak dengan buruk.
Apabila nilai itu ditulis semula atau dibuang di tengah-tengah aliran, sambungan tidak gagal, ia berhenti bergerak ke hadapan. Penghantaran semula meningkat, tetingkap runtuh, dan aplikasi tidak melaporkan apa-apa kerana tiada apa yang menghasilkan ralat. Kesenyapan itulah sebabnya orang menggambarkan gejala ini sebagai tersangkut dan bukan sebagai kegagalan.
Sahkan dahulu binaan klien dengan ssh -V. Apa-apa pada 7.8 atau lebih tinggi membawa tingkah laku ini secara lalai.
Tiga arahan yang memisahkan ini daripada MTU dan DNS
Dua punca yang serupa wajar disingkirkan sebelum menyunting mana-mana fail konfigurasi. Kerosakan MTU membenarkan pertukaran kecil berlalu dan membeku pada paket besar pertama, manakala kerosakan penamaan tidak pernah menghasilkan sesi.
ssh -o IPQoS=none -v [email protected]
ssh -G [email protected] | grep -i ipqos
sudo tcpdump -ni any -vv "tcp port 22"
Arahan pertama mengulangi operasi yang gagal dengan penandaan dimatikan, dan kejayaannya ialah bukti tunggal paling kuat yang ada. Yang kedua mencetak konfigurasi yang sebenarnya akan digunakan oleh klien pada destinasi itu, yang menangkap entri lapuk dalam fail yang anda lupakan. Yang ketiga menunjukkan bait TOS dalam kedua-dua arah semasa pemindahan tersangkut, dan corak yang menarik ialah adanya nilai pada laluan rosak dan tiadanya pada laluan yang berfungsi.
Lakukan tangkapan pada komputer riba dan bukan pada pelayan, kerana penghantar yang menetapkan nilai itu dan kedua-dua arah boleh mengubahnya. Bandingkan laluan yang berfungsi dengan laluan yang gagal menggunakan tangkapan yang sama, dan perbezaannya muncul tanpa meneka.
Letakkan pengecualian dalam satu fail, satu hos pada satu masa
Pengecualian sepatutnya berada di sebelah hos yang dikenainya, dengan komen yang menyatakan mengapa ia wujud.
Host gitlab.example.internal
IPQoS none
# direct route rewrites the marking; the tunnel route passes it
Skop lebih penting daripada nilai itu sendiri. Entri kad liar mematikan tingkah laku di mana-mana, membuang petunjuk yang membantu pada rangkaian yang berkelakuan baik, dan tidak membiarkan sesiapa mengatakan bilakah ia muncul. Entri bagi setiap hos mudah dibaca, boleh diterbalikkan dan remeh untuk dipadam selepas rangkaian dibaiki. Gunakan fail pengguna untuk penyelesaian peribadi dan fail terurus apabila seluruh armada memerlukan pengecualian yang sama.
Nyatakan dengan jelas apa yang tidak dilindungi oleh pengecualian itu. Ia terpakai kepada SSH, jadi repositori jauh HTTPS, cermin pakej dan pelayar semuanya berada di luarnya, dan kegagalan pada mana-mana daripadanya memerlukan buktinya sendiri. Pada rantaian melalui bastion, setiap lompatan menggunakan konfigurasi klien, dan lompatan yang tersangkut itulah yang wajar dibataskan.
Tutup gelung dengan pemilik rangkaian
Serahkan penemuan itu sebagai empat fakta: versi klien, laluan yang diuji, klien VPN yang digunakan, dan arah mana yang membawa penandaan. Empat itu cukup untuk pemilik rangkaian menghasilkan semula layanan itu dan memutuskan sama ada ia disengajakan.
Jika pengecualian tidak menyembuhkan kesesakan itu, hapuskannya. Penyelesaian yang bertahan daripada eksperimen gagal menjadi cerita rakyat, dan orang seterusnya menghabiskan sejam membuktikan bahawa ia tidak melakukan apa-apa. Jika ia menyembuhkan kesesakan itu, laluan itu masih salah bagi setiap alat lain yang melintasinya, dan pembaikan itu menjadi tanggungjawab sesiapa yang mengendalikan peranti tengah.
Perubahan pada klien ialah tampalan sementara dengan tarikh luput. Tulis tarikh itu dalam komen.