UDP dan QUIC melalui proksi

Proksi dapat lolos pemeriksaan web tetapi tetap tidak mampu membawa trafik yang diperlukan program Anda. Misalnya, gim dapat masuk melalui proksi tetapi gagal bertukar pembaruan permainan. Situs dapat terbuka normal sementara browser menggunakan HTTP/2, bukan HTTP/3. Operasi ini menggunakan kemampuan jaringan yang berbeda.

Untuk pilihan protokol yang lebih luas, lihat Proksi SOCKS dan HTTP. Artikel ini menjelaskan cara UDP mencapai tujuan melalui proksi, kebutuhan QUIC dari jalur tersebut, dan cara memeriksa bahwa aplikasi menggunakan transport serta IP keluar yang dimaksud.

Fungsi UDP, QUIC, dan HTTP/3

TCP mengirim aliran bita yang berurutan. Jika sebagian data hilang, TCP mengatur pengiriman ulang dan menahan bita berikutnya dari aplikasi sampai celah terisi. UDP mengirim pesan terpisah yang disebut datagram. UDP sendiri tidak menjamin pengiriman, urutan, atau perlindungan terhadap duplikat; perangkat lunak yang menggunakannya menentukan cara menangani situasi tersebut.

Ini memberi aplikasi ruang untuk memilih perilaku berbeda. Aplikasi suara dapat membuang paket audio yang tiba terlalu terlambat untuk diputar. Gim dapat lebih memilih pembaruan posisi terkini daripada yang lama. Pertukaran DNS dapat terdiri dari pertanyaan dan jawaban singkat. Transport sebenarnya bergantung pada program: contoh ini tidak berarti setiap panggilan, gim, atau permintaan DNS menggunakan UDP.

QUIC adalah protokol transport yang dibangun di atas UDP. QUIC menambahkan pembentukan koneksi, pemulihan data hilang, kendali kepadatan, dan aliran andal. Berkas yang ditransfer melalui aliran QUIC andal dapat tiba lengkap dan berurutan. Fakta bahwa paketnya berjalan di dalam datagram UDP tidak menghilangkan keandalan yang diberikan QUIC.

QUIC juga memungkinkan beberapa aliran berbagi koneksi. Ketika data satu aliran hilang, aliran lain yang datanya sudah tiba dapat berlanjut. Ini dapat mengurangi penantian dibandingkan membawa semua aliran melalui satu koneksi TCP berurutan. Hasilnya tetap bergantung pada rute, kehilangan paket, server, dan klien; memilih QUIC saja tidak menjamin aplikasi lebih cepat.

HTTP/3 membawa HTTP melalui QUIC. HTTP/1.1 dan HTTP/2 biasanya menggunakan TCP. Ketiganya dapat melayani situs HTTPS, sehingga https:// dalam alamat tidak mengidentifikasi versi HTTP atau memastikan bahwa UDP digunakan.

Enkripsi adalah sifat terpisah. UDP tidak mengenkripsi data. QUIC menggunakan TLS 1.3 untuk membentuk perlindungan trafik aplikasi. Aplikasi UDP biasa dapat menggunakan mekanisme keamanan lain atau mengirim muatannya tanpa enkripsi; meneruskannya melalui proksi tidak otomatis menambahkan perlindungan itu.

Cara SOCKS5 membawa UDP

SOCKS5 mendefinisikan relai UDP: layanan yang menerima datagram dari klien, mengirim muatannya ke tujuan, dan mengembalikan balasannya. Klien terlebih dahulu mengatur penerusan ini melalui TCP. Koneksi kendali dan jalur datagram kemudian berjalan berdampingan.

1. Klien terhubung ke server SOCKS5 melalui TCP dan menyelesaikan prosedur autentikasi yang disepakati.
2. Klien meminta UDP ASSOCIATE. Jika proksi menerima, balasannya memberikan alamat dan port UDP relai.
3. Klien mengirim datagram ke relai dengan header SOCKS yang mengidentifikasi tujuan. Relai menghapus header itu sebelum meneruskan muatan. Untuk balasan, relai menambahkan header SOCKS sebelum mengirim datagram kembali ke klien.
4. Klien mempertahankan koneksi kendali TCP terbuka selama menggunakan relai. Menutupnya mengakhiri penerusan UDP yang diatur melalui koneksi itu. Hubungan antara koneksi kendali dan penerusan UDP ini disebut asosiasi UDP.

Relai dapat menggunakan alamat atau port berbeda dari titik koneksi TCP yang dimasukkan ke pengaturan proksi. Mengirim UDP mentah ke titik koneksi yang sudah dikenal itu tidak melakukan pertukaran SOCKS5. Klien yang hanya menerapkan CONNECT dapat menggunakan SOCKS5 untuk TCP, tetapi tidak memiliki prosedur yang diperlukan di sini. SOCKS4 tidak mendefinisikan fasilitas relai UDP ini.

Ini menjelaskan keberhasilan sebagian yang umum: firewall mengizinkan koneksi TCP dan autentikasi, tetapi memblokir datagram ke relai yang dinegosiasikan. Kata sandi berfungsi; aplikasi tetap tidak menerima balasan UDP. Kedua bagian rute harus tersedia.

Dapatkah proksi HTTP meneruskan UDP?

Permintaan HTTP CONNECT biasa meminta proksi membuka koneksi TCP ke tujuan dan membawa aliran bita. Permintaan itu tidak membentuk penerusan UDP. Menggunakan TLS untuk koneksi ke proksi HTTPS melindungi koneksi itu tanpa mengubah jenis terowongan yang diminta.

HTTP memiliki mekanisme terowongan UDP tambahan, yang biasa disebut CONNECT-UDP dan dikembangkan sebagai bagian dari MASQUE. Dengan klien dan server yang sesuai, klien meminta terowongan ke tujuan UDP. Proksi meneruskan datagram ke tujuan tersebut dan membawa balasan kembali. Ini memerlukan dukungan eksplisit pada kedua sisi.

Pada koneksi klien-ke-proksi, HTTP Datagrams dapat dibawa dalam bingkai QUIC DATAGRAM ketika HTTP/3 dan ekstensi yang diperlukan didukung. Datagram juga dapat dibawa dalam kapsul: pesan berbingkai di dalam aliran HTTP andal, termasuk HTTP/2 melalui TCP. Dalam hal itu, proksi tetap mengirim UDP ke tujuan meskipun bagian pertama rute menggunakan TCP.

Pilihan itu memengaruhi waktu. Jika koneksi TCP kehilangan data, bita berikutnya dapat menunggu pemulihannya sehingga datagram di dalamnya tertunda. Terowongan dapat berfungsi tetapi tidak sesuai untuk beban kerja waktu nyata tertentu. Sekadar memasukkan alamat proksi http:// dalam program tidak mengaktifkan mekanisme UDP tambahan tersebut.

Koneksi mana yang menggunakan QUIC?

Frasa “proksi QUIC” memerlukan konteks. Frasa itu dapat menjelaskan transport untuk mencapai proksi atau koneksi aplikasi ke tujuan. Keduanya merupakan bagian pertukaran yang terpisah.

Dalam relai UDP biasa, proksi tidak perlu mengakhiri koneksi QUIC aplikasi. Proksi meneruskan paket sementara aplikasi dan tujuan tetap menjadi titik akhir pertukaran terenkripsi itu. Proksi tetap mengetahui tujuan penerusan trafik dan dapat mengamati volume serta waktunya.

Mengapa dukungan aplikasi penting

Program perlu menerapkan metode penerusan yang ditawarkan layanan. Kotak centang SOCKS5 tidak menunjukkan apakah program mendukung UDP ASSOCIATE. Demikian pula, program dapat mendukung HTTP/3 untuk koneksi langsung tetapi hanya menawarkan koneksi proksi TCP.

Chrome memberikan contoh nyata: dukungan SOCKS5 bawaannya memproksikan permintaan URL berbasis TCP dan tidak meneruskan UDP melalui SOCKS5. Memuat halaman dengan pengaturan itu tidak dapat menguji relai UDP layanan. Keterbatasan ini menyangkut mode klien tertentu tersebut; klien lain atau perangkat lunak perutean eksternal dapat memiliki kemampuan berbeda.

Periksa pula cakupan pengaturan. Login, unduhan berkas, suara, dan permainan dapat menggunakan komponen jaringan berbeda dalam satu aplikasi. Proksi yang dikonfigurasi untuk permintaan web mungkin hanya mencakup sebagian. Pengaturan proksi sistem juga bergantung pada apakah setiap program mengikutinya.

Program yang mengalihkan trafik aplikasi lain dapat mengirim UDP-nya melalui proksi jika mendukung UDP dan metode penerusan layanan. Mengalihkan TCP saja tidak cukup. Jika program menggunakan antarmuka jaringan virtual, aturan peruteannya menentukan trafik yang masuk ke dalamnya. Uji gabungan lengkap: aplikasi, program perutean, dan titik koneksi proksi.

Beralih ke transport lain, kegagalan, dan koneksi langsung

Ketika jalur yang diperlukan tidak tersedia, hasil bergantung pada kemampuan dan kebijakan aplikasi. Tiga hasil dapat tampak serupa jika satu-satunya pertanyaan adalah apakah sesuatu berhasil terbuka:

Beralih ke versi HTTP berbasis TCP disebut fallback. Ini dapat mempertahankan penjelajahan normal ketika QUIC tidak tersedia. Klien membuka koneksi berbeda; QUIC sendiri tidak berubah menjadi TCP. Karena itu, menonaktifkan QUIC dapat membantu aplikasi web menggunakan jalur TCP yang tersedia, tetapi tidak dapat menyediakan UDP untuk fitur yang memerlukannya.

Menuju langsung ke tujuan adalah keputusan perutean. UDP yang tidak didukung tidak selalu dikirim langsung: perangkat lunak dapat berhenti, mencoba transport lain, atau mengikuti aturan pengecualian yang dikonfigurasi. Jika semua trafik tugas harus melewati proksi, gunakan mode yang berhenti ketika rute itu gagal dan periksa perilakunya saat proksi tidak tersedia.

Mengapa UDP dapat berhenti berfungsi setelah pembentukan

Aturan port dan jalur kembali

Port TCP 443 dan port UDP 443 termasuk transport berbeda. Mengizinkan salah satunya tidak membuka yang lain. Untuk SOCKS5, klien harus mencapai titik koneksi relai UDP yang dikembalikan; relai juga harus diizinkan mencapai port UDP tujuan. HTTP/3 dapat menggunakan port selain 443, jadi periksa titik koneksi yang benar-benar digunakan aplikasi.

Balasan harus kembali melalui relai, firewall, dan NAT jika ada, yang menerjemahkan alamat dan sering kali port antarjaringan. Datagram yang terkirim saja tidak menunjukkan jalur kembali ini berfungsi. Perubahan jaringan dapat mengubah IP publik klien atau pemetaan portnya. Relai SOCKS5 diwajibkan menolak datagram dari IP sumber selain yang dicatat untuk asosiasi UDP tersebut, sehingga alamat yang berubah dapat memerlukan asosiasi baru.

Jeda dan status kedaluwarsa

Relai dan perangkat NAT menyimpan catatan sementara untuk pertukaran UDP. Catatan itu dapat kedaluwarsa selama jeda. Panggilan atau sesi dapat berfungsi pada awalnya, lalu kehilangan jalur UDP hingga klien membentuknya kembali. Mempertahankan IP keluar yang sama tidak mencegah ini: status yang diperlukan untuk meneruskan UDP dan alokasi IP layanan adalah hal terpisah.

Ukuran datagram dan MTU

MTU adalah paket IP terbesar yang dapat dibawa sebuah sambungan jaringan tanpa fragmentasi. Ukuran yang dapat digunakan sepanjang rute dibatasi oleh batas terkecilnya, yang disebut path MTU. Header IP, UDP, dan terowongan tambahan semuanya mengambil ruang dalam paket. Pesan uji kecil dapat lewat sementara datagram lebih besar dibuang, sehingga aplikasi harus memperhitungkan seluruh jalur dan header tambahannya.

Jalur QUIC harus membawa sedikitnya 1.200 bita muatan UDP, tanpa menghitung header IP dan UDP. Klien menambahkan pengisi pada datagram UDP yang membawa paket QUIC Initial-nya hingga sedikitnya ukuran muatan itu. Header proksi pada bagian klien-ke-proksi memerlukan ruang tambahan. Ini bukan anjuran untuk mengatur MTU antarmuka ke 1.200: ini menjelaskan mengapa permintaan dan balasan DNS kecil dapat berfungsi sementara jabat tangan QUIC yang lebih besar tidak dapat lewat.

