•  untoreh-ışık

TCsplitter

TCP veya UDP bağlantısını birden çok TCP bağlantısı arasında bölmek için bir tünel

Hedef

Bir TCP bağlantısını ne zaman birden çok bağlantıya bölmek istersiniz? Genellikle bir kullanırsın tünel başarmak tam tersi . Kullanım durumum, bir mobil ağdaki bant genişliği sınırlamalarını aşmaktı, bu nedenle testler, planında daha fazla veri kalmayan bir sim kartla yapıldı.[1].

O nasıl çalışır

NS tünel yazıldı golang Yeterince hızlı olduğu ve yaygın olarak ağ araçları için kullanıldığı için. Farklı yöntemleri test ettiğim için seçeneklerin çoğu elden geçirildiği için cli zar zor kullanılabilir.

Başlangıçta, giden (fırlatılan) ve gelen (kementlenen) bağlantıların sayısını bölmek için "kaçışlar" ve "kementler" vardı, ancak bu gereksiz bir soyutlamaydı, çünkü asıl amaç şu olsa da paketleri hedefleriyle etiketlemek daha iyidir. giden ve gelen bağlantılar için farklı hız limitleri sunmak, bu nedenle yukarı/aşağı arasında daha yüksek düzeyde bir ayrım pratik görünüyordu.

Sunucunun giden bağlantıları açamayacağını varsaydığımız için istemcinin tüm bağlantıları başlatması gerekir. İstemciler bir kullanıcı uygulamasından bağlantı aldığında, sunucu ile gerekli bağlantı havuzunu kurar ve aldığı veri ne olursa olsun, kullanıcı tanımlı bir sınıra göre özel bağlantılar arasında böler.

Paketler daha sonra sunucuya gönderilir, sunucu onları doğru sırayla yeniden yapılandırmak zorundadır, çünkü farklı TCP bağlantıları veri akışını herhangi bir zamanda bitirebilir (gönderilen sıraya uyulmaz, çünkü yönlendirme ) ve ardından alıcı uygulamaya iletilir.

Bağlantı başına yapılandırılmış veri sınırına ulaşıldığında, bağlantılar kapatılır ve yenileri açılır. gölge çoraplarıTünelimizin bunu mümkün olduğunca sık yapması dışında, veri akışlarının davranışını maskelemek amacıyla proxy'ler farklı akışlar arasında verileri tüneller.

neden işe yarıyor

Buradaki amaç, her bağlantının ne kadar veri işlemesi gerektiğini kontrol etmektir. Bizim amaçlarımız için, asla ötesine geçmedi, genellikle MTU Pencere boyutu. MTU'yu ağ üzerinden bütün olarak geçen bir veri parçasının üst sınırı olarak düşünebilirsiniz ve hedefimiz buydu çünkü kapılı bir ağın bant genişliği hızı sınırlarını atlamak istedik. Bir istemcinin ne kadar veri geçebileceğini sınırlamak için şunları yapmanız gerekir: saymak O doğru? Mantığınız şöyle bir şeyle çalışıyorsado-while

O zaman ihtiyacın var en azından almakpacket . Gerçekten olanın bu olup olmadığından emin değilim, yoksa tünelimin çalışmasının nedeni başka bir şey mi? Belki ilk paketi bile kontrol etmek tamamen mümkündür, ancak tasarım açısından bu, kontrol etmeniz gerektiği anlamına gelir. her sistemi DOS saldırılarına karşı zayıflatacak tek bağlantı ve evet, tünelim verimli bir DOS/Stres aracı olarak kolayca kullanılabilir, çünkü verileri çok küçük paketlere bölebilirsiniz (bu, TCP bağlantılarının yüksek bir geri dönüşüm basıncına sahip olacağı anlamına gelir). ) ve istediğiniz kadar büyük bir bağlantı havuzuna sahip olun.

Farklı bağlantı noktaları üzerinde yapılan testler, bunun yalnızca biraz bağlantı noktaları ve sınırın bağlantı noktaları arasında sürekli olarak farklı olduğu,443 etrafındaki yüksek pencerelerden birini vererek20kb , tahmin çünküTLS tokalaşmaların daha fazla veri gerektirdiğini ve bu hız sınırlarının günün saatine göre değişeceğini[2].

Sonuçlar

Veri verimini artırma umuduyla silme kodlamasını denedim. Bir silme kodlama kitaplığı kullanarak ve verilerin kendisini kodlayarak/kodunu çözerek ve ayrıca KCP bölme protokolüm üzerinden protokol. KCP'yi denemek geriye doğru bir yaklaşım gibi görünebilir, çünkü daha düşük verim için daha iyi gecikme süresi sağlar, ancak ilk varsayımım, bağlantılardaki darboğazımın iletimin ortasında düştüğü ve bu da birçok bozuk pakete neden olacağıydı, bu yüzden daha yüksek bir sonuç elde edebilirdim. hata düzeltme ile verim.

Bunun, bir istemcinin ağ üzerinden gönderebileceği TCP bağlantılarının sayısıyla ilgili bir hız sınırı olduğu ortaya çıktı, bu yüzden yalnızca bir DOS koruması hakkında hiçbir şey yapamam. X miktarda bağlantıdan sonra herhangiSYN denemeler hakkını almayı durdururACK , biriktirme listesini doldurmak ve sonunda tünelin durmasını sağlamak. Deneme yanılma arasında mümkün olduğunu gösterdi4-8[3] bağlantılar herhangi bir zamanda açılır ve bir MTU ile500-1000 bayt en azından etrafında sabit bir akış tutabilirsiniz128kbps , sabit bir akış bir gereklilik değilse, daha kısa bir süre içinde daha yüksek hızlar elde edebilirsiniz. patlama talep üzerine birçok bağlantı.

Buna karşılık, bir (doğru)DNS tünel zar zor itebilir56kbps ve hızlı bir şekilde kısılabilir çünkü çok sayıda DNS isteğinin TCP isteklerinden daha şüpheli göründüğünü düşünüyorum. Belirtmeliyiz ki birtrue DNS tüneli, sahte alt alanlar üzerinden (giden) verileri kodlar ve DNS kayıtlarını sorgulayarak alınan (gelen) verilerin kodunu çözer, oysa bazen bir DNS tüneli, muhtemelen geçmişte bir zamanlar DNS sunucuları olan DNS bağlantı noktası üzerinden ham bir UDP bağlantısı olarak düşünülebilir. izin verilir ve doğru bir şekilde iletilir.

Sonuçlar

amacıma ulaştığımdan emin değilim Yarar akıllıca, çünkü bu tür bir tüneli çalıştırmak telefonunuzu oldukça ısıtabilir ve çok fazla pil israfına neden olabilir, ancak onu yedek bağlantı olarak kullanmak güven verici olabilir...

[1]genellikle bir sim kartın web'e göz atacak daha fazla verisi olmadığında, web istekleri yakalama ağ geçidine yönlendirilir (size daha fazla veri satın almanızı söylemek için)
[2]mobil veri planları, gece saatlerinde daha iyi bir bağlantı sağlayabilir
[3]Bu sayı, bir şekilde ortak çekirdek sayılarına göre ayarlandığında, çekirdeğin bağlantıları bir şekilde sınırlandırdığından şüphelenmenize neden olabilir, tünelimizin açık bağlantı senaryosu kesinlikle olağandışıdır, ancak linux düğmelerinin ayarlanması benim açımdan asla daha iyi sonuçlar vermedi.

Etiketleri Gönder: