•  untoreh-light

TCSplitter

En tunnel för att dela TCP- eller UDP -anslutning över flera TCP -anslutningar

Mål

När vill du dela upp en TCP -anslutning i flera? Vanligtvis använder du en tunnel att uppnå raka motsatsen . Mitt användningsfall var att kringgå bandbreddsbegränsningar i ett mobilnät, så tester utfördes med ett sim -kort utan mer data kvar på planen[1].

Hur fungerar det

De tunnel skrevs in golang eftersom det är tillräckligt snabbt och ofta används för nätverksverktyg. Cli är knappt användbar eftersom de flesta alternativen omarbetades när jag testade olika metoder.

Inledningsvis fanns det "flings" och "lassos", för att dela antalet anslutningar för utgående (flinged) och inkommande (lassoed), men detta var en onödig abstraktion eftersom det är bättre att märka paket med deras destination, även om huvudavsikten var att erbjuda olika takgränser för utgående och inkommande anslutningar, så en högre nivåseparation mellan upp/ner verkade praktiskt.

Klienten måste instansera alla anslutningar eftersom vi antar att servern inte kan öppna utgående anslutningar. När klienterna får en anslutning från en användarapplikation, ställer den upp den nödvändiga poolen av anslutningar med servern, och vilken data den än tar emot delar den den mellan de dedikerade anslutningarna enligt en användardefinierad gräns.

Paketen skickas sedan till servern, som måste rekonstruera dem i rätt ordning, eftersom olika TCP -anslutningar kan avsluta dataströmmen när som helst (skickad order respekteras inte, eftersom routing ) och sedan vidarebefordrad till den mottagande appen.

Anslutningar stängs och nya öppnas när den konfigurerade datagränsen per anslutning nås, i likhet med hur skuggorproxys tunneldata över olika strömmar med målet att dölja beteendet hos dataströmmar, förutom att vår tunnel gör det så ofta som möjligt.

Varför fungerar det

Avsikten här är att styra hur mycket data varje anslutning ska hantera. För våra syften var det aldrig längre än det vanligtvis är MTU fönsterstorlek. Du kan tänka dig MTU som den övre gränsen för en data som passerar hela i nätverket, och det var vårt mål eftersom vi ville kringgå gränserna för bandbreddshastighet för ett grindat nätverk. För att begränsa hur mycket data en klient kan passera måste du räkna det, eller hur? Om din logik fungerar med något som endo-while

Då måste du åtminstone ta emot enpacket . Jag är inte säker på om detta är vad som faktiskt händer, eller anledningen till att min tunnel fungerar är en annan. Kanske är det fullt möjligt att kontrollera även det första paketet, men ur ett designperspektiv skulle det betyda att du måste kontrollera varje enkel anslutning, vilket skulle göra systemet svagare mot DOS -attacker, och ja min tunnel kan enkelt användas som ett effektivt DOS/Stress -verktyg, eftersom du kan dela upp data till mycket små paket (vilket innebär att TCP -anslutningar kommer att ha ett högt återvinningstryck ) och ha en pool av anslutningar så stora som du vill.

Testning över olika portar visade också att det bara var möjligt över vissa hamnar, och att gränsen ständigt var annorlunda mellan hamnar, med443 ger ett av de högre fönstren, runt20kb , gissa förTLS handskakningar kräver mer data, och att dessa takgränser skulle förändras baserat på tid på dagen[2].

Resultat

Jag försökte radera kodning i hopp om att öka dataflödet. Genom att använda ett raderingskodningsbibliotek och koda/avkoda själva data, och även genom att lägga över KCP protokoll över mitt delningsprotokoll. Att testa KCP kan tyckas vara ett bakåtsträvande tillvägagångssätt, eftersom det handlar bättre latens för lägre genomströmning, men mitt första antagande var att min flaskhals var i anslutningar tappade mitt i överföringen, vilket skulle orsaka många skadade paket, så jag kunde ha uppnått en högre genomströmning med felkorrigering.

Det visade sig att det bara var en takgräns över hur många TCP-anslutningar en klient kan skicka över nätverket, så bara ett DOS-skydd som jag inte kan göra något åt. Efter X mängder anslutningar eventuellaSYN försök sluta ta emot deras förfallodagACK , fyller på eftersläpningen och så småningom gör tunneln stall. Prövning och fel visade att det var möjligt mellan4-8[3] anslutningar öppna vid varje given tidpunkt, och med en MTU av500-1000 byte kan du hålla en jämn ström åtminstone128kbps , om en konstant ström inte var ett krav, kan du uppnå högre hastigheter under en kortare tidsperiod med spricker många anslutningar på begäran.

Däremot är ett (sant)DNS tunneln kan knappt skjuta56kbps och kan snabbt bli strypt eftersom jag tycker att ett stort antal DNS -förfrågningar ser mer misstänkta ut än TCP -förfrågningar. Vi måste ange att atrue DNS -tunnel kodar (utgående) data över falska underdomäner och avkodar (inkommande) data som tas emot genom att fråga DNS -poster, medan ibland kan en DNS -tunnel anses vara en rå UDP -anslutning över DNS -porten, vilket förmodligen någon gång tidigare, DNS -servrar tillåtet och vidarebefordrat korrekt.

Slutsatser

Jag är inte säker på att jag nått mitt mål verktyg klokt, eftersom körning av en sådan tunnel kan få dig att ringa ganska varmt och slösa mycket batteri, men att ha det som en backupanslutning kan vara lugnande ... om jag faktiskt brydde mig om att göra det tillräckligt stabilt :)

[1]vanligtvis när ett SIM -kort inte har mer data för att surfa på webben, omdirigeras webbförfrågningar till capture -gatewayen (för att berätta för dig att köpa mer data)
[2]mobildataplaner kan ge en bättre anslutning under nattetid
[3]Detta antal, något anpassat till vanliga kärnvärden, kan få dig att misstänka att kärnan begränsar anslutningar på något sätt, scenariot med öppna anslutningar i vår tunnel är definitivt ovanligt, men att ställa in linux -rattar gav aldrig bättre resultat på mitt slut.

Inläggstaggar: