HTTPS dalam kontena tersekat pada VPN korporat? Uji kaki DTLS

Di dalam kontena di belakang VPN korporat, DNS diselesaikan, halaman log masuk dimuatkan, titik akhir kesihatan menjawab, dan kemudian permintaan HTTPS tersekat sehingga tamat masa. Membina semula imej dan menukar pemboleh ubah proksi tidak mengubah apa-apa, kerana bahagian yang gagal bukan di dalam imej. Klien mengesahkan identiti melalui satu pengangkutan dan memindahkan data pukal melalui yang lain, dan hanya yang kedua rosak.

Dua pengangkutan, satu gejala yang mengelirukan

Klien korporat berasaskan TLS biasanya mengesahkan identiti melalui sambungan TLS biasa, kemudian merundingkan saluran data kedua berasaskan UDP untuk sesi itu. Apabila kaki kedua itu berfungsi, daya pemprosesan dan kependaman bertambah baik. Apabila ia ditapis atau tidak dapat memuat melalui laluan, segala-galanya sebelum pemindahan pukal berjaya dan pemindahan itu sendiri berhenti, iaitu tepat corak di atas.

Kontena tidak mengubah rundingan itu; ia mengubah laluan yang dilalui paket luar. Hos menterjemah aliran kontena, jadi datagram UDP keluar dari port sumber berbeza daripada soket tempatan klien, dan kembali melalui entri terjemahan yang luput dengan pemasa jauh lebih pendek daripada aliran TCP yang mantap. Jika terowong berfungsi pada hos tetapi gagal dalam kontena, bandingkan kedua-dua aliran itu sebelum menyalahkan aplikasi. Perbandingan itu menyelesaikan lebih banyak daripada mana-mana pembinaan semula imej.

Putuskan melalui eksperimen, bukan gerak hati

Eksperimen paling murah melumpuhkan saluran data UDP dan mengulangi permintaan itu. Gunakan klien baris arahan dan bukan pembalut desktop, supaya bendera itu benar-benar digunakan: openconnect vpn.example.net --user=you --interface=tun0 --no-dtls. Jika permintaan yang tersekat tadi kini selesai, kaki DTLS ialah masalahnya dan selebihnya ialah bunyi bising.

Sahkan hasilnya dalam kedua-dua arah dari kontena yang sama, satu permintaan pukal dengan bendera dan satu tanpanya. Perubahan tingkah laku yang mengikut bendera ialah bukti; halaman yang akhirnya dimuatkan bukan bukti.

Jika bendera itu membaikinya, putuskan mengapa

Tiga keadaan menghasilkan gejala yang sama, dan ia memerlukan tindak balas berbeza. Laluan mungkin menapis UDP sepenuhnya, yang menjadikan bendera itu jawapan kekal yang betul untuk rangkaian tersebut. Laluan mungkin membenarkan UDP tetapi menggugurkan datagram besar, yang menunjuk kepada MTU dan bukan penapisan. Atau laluan mungkin cukup banyak kehilangan paket sehingga kaki UDP berprestasi lebih teruk daripada TCP, yang merupakan keputusan kapasiti dan bukan kebolehcapaian.

Bezakan mereka sebelum mendokumenkan penyelesaian sementara. Penapisan bertahan pada setiap saiz paket, masalah MTU hanya muncul di atas ambang, dan kehilangan muncul sebagai penghantaran semula dan kelewatan berubah-ubah dan bukan tersekat bersih. Setiap ujian menyempitkan punca tanpa mengubah konfigurasi klien.

Semak saiz paket sebelum mengekalkan penyelesaian sementara

Jika saiz ialah puncanya, antara muka terowong menerima paket yang laluan tidak dapat membawa, dan masalah kembali pada mana-mana pengangkutan sebaik sahaja muatan bertambah. Bandingkan antara muka: ip link show tun0 pada hos, kemudian docker network inspect bridge untuk membaca MTU yang direkodkan dalam pilihan rangkaian. Jambatan kontena yang masih pada 1500 bait di bawah terowong yang membawa lebih sedikit ialah penemuan biasa.

Usul ke atas dari saiz baik yang diketahui dengan ujian tanpa pemecahan di dalam terowong, kemudian turunkan MTU rangkaian kontena atau ketatkan TCP MSS pada terowong. Salah satu pembetulan itu sering menjadikan laluan UDP boleh digunakan semula dan menghapuskan keperluan bendera, iaitu hasil yang lebih baik apabila penapisan bukan puncanya.

Putuskan apa yang anda sanggup tukar

Dengan saluran data dilumpuhkan, terowong membawa muatannya di dalam sambungan TCP. Pada laluan bersih itu hanya lebih perlahan; pada laluan yang banyak kehilangan paket, satu segmen hilang melambatkan segala-galanya di belakangnya dan penghantaran semula luar bersaing dengan yang dalam. Pertukaran itu sesuai untuk pembangunan interaktif dan panggilan API kecil, dan kurang sesuai untuk pemindahan pukal atau sesi panjang melalui pautan mudah alih.

Apa pun pilihan yang anda ambil, catat pengangkutan mana yang akhirnya digunakan oleh terowong itu dan mengapa. Kontena yang bergantung secara senyap pada bendera yang ditambah seseorang berbulan-bulan lalu ialah gangguan seterusnya, dan orang yang menyahpepijatnya tidak akan tahu sama ada bendera itu penyelesaian sementara untuk penapisan atau sisa eksperimen MTU.