•  ontereh-licht

TCSsplitter

Een tunnel om de TCP- of UDP-verbinding over meerdere TCP-verbindingen te splitsen

Doel

Wanneer zou u een TCP-verbinding in meerdere willen splitsen? Meestal gebruik je een tunnel bereiken precies het tegenovergestelde . Mijn gebruiksgeval was het omzeilen van bandbreedtebeperkingen in een mobiel netwerk, dus werden tests uitgevoerd met een simkaart zonder dat er meer gegevens op het plan stonden[1].

Hoe werkt het

De tunnel is geschreven in golang omdat het snel genoeg is en vaak wordt gebruikt voor netwerktooling. De cli is nauwelijks bruikbaar omdat de meeste opties zijn herwerkt terwijl ik verschillende methoden heb getest.

Aanvankelijk waren er "flings" en "lasso's", om het aantal verbindingen voor uitgaande (geslingerde) en inkomende (lassoed) te splitsen, maar dit was een onnodige abstractie omdat het beter is om pakketten te taggen met hun bestemming, hoewel de hoofdbedoeling was om verschillende tarieflimieten aan te bieden voor uitgaande en inkomende verbindingen, dus een scheiding op een hoger niveau tussen omhoog/omlaag leek praktisch.

De client moet alle verbindingen tot stand brengen, omdat we aannemen dat de server geen uitgaande verbindingen kan openen. Wanneer de clients een verbinding ontvangen van een gebruikerstoepassing, stelt deze de vereiste pool van verbindingen op met de server, en welke gegevens het ook ontvangt, het verdeelt het over de speciale verbindingen, volgens een door de gebruiker gedefinieerde limiet.

De pakketten worden vervolgens naar de server gestuurd, die ze in de juiste volgorde moet reconstrueren, omdat verschillende TCP-verbindingen de datastroom op elk moment kunnen beëindigen (verzonden volgorde wordt niet gerespecteerd, omdat routering ) en vervolgens doorgestuurd naar de ontvangende app.

Verbindingen worden gesloten en nieuwe geopend als de geconfigureerde datalimiet per verbinding is bereikt, vergelijkbaar met hoe schaduwsokkenproxy's tunnelen gegevens over verschillende stromen met als doel het gedrag van gegevensstromen te maskeren, behalve dat onze tunnel dat zo vaak mogelijk doet.

Waarom werkt het?

De bedoeling hier is om te bepalen hoeveel gegevens elke verbinding moet verwerken. Voor onze doeleinden was het nooit verder dan was het meestal de MTU venstergrootte. Je kunt de MTU zien als de bovengrens van een stuk data dat in zijn geheel over het netwerk gaat, en het was ons doel omdat we de bandbreedtelimieten van een gated netwerk wilden omzeilen. Om te beperken hoeveel gegevens een klant kan doorgeven, moet u: Graaf het, toch? Als je logica werkt met zoiets als ado-while

Dan moet je minstens ontvang eenpacket . Ik weet niet zeker of dit is wat er werkelijk gebeurt, of dat de reden dat mijn tunnel werkt een andere is. Misschien is het helemaal mogelijk om zelfs het eerste pakket te controleren, maar vanuit een ontwerpperspectief zou dat betekenen dat je zou moeten controleren elk enkele verbinding, wat het systeem zwakker zou maken voor DOS-aanvallen, en ja, mijn tunnel zou gemakkelijk kunnen worden gebruikt als een efficiënte DOS/Stress-tool, omdat je de gegevens kunt splitsen in zeer kleine pakketten (wat betekent dat TCP-verbindingen een hoge recycledruk zullen hebben ) en heb een pool van verbindingen zo groot als je wilt.

Testen over verschillende poorten toonde ook aan dat het alleen mogelijk was over sommige poorten, en dat de limiet constant verschillend was tussen poorten, met443 het geven van een van de hogere ramen, rond20kb , gissen omdatTLS handshakes vereisen meer gegevens en dat deze snelheidslimieten zouden veranderen op basis van het tijdstip van de dag[2].

Resultaten

Ik probeerde codering te wissen in de hoop de gegevensdoorvoer te vergroten. Door een wiscoderingsbibliotheek te gebruiken en de gegevens zelf te coderen/decoderen, en ook door de KCP protocol over mijn splitsingsprotocol. KCP uitproberen lijkt misschien een achterwaartse benadering, omdat het een betere latentie inruilt voor een lagere doorvoer, maar mijn eerste veronderstelling was dat mijn knelpunt was in verbindingen die halverwege de transmissie wegvielen, wat veel beschadigde pakketten zou veroorzaken, dus ik had een hogere doorvoer met foutcorrectie.

Het bleek slechts een snelheidslimiet te zijn voor het aantal TCP-verbindingen dat een client via het netwerk kan verzenden, dus gewoon een DOS-beveiliging waar ik niets aan kan doen. Na X aantal verbindingen willekeurigSYN pogingen stoppen met het ontvangen van hun verschuldigdeACK , de achterstand opvullen en uiteindelijk de tunnel doen ophouden. Trial and error toonde aan dat het mogelijk was tussen4-8[3] verbindingen open op elk willekeurig moment, en met een MTU van500-1000 bytes, je zou op zijn minst een gestage stroom kunnen houden128kbps , als een constante stroom geen vereiste was, zou je hogere snelheden in een kortere tijdsperiode kunnen bereiken door barstend veel aansluitingen op aanvraag.

Daarentegen een (echte)DNS tunnel kan nauwelijks duwen56kbps en kan snel worden afgeremd omdat ik denk dat een groot aantal DNS-verzoeken er verdachter uitziet dan TCP-verzoeken. We moeten specificeren dat atrue DNS-tunnel codeert (uitgaande) gegevens over valse subdomeinen en decodeert (inkomende) gegevens die zijn ontvangen door DNS-records op te vragen, terwijl soms kan worden gedacht dat een DNS-tunnel een onbewerkte UDP-verbinding is via de DNS-poort, die waarschijnlijk ergens in het verleden DNS-servers toegestaan ​​en correct doorgestuurd.

conclusies

Ik weet niet zeker of ik mijn doel heb bereikt nut verstandig, aangezien het gebruik van zo'n soort tunnel je telefoon behoorlijk heet kan maken en veel batterij kan verspillen, maar het als een back-upverbinding hebben kan geruststellend zijn ... als ik echt de moeite heb genomen om het stabiel genoeg te maken :)

[1]meestal wanneer een simkaart geen gegevens meer heeft om op internet te surfen, worden webverzoeken omgeleid naar de capture-gateway (om u te vertellen dat u meer gegevens moet kopen)
[2]mobiele data-abonnementen kunnen 's nachts een betere verbinding bieden
[3]Dit aantal, enigszins afgestemd op het aantal gemeenschappelijke kernen, zou je kunnen doen vermoeden dat de kernel op de een of andere manier verbindingen beperkt, het scenario van geopende verbindingen van onze tunnel is absoluut ongebruikelijk, maar het afstemmen van linux-knoppen gaf nooit betere resultaten aan mijn kant.

Berichttags: