Muat Turun Besar lwn VPN: Pilih Laluan pada Permintaan

“Hantar muat turun besar di sekeliling VPN dan biarkan balasan kecil di atasnya” kedengaran seperti dasar penghalaan, tetapi bukan. Penghala membuat keputusan dengan maklumat yang tersedia pada saat itu: alamat, port, protokol, tanda firewall, aliran yang dikenal pasti. Saiz akhir respons tiada dalam set itu, kerana ia belum tiba, dan apabila penghala boleh mengukur bait, ia sudah membawanya. Jika anda mahu panduan mengikut tugas, keputusan mesti berpindah ke titik yang mengenali tugas itu, dan senarai semak di bawah menunjukkan sama ada reka bentuk anda mempunyai titik sedemikian.

Mengapa penghala tidak boleh mengukur respons

Pada saat paket memerlukan laluan, penghala paling banyak telah melihat beberapa paket pertama sesuatu aliran. Ia boleh memberitahu siapa bercakap dengan siapa, melalui protokol apa, dengan tanda apa, dan berapa banyak bait telah berlalu setakat ini. Bait setakat ini menggambarkan masa lalu. Saiz balasan ialah sifat respons yang belum dijana, dan bagi respons berpecah atau penstriman ia mungkin tidak pernah diketahui lebih awal.

Malah metadata protokol itu sendiri lebih lemah daripada yang kelihatan. HTTP membenarkan respons yang panjangnya tidak diumumkan sebelum badan, dan satu tindakan pengguna boleh menghasilkan banyak permintaan yang kos gabungannya tidak menyerupai mana-mana nilai pengepala tunggal. Menganggap pengepala sebagai saiz tugas ialah ralat pemodelan sebelum ia menjadi ralat penghalaan.

Semakan 1: adakah titik keputusan yang boleh memilih laluan?

Namakan komponen yang akan membuat pilihan, kemudian namakan apa yang ia tahu pada saat pemilihan. Penyelaras yang mengambil daripada set hos berdokumen mengetahui tujuannya sebelum pemindahan bermula. Perkhidmatan muat turun yang menyemak metadata dan kemudian membuka permintaan mengetahui tugas itu sebelum sambungan wujud. Proksi yang bekerjasama boleh menggunakan dasar peringkat permintaan atau menyimpan respons dalam cache tanpa berpura-pura menjadi penghala.

Jika jawapannya “gateway”, senarai semak sudah gagal. Gateway boleh mengelaskan aliran yang diketahui mengikut destinasi, tanda atau segmen klien dan menghantarnya melalui laluan yang ditetapkan dari paket pertama, yang selalunya cukup untuk penyelaras yang diluluskan dan tidak pernah cukup untuk saiz respons yang tidak diketahui.

Semakan 2: apa yang sebenarnya dikatakan metadata?

Panduan sedar aplikasi hanya sebaik medan yang dibacanya. Peraturan panjang respons dalam semantik HTTP membenarkan kes apabila panjang tidak tersedia pada permulaan, dan pengekodan kandungan menjadikan kiraan bait yang dipindahkan berbeza daripada saiz perwakilan pula. Oleh itu dasar yang menukar laluan apabila pengepala melepasi ambang akan berkelakuan tidak konsisten, dan kebanyakannya tepat pada pemindahan besar yang sepatutnya ditangkapnya.

Apa yang boleh disokong metadata aplikasi ialah keputusan tentang tugas: aliran kerja ini penyegerakan pukal, ini interaktif, ini kemas kini perisian daripada asal yang diketahui. Itu dasar yang ditulis dalam istilah niat, dan cukup stabil untuk diuji. “Respons ini akan lebih besar daripada empat puluh megabait” bukan dasar seperti itu.

Semakan 3: adakah aliran sudah wujud?

Penghalaan boleh berubah untuk sesuatu aliran tanpa mengubah identiti sambungan, dan perbezaan itu wajar dikekalkan dengan tepat. Sambungan TCP dikenal pasti melalui alamat dan port hujungnya, dan paket boleh mengambil laluan berbeza jika jadual penghalaan berubah di bawahnya. Apa yang tidak boleh berubah secara tidak kelihatan ialah keadaan terjemahan alamat rangkaian: memindahkan trafik ke jalan keluar lain biasanya mengubah tuple sumber awam, dan hujung jauh akan melihat rakan yang berbeza tanpa keadaan yang sepadan.

conntrack -L -p tcp --dport 443 | head -5
ip route get 203.0.113.10
ss -tn state established dst 203.0.113.10

Jadi peraturan praktikalnya ialah perpindahan di tengah sambungan dari satu jalan keluar ke jalan keluar lain ialah hubungan baharu, bukan migrasi. Jika reka bentuk memerlukan sambungan yang sama diteruskan, keputusan itu perlu dibuat sebelum SYN pertama, dan tiada peraturan paket yang ditambah kemudian boleh membinanya semula dengan bersih.

Semakan 4: adakah keperluan sebenar kependaman, bukan jalan keluar?

Banyak sekali permintaan “hantar trafik pukal ke tempat lain” sebenarnya aduan bahawa pemindahan besar membuat kerja interaktif terasa lambat. Itu masalah penjadualan, dan ia mempunyai jawapan penjadualan: baris gilir adil atau dasar lebar jalur yang disokong pada laluan sedia ada menghalang aliran pukal daripada melaparkan mesej sembang tanpa memindahkan mana-mana daripada keduanya.

tc qdisc replace dev eth0 root cake bandwidth 100mbit

Menangani gejala dengan cara ini mengekalkan keputusan jalan keluar di tempat dasar keselamatan meletakkannya, dan ia boleh diterbalikkan dengan satu arahan. Menukar jalan keluar untuk seluruh kelas trafik ialah perubahan dasar dengan akibat pengesahan, pengelogan dan peraturan akses, jadi ia tidak sepatutnya menjadi alat pertama ketika ada aduan kependaman.

Jika keperluannya benar-benar jalan keluar internet yang berbeza, katakan dengan perkataan itu dan laksanakannya pada sempadan yang disokong: sambungan baharu daripada aliran kerja yang diluluskan, atau aplikasi yang membuka permintaannya sendiri melalui jalan keluar yang dipilih. Kemudian rekod tugas mana menggunakan jalan keluar mana, supaya orang seterusnya tidak perlu menyimpulkannya daripada jadual penghalaan.

Simpan senarai semak dalam rekod perubahan: titik keputusan, medan atau tugas yang menggerakkannya, sama ada aliran sudah wujud, dan sama ada gejala yang diukur ialah kependaman atau jalan keluar. Empat soalan, dan dasar yang menjawab keempat-empatnya ialah dasar yang boleh anda kendalikan, bukan pertahankan.