Proxy Üzerinden UDP ve QUIC

Proxy sunucusu web kontrolünden geçse de programınızın gerektirdiği trafiği taşıyamayabilir. Örneğin oyun proxy üzerinden giriş yapabilir, ancak oyun güncellemelerini alıp veremeyebilir. Web sitesi normal açılırken tarayıcı HTTP/3 yerine HTTP/2 kullanabilir. Bu işlemler farklı ağ yeteneklerini kullanır.

Genel protokol seçimi için SOCKS ve HTTP Proxy Sunucuları makalesine bakın. Bu makale UDP’nin proxy üzerinden hedefe nasıl ulaştığını, QUIC’in bu yoldan ne gerektirdiğini ve uygulamanızın amaçlanan taşıma protokolünü ve çıkış IP adresini kullandığının nasıl kontrol edileceğini açıklar.

UDP, QUIC ve HTTP/3 ne yapar?

TCP sıralı bayt akışı iletir. Veri kaybolursa yeniden iletimi düzenler ve boşluk dolana kadar sonraki baytları uygulamaya vermez. UDP, datagram denen ayrı iletiler gönderir. UDP’nin kendisi teslimatı, sıralamayı veya yinelenmelere karşı korumayı garantilemez; bu durumların nasıl ele alınacağına onu kullanan yazılım karar verir.

Bu, uygulamalara farklı davranışlar seçme alanı verir. Ses uygulaması çalınamayacak kadar geç gelen ses paketini atabilir. Oyun, eski konum güncellemesi yerine yenisini tercih edebilir. DNS alışverişi kısa soru ve yanıttan oluşabilir. Gerçek taşıma programın davranışına bağlıdır: Bu örnekler her aramanın, oyunun veya DNS isteğinin UDP kullandığı anlamına gelmez.

QUIC, UDP üzerine kurulmuş taşıma protokolüdür. Bağlantı kurma, kayıp veriyi kurtarma, tıkanıklık kontrolü ve güvenilir akışlar ekler. Güvenilir QUIC akışından aktarılan dosya eksiksiz ve sıralı ulaşabilir. Paketlerinin UDP datagramları içinde taşınması, QUIC’in sağladığı güvenilirliği ortadan kaldırmaz.

QUIC, birden fazla akışın tek bağlantıyı paylaşmasını da sağlar. Bir akışın verisi kaybolduğunda verisi ulaşmış diğer akışlar devam edebilir. Bu, tüm akışları sıralı tek TCP bağlantısından taşımaya göre beklemeyi azaltabilir. Sonuç yine rotaya, paket kaybına, sunucuya ve istemciye bağlıdır; yalnızca QUIC seçmek daha hızlı uygulama garantilemez.

HTTP/3, HTTP’yi QUIC üzerinden taşır. HTTP/1.1 ve HTTP/2 normalde TCP kullanır. Üçü de HTTPS web sitesine hizmet verebilir; dolayısıyla adresteki https:// HTTP sürümünü tanımlamaz veya UDP kullanıldığını doğrulamaz.

Şifreleme ayrı özelliktir. UDP veriyi şifrelemez. QUIC, uygulama trafiğini korumak için TLS 1.3 kullanır. Olağan UDP uygulaması başka güvenlik mekanizması kullanabilir veya yükünü şifrelemeden gönderebilir; proxy üzerinden iletmek bu korumayı otomatik eklemez.

SOCKS5 UDP’yi nasıl taşır?

SOCKS5, istemciden datagramları kabul eden, yüklerini hedefe gönderen ve yanıtları döndüren UDP aktarma hizmetini tanımlar. İstemci önce bu iletimi TCP üzerinden düzenler. Ardından kontrol bağlantısı ve datagram yolu yan yana var olur.

1. İstemci SOCKS5 sunucusuna TCP üzerinden bağlanır ve uzlaşılan kimlik doğrulama prosedürünü tamamlar.
2. UDP ASSOCIATE ister. Proxy sunucusu kabul ederse yanıt, aktarıcının adresini ve UDP portunu sağlar.
3. İstemci hedefi belirten SOCKS başlığıyla datagramları aktarıcıya gönderir. Aktarıcı yükü iletmeden önce bu başlığı kaldırır. Yanıtlarda, datagramı istemciye geri göndermeden önce SOCKS başlığı ekler.
4. İstemci aktarıcıyı kullanırken TCP kontrol bağlantısını açık tutar. Onu kapatmak, bağlantının düzenlediği UDP iletimini bitirir. Kontrol bağlantısı ile UDP iletimi arasındaki bu ilişkiye UDP ilişkilendirmesi denir.

