HTTPS di kontainer macet di VPN kantor? Uji kaki DTLS

Di dalam kontainer di belakang VPN kantor, DNS berhasil diselesaikan, halaman login termuat, endpoint health menjawab, lalu permintaan HTTPS macet sampai waktu habis. Membangun ulang image dan mengubah variabel proxy tidak mengubah apa pun, karena bagian yang gagal bukan ada di image. Klien mengautentikasi lewat satu transport dan memindahkan data besar lewat transport lain, dan hanya yang kedua yang rusak.

Dua transport, satu gejala yang membingungkan

Klien kantor berbasis TLS biasanya mengautentikasi lewat koneksi TLS biasa, lalu menegosiasikan kanal data kedua berbasis UDP untuk sesi. Saat kaki kedua itu bekerja, throughput dan latensi membaik. Saat disaring atau tidak muat di jalur, semua sebelum transfer besar berhasil dan transfernya sendiri berhenti, yang persis pola di atas.

Kontainer tidak mengubah negosiasi itu; ia mengubah jalur yang dilalui paket luar. Host menerjemahkan alur kontainer, jadi datagram UDP keluar dari port sumber berbeda dari soket lokal klien dan kembali lewat entri terjemahan yang kedaluwarsa dengan pengatur waktu jauh lebih pendek daripada alur TCP yang sudah terbentuk. Jika tunnel bekerja di host dan gagal di kontainer, bandingkan kedua alur itu sebelum menyalahkan aplikasi. Perbandingan itu menjelaskan lebih banyak daripada membangun ulang image.

Putuskan dengan eksperimen, bukan intuisi

Eksperimen termurah menonaktifkan kanal data UDP dan mengulang permintaan. Gunakan klien baris perintah alih-alih pembungkus desktop, agar flag benar-benar diterapkan: openconnect vpn.example.net --user=you --interface=tun0 --no-dtls. Jika permintaan yang tadinya macet kini selesai, kaki DTLS adalah masalahnya dan sisanya kebisingan.

Konfirmasi hasilnya di kedua arah dari kontainer yang sama: satu permintaan besar dengan flag dan satu tanpa. Perubahan perilaku yang mengikuti flag adalah bukti; halaman yang akhirnya termuat bukan bukti.

Jika flag memperbaikinya, putuskan mengapa

Tiga kondisi menghasilkan gejala yang sama, dan menuntut respons berbeda. Jalur mungkin menyaring UDP sepenuhnya, yang menjadikan flag jawaban permanen yang benar untuk jaringan itu. Jalur mungkin mengizinkan UDP tetapi membuang datagram besar, yang mengarah ke MTU bukan penyaringan. Atau jalur mungkin cukup banyak kehilangan paket sehingga kaki UDP berkinerja lebih buruk daripada TCP, yang merupakan keputusan kapasitas bukan keterjangkauan.

Bedakan ketiganya sebelum mendokumentasikan solusi sementara. Penyaringan bertahan pada semua ukuran paket, masalah MTU hanya muncul di atas ambang, dan kehilangan tampak sebagai pengiriman ulang dan penundaan bervariasi bukan macet bersih. Setiap uji mempersempit penyebab tanpa mengubah konfigurasi klien.

Periksa ukuran paket sebelum mempertahankan solusi sementara

Jika ukuran penyebabnya, antarmuka tunnel menerima paket yang tidak dapat dibawa jalur, dan masalahnya kembali pada transport apa pun begitu muatan bertambah. Bandingkan antarmukanya: ip link show tun0 di host, lalu docker network inspect bridge untuk membaca MTU yang tercatat di opsi jaringan. Jembatan kontainer yang masih di 1500 byte di bawah tunnel yang membawa lebih sedikit adalah temuan yang biasa.

Probe ke atas dari ukuran yang diketahui baik dengan uji tanpa fragmentasi di dalam tunnel, lalu turunkan MTU jaringan kontainer atau kencangkan TCP MSS pada tunnel. Salah satu koreksi sering membuat jalur UDP dapat digunakan lagi dan menghapus kebutuhan akan flag, yang merupakan hasil lebih baik bila penyaringan bukan penyebabnya.

Putuskan apa yang bersedia Anda tukar

Dengan kanal data dinonaktifkan, tunnel membawa muatannya di dalam koneksi TCP. Pada jalur bersih itu hanya lebih lambat; pada jalur yang banyak kehilangan paket, satu segmen hilang menunda semua di belakangnya dan pengiriman ulang luar bersaing dengan yang dalam. Pertukaran itu cocok untuk pengembangan interaktif dan panggilan API kecil, dan kurang cocok untuk transfer besar atau sesi panjang lewat tautan seluler.

Apa pun opsi yang Anda pilih, catat transport mana yang akhirnya dipakai tunnel dan mengapa. Kontainer yang diam-diam bergantung pada flag yang ditambahkan seseorang berbulan-bulan lalu adalah gangguan berikutnya, dan orang yang men-debug-nya tidak akan tahu apakah flag itu solusi sementara untuk penyaringan atau sisa eksperimen MTU.