Penundaan, kehilangan, dan beban

Untuk panggilan atau gim, waktu pengiriman dapat sama pentingnya dengan pengiriman itu sendiri. Penundaan yang bervariasi, kehilangan paket, dan batas laju paket dapat mengganggu relai UDP yang sebenarnya berfungsi. Lebar pita saja tidak menjelaskan kondisi ini. Proksi menambahkan bagian lain pada rute; proksi dapat mengubah kinerja ke arah mana pun, tergantung jaringan dan beban kerja.

Cara memverifikasi UDP dan HTTP/3 melalui proksi

Uji aplikasi yang akan Anda gunakan, atau klien yang menerapkan metode penerusan yang sama. Pengujian yang berguna memeriksa balasan, transport, dan alamat keluar untuk pertukaran yang sama.

1. Pilih tujuan yang menjawab trafik yang diperlukan. Gunakan server aplikasi sebenarnya atau penjawab UDP yang Anda kendalikan. Untuk HTTP/3, pilih tujuan yang diketahui mendukungnya. Tidak adanya respons dari port UDP sembarang tidak memberi tahu bagian yang gagal.
2. Pastikan relai atau terowongan diterima. Dengan SOCKS5, periksa hasil UDP ASSOCIATE dan alamat serta port relai yang dikembalikan. Dengan terowongan UDP HTTP, pastikan terowongan itu diterima. Autentikasi saja tidak mencakup langkah ini.
3. Selesaikan permintaan dan balasan. Penjawab yang Anda kendalikan dapat mengembalikan pengenal permintaan dan mencatat IP sumber yang dilihatnya. Ini memeriksa jalur keluar yang digunakan pertukaran UDP tersebut. Pemeriksaan IP web terpisah hanya mencakup permintaannya sendiri.
4. Untuk HTTP/3, pastikan protokol pada pertukaran tujuan. Cari HTTP/3 atau h3 dalam log koneksi klien atau server, bersama bukti rute proksi. Jika klien uji memiliki mode khusus HTTP/3, mode itu dapat mengungkap kegagalan yang akan tersembunyi oleh fallback otomatis.
5. Ulangi dalam kondisi yang relevan: ukuran datagram realistis, trafik berkelanjutan, dan jeda yang diikuti aktivitas. Jika trafik langsung dilarang untuk tugas, uji pula yang terjadi ketika proksi tidak tersedia. Simpan versi klien dan pengaturan koneksi bersama hasilnya.

Penangkapan paket dapat membantu mengidentifikasi rute. Penerusan UDP SOCKS5 standar mengirim datagram ke relai yang dinegosiasikan. Terowongan UDP HTTP dapat menggunakan koneksi TCP luar, sehingga tidak adanya UDP pada bagian pertama rute itu bukan bukti kegagalan yang cukup.

DNS jarak jauh dan ping menguji hal berbeda. Proksi dapat mencari nama host untuk koneksi TCP tanpa meneruskan trafik UDP aplikasi. ping biasa menggunakan ICMP. Kedua pengujian tidak menggantikan permintaan dan balasan UDP yang diamati pada rute proksi yang dimaksud.

Kapan dukungan UDP layak dipilih

Mulai dari trafik yang diperlukan tugas Anda. Pekerjaan situs dan API yang berjalan melalui HTTP/1.1 atau HTTP/2 dapat sepenuhnya dilayani proksi khusus TCP. Pengujian HTTP/3, media UDP, dan fitur lain yang bergantung pada UDP memerlukan relai atau terowongan yang sesuai beserta klien yang dapat menggunakannya.

Tanyakan kepada layanan metode penerusan UDP dan konfigurasi klien yang didukung. Kemudian periksa tujuan dan port yang diizinkan, batas ukuran datagram, perilaku saat menganggur, dan batas trafik atau laju paket yang relevan bagi beban kerja. Jika TCP dan UDP harus menggunakan IP keluar atau lokasi yang sama, verifikasi kebutuhan itu dalam aplikasi sebenarnya. Akun bersama atau pemeriksaan web yang berhasil tidak membuktikan perilaku keluar identik.