Aktarıcı, proxy ayarlarına girilen TCP uç noktasından farklı adres veya port kullanabilir. Bildiğiniz bu uç noktaya ham UDP göndermek SOCKS5 alışverişini gerçekleştirmez. Yalnızca CONNECT uygulayan istemci TCP için SOCKS5 kullanabilir, ancak burada gereken prosedüre sahip değildir. SOCKS4 bu UDP aktarma olanağını tanımlamaz.

Bu, yaygın bir kısmi başarıyı açıklar: Güvenlik duvarı TCP bağlantısına ve kimlik doğrulamasına izin verir, ancak uzlaşılan aktarıcıya giden datagramları engeller. Parola çalışır; uygulama yine UDP yanıtı alamaz. Rotanın her iki bölümü de kullanılabilir olmalıdır.

HTTP proxy UDP iletebilir mi?

Olağan HTTP CONNECT isteği, proxy sunucusundan hedefe TCP bağlantısı açmasını ve bayt akışı taşımasını ister. UDP iletimi kurmaz. HTTPS proxy sunucusuna bağlantıda TLS kullanmak, istenen tünel türünü değiştirmeden bu bağlantıyı korur.

HTTP’nin, genellikle CONNECT-UDP denen ve MASQUE kapsamında geliştirilen ek UDP tünelleme mekanizması vardır. Uyumlu istemci ve sunucuyla istemci UDP hedefine tünel ister. Proxy sunucusu datagramları o hedefe iletir ve yanıtları geri taşır. İki tarafta da açık destek gerekir.

İstemci-proxy bağlantısında, HTTP/3 ve gereken uzantılar destekleniyorsa HTTP Datagramları QUIC DATAGRAM çerçevelerinde taşınabilir. Kapsüllerde de taşınabilirler: TCP üzerinden HTTP/2 dahil güvenilir HTTP akışının içindeki çerçeveli iletiler. Bu durumda rotanın ilk bölümü TCP kullansa da proxy sunucusu hedefe yine UDP gönderir.

Bu seçim zamanlamayı etkiler. TCP bağlantısı veri kaybederse sonraki baytlar kurtarılmasını bekleyebilir ve içlerinde taşınan datagramları geciktirebilir. Tünel çalışır olsa da belirli gerçek zamanlı iş yüküne uygun olmayabilir. Programa yalnızca http:// proxy adresi girmek bu ek UDP mekanizmalarını etkinleştirmez.

Hangi bağlantı QUIC kullanır?

“QUIC proxy” ifadesi bağlam gerektirir. Proxy sunucusuna ulaşmak için kullanılan taşımayı veya uygulamanın hedefe bağlantısını anlatabilir. Bunlar alışverişin ayrı bölümleridir.

Olağan UDP aktarımında proxy sunucusunun uygulamanın QUIC bağlantısını sonlandırması gerekmez. Uygulama ve hedef, şifreli alışverişin uçları olarak kalırken paketleri iletir. Proxy sunucusu trafiği nereye ilettiğini yine bilir ve hacmini ve zamanlamasını gözlemleyebilir.

Uygulama desteği neden önemlidir?

Program hizmetin sunduğu iletim yöntemini uygulamalıdır. SOCKS5 onay kutusu, UDP ASSOCIATE destekleyip desteklemediğini söylemez. Benzer şekilde program doğrudan bağlantıda HTTP/3 desteklerken yalnızca TCP proxy bağlantıları sunabilir.

Chrome somut örnektir: Yerleşik SOCKS5 desteği TCP tabanlı URL isteklerini proxy üzerinden geçirir ve SOCKS5 üzerinden UDP aktarmaz. Bu ayarla sayfa yüklemek hizmetin UDP aktarıcısını test edemez. Sınırlama bu belirli istemci moduyla ilgilidir; diğer istemciler veya dış yönlendirme yazılımları farklı yeteneklere sahip olabilir.

Ayarın kapsamını da kontrol edin. Giriş, dosya indirme, ses ve oyun işlevleri tek uygulamada farklı ağ bileşenleri kullanabilir. Web isteklerine yapılandırılmış proxy yalnızca bazılarını kapsayabilir. Sistem proxy ayarı da her programın ona uyup uymamasına bağlıdır.

Başka uygulamanın trafiğini yönlendiren program, UDP’yi ve hizmetin iletim yöntemini destekliyorsa onun UDP trafiğini proxy üzerinden gönderebilir. Yalnızca TCP yönlendirmek yetmez. Program sanal ağ arayüzü kullanıyorsa hangi trafiğin gireceğini yönlendirme kuralları belirler. Uygulamayı, yönlendirme programını ve proxy uç noktasını birlikte test edin.

Geri dönüş, hata ve doğrudan bağlantı

Gereken yol kullanılamıyorsa sonuç uygulamanın yeteneklerine ve politikasına bağlıdır. Tek soru bir şeyin açılıp açılmadığıysa üç sonuç benzer görünebilir:

TCP tabanlı HTTP sürümüne geçmeye geri dönüş denir. QUIC kullanılamadığında normal gezinmeyi sürdürebilir. İstemci farklı bağlantı açar; QUIC’in kendisi TCP’ye dönüşmez. Bu nedenle QUIC’i kapatmak web uygulamasının kullanılabilir TCP yolunu kullanmasına yardımcı olabilir, ancak UDP gerektiren özelliğe UDP sağlayamaz.

Doğrudan hedefe gitmek yönlendirme kararıdır. Desteklenmeyen UDP her yazılımda doğrudan gönderilmez: Yazılım durabilir, başka taşıma deneyebilir veya yapılandırılmış atlama kuralını izleyebilir. Görevin tüm trafiği proxy üzerinden geçmeliyse o rota bozulduğunda duran modu kullanıp proxy sunucusuna ulaşılamazken davranışını kontrol edin.

UDP kurulumdan sonra neden çalışmayı bırakabilir?

Port kuralları ve dönüş yolu

TCP portu 443 ve UDP portu 443 farklı taşıma protokollerine aittir. Birine izin vermek diğerini açmaz. SOCKS5’te istemci döndürülen UDP aktarma uç noktasına ulaşabilmeli; aktarıcının da hedef UDP portuna ulaşmasına izin verilmelidir. HTTP/3, 443 dışında portlar kullanabilir; bu nedenle uygulamanın gerçekten kullandığı uç noktayı kontrol edin.

Yanıtlar, aktarıcıdan, güvenlik duvarından ve ağlar arasında adresleri, çoğu zaman portları çeviren NAT’tan geri geçmelidir. Tek başına gönderilmiş datagram bu dönüş yolunun çalıştığını göstermez. Ağ değişikliği istemcinin genel IP adresini veya port eşlemesini değiştirebilir. SOCKS5 aktarıcıları, UDP ilişkilendirmesi için kaydedilenden farklı kaynak IP adresinden gelen datagramları reddetmelidir; bu nedenle değişen adres yeni ilişkilendirme gerektirebilir.

Duraklamalar ve süresi dolan durum

Aktarıcılar ve NAT cihazları UDP alışverişleri için geçici kayıtlar tutar. Duraklama sırasında bu kayıtların süresi dolabilir. Arama veya oturum başlangıçta çalışıp istemci yeniden kurana kadar UDP yolunu kaybedebilir. Aynı çıkış IP adresini korumak bunu önlemez: UDP iletimi için gereken durumla hizmetin IP ataması ayrı şeylerdir.

Datagram boyutu ve MTU

MTU, ağ bağlantısının parçalamadan taşıyabildiği en büyük IP paketidir. Rota boyunca kullanılabilir boyut, yol MTU’su denen en küçük böyle sınırla belirlenir. IP, UDP ve ek tünel başlıklarının hepsi pakette yer kaplar. Küçük test iletisi geçerken büyük datagramlar düşürülebilir; dolayısıyla uygulama yolun tamamını ve ek başlıkları hesaba katmalıdır.

QUIC yolu, IP ve UDP başlıkları hariç en az 1.200 bayt UDP yükü taşımalıdır. İstemci, QUIC Initial paketlerini taşıyan UDP datagramlarını en az bu yük boyutuna tamamlar. İstemci-proxy bölümündeki proxy başlıkları ek yer gerektirir. Bu, arayüz MTU’sunu 1.200 yapma önerisi değildir: Küçük DNS isteği ve yanıtı çalışırken daha büyük QUIC el sıkışmasının neden geçemediğini açıklar.

Gecikme, kayıp ve yük

Arama veya oyunda teslimat zamanı, teslimatın kendisi kadar önemli olabilir. Değişken gecikme, paket kaybı ve paket hızı sınırları, normalde çalışan UDP aktarımını bozabilir. Bant genişliği tek başına bu koşulları anlatmaz. Proxy sunucusu rotaya başka bölüm ekler; ağlara ve iş yüküne göre performansı iki yönde de değiştirebilir.

Proxy üzerinden UDP ve HTTP/3 nasıl doğrulanır?

Kullanmayı planladığınız uygulamayı veya aynı iletim yöntemini uygulayan istemciyi test edin. Yararlı test, aynı alışverişin yanıtını, taşıma protokolünü ve çıkış adresini kontrol eder.

1. Gereken trafiğe yanıt veren hedef seçin. Gerçek uygulama sunucusunu veya kontrollü UDP yanıtlayıcısını kullanın. HTTP/3 için desteklediği bilinen hedef seçin. Rastgele UDP portunun sessiz kalması hangi bölümün başarısız olduğunu söylemez.
2. Aktarıcının veya tünelin kabul edildiğini doğrulayın. SOCKS5’te UDP ASSOCIATE sonucunu ve dönen aktarma adresiyle portunu inceleyin. HTTP UDP tünelinde tünelin kabulünü doğrulayın. Kimlik doğrulaması tek başına bu adımı kapsamaz.
3. İstek ve yanıtı tamamlayın. Kontrollü yanıtlayıcı istek kimliği döndürebilir ve gördüğü kaynak IP adresini kaydedebilir. Bu, o UDP alışverişinin çıkışını kontrol eder. Ayrı web IP kontrolü yalnızca kendi isteğini kapsar.
4. HTTP/3 için hedef alışverişindeki protokolü doğrulayın. Proxy rotasının kanıtıyla birlikte istemci veya sunucunun bağlantı günlüğünde HTTP/3 ya da h3 arayın. Test istemcisinde yalnızca HTTP/3 modu varsa otomatik geri dönüşün gizleyeceği hatayı açığa çıkarabilir.
5. İlgili koşullarda tekrarlayın: gerçekçi datagram boyutları, sürekli trafik ve duraklama sonrası etkinlik. Görevde doğrudan trafik yasaksa proxy kullanılamadığında ne olduğunu da test edin. İstemci sürümünü ve bağlantı ayarlarını sonuçla saklayın.

Paket yakalama rotayı belirlemeye yardımcı olabilir. Standart SOCKS5 UDP iletimi, datagramları uzlaşılan aktarıcıya gönderir. HTTP UDP tüneli ise dış TCP bağlantısı kullanabilir; dolayısıyla rotanın ilk bölümünde UDP olmaması tek başına başarısızlık kanıtı değildir.

Uzaktan DNS ile ping farklı şeyleri test eder. Proxy sunucusu, uygulamanın UDP trafiğini aktarmadan TCP bağlantısı için ana makine adı çözümleyebilir. Olağan ping ICMP kullanır. Hiçbir test, amaçlanan proxy rotasında gözlemlenen UDP isteği ve yanıtının yerini tutmaz.

UDP desteği ne zaman seçilmeye değer?

Görevinizin gerektirdiği trafikle başlayın. HTTP/1.1 veya HTTP/2 üzerinden yürüyen web sitesi ve API işlerini yalnızca TCP destekli proxy tamamen karşılayabilir. HTTP/3 testi, UDP medya ve UDP’ye bağlı diğer özellikler, uygun aktarıcı veya tünel ile onu kullanabilen istemci gerektirir.

Hizmete hangi UDP iletim yöntemini ve istemci yapılandırmasını desteklediğini sorun. Ardından izin verilen hedefleri ve portları, datagram boyutu sınırlarını, hareketsizlik davranışını ve iş yüküyle ilgili trafik veya paket hızı sınırlarını kontrol edin. TCP ve UDP aynı çıkış IP adresi veya konumu kullanmalıysa bunu gerçek uygulamada doğrulayın. Ortak hesap veya başarılı web kontrolü aynı çıkış davranışını kanıtlamaz.