•  untoreh-light

TCSplitter

Un tunel pentru a împărți conexiunea TCP sau UDP pe mai multe conexiuni TCP

Poartă

Când doriți să împărțiți o conexiune TCP în mai multe? De obicei folosiți un tunel pentru a realiza exact opusul . Cazul meu de utilizare a fost eludarea limitărilor lățimii de bandă într-o rețea mobilă, astfel încât testele au fost efectuate cu o cartelă SIM, fără a mai rămâne date pe planul său[1].

Cum functioneazã

The tunel a fost scris în golang deoarece este suficient de rapid și este utilizat în mod obișnuit pentru instrumentele de rețea. CLI-ul este abia utilizabil, deoarece majoritatea opțiunilor au fost refăcute pe măsură ce am testat diferite metode.

Inițial au existat „flings” și „lassos”, pentru a împărți numărul de conexiuni pentru ieșire (flinged) și de intrare (lassoed), dar aceasta a fost o abstractizare inutilă, deoarece este mai bine să etichetați pachetele cu destinația lor, deși intenția principală a fost pentru a oferi limite de rată diferite pentru conexiunile de ieșire și de intrare, astfel încât o separare la nivel mai înalt între sus / jos părea practic.

Clientul trebuie să instanțieze toate conexiunile, deoarece presupunem că serverul nu poate deschide conexiunile de ieșire. Când clienții primesc o conexiune de la o aplicație de utilizator, aceasta configurează grupul necesar de conexiuni cu serverul și, indiferent de datele pe care le primește, le împarte între conexiunile dedicate, conform unei limite definite de utilizator.

Pachetele sunt apoi trimise la server, care trebuie să le reconstruiască în ordinea corectă, deoarece conexiuni TCP diferite pot termina fluxul de date în orice moment (ordinea trimisă nu este respectată, deoarece rutare ), apoi redirecționat către aplicația de primire.

Conexiunile sunt închise și cele noi deschise pe măsură ce se atinge limita de date configurată pe conexiune, asemănător cu cum umbreleproxy tunelează date în flux diferit cu scopul de a masca comportamentul fluxurilor de date, cu excepția faptului că tunelul nostru face asta cât mai des posibil.

De ce funcționează

Intenția de aici este de a controla cât de multe date ar trebui să gestioneze fiecare conexiune. Pentru scopurile noastre, nu a fost niciodată dincolo, de obicei este MTU dimensiunea ferestrei. Vă puteți gândi la MTU ca la limita superioară a unei bucăți de date care trece întregi prin rețea și a fost ținta noastră pentru că am vrut să ocolim limitele ratei lățimii de bandă a unei rețele închise. Pentru a limita cât de multe date poate trece un client, trebuie să numara nu, nu? Dacă logica ta funcționează cu ceva de genul ado-while

Atunci trebuie macar primi opacket . Nu sunt sigur dacă asta se întâmplă de fapt sau motivul pentru care funcționează tunelul meu este altul. Poate că este total posibil să verificați chiar și primul pachet, dar din perspectiva designului, asta ar însemna că ar trebui să verificați fiecare conexiune unică, ceea ce ar face sistemul mai slab față de atacurile DOS și da, tunelul meu ar putea fi ușor utilizat ca instrument DOS / Stress eficient, deoarece puteți împărți datele în pachete foarte mici (ceea ce înseamnă că conexiunile TCP vor avea o presiune mare de reciclare ) și aveți un grup de conexiuni cât de mare doriți.

Testarea pe diferite porturi a arătat, de asemenea, că este posibil doar peste niste porturi și că limita era constant diferită între porturi, cu443 dând una dintre ferestrele superioare, în jur20kb , ghicind pentru căTLS strângerile de mână necesită mai multe date și că aceste limite de rată se vor schimba în funcție de ora din zi[2].

Rezultate

Am încercat să șterg codarea în speranța de a crește capacitatea de transfer a datelor. Folosind o bibliotecă de codificare a ștergerii și encodarea / decodarea datelor în sine, precum și prin suprapunerea fișierului KCP protocol peste protocolul meu de divizare. Încercarea KCP ar putea părea o abordare inversă, deoarece tranzacționează o latență mai bună pentru un debit mai scăzut, dar presupunerea mea inițială a fost că gâtuirea mea a fost în conexiunile scăzute la mijlocul transmisiei, ceea ce ar provoca o mulțime de pachete corupte, așa că aș fi putut obține o randament cu corectarea erorilor.

S-a dovedit că a fost doar o rată-limită pentru câte conexiuni TCP poate trimite un client prin rețea, deci doar o protecție DOS despre care nu pot face nimic. După X cantități de conexiuni oricareSYN încercările nu mai primesc datoriaACK , umplerea restantei și în cele din urmă blocarea tunelului. Încercarea și eroarea au arătat că este posibil între4-8[3] conexiunile se deschid la un moment dat și cu un MTU de500-1000 octeți ai putea menține un flux constant cel puțin în jur128kbps , dacă un flux constant nu era o cerință, puteți atinge viteze mai mari într-o perioadă mai scurtă de timp izbucnind multe conexiuni la cerere.

În schimb, un (adevărat)DNS tunelul abia poate împinge56kbps și se poate strânge rapid, deoarece cred că un număr mare de cereri DNS pare mai suspect decât cererile TCP. Trebuie să specificăm că atrue Tunelul DNS codifică date (de ieșire) peste subdomenii false și decodează (primite) date primite prin interogarea înregistrărilor DNS, în timp ce uneori un tunel DNS poate fi considerat a fi o conexiune UDP brută pe portul DNS, care probabil cândva în trecut, servere DNS permis și redirecționat corect.

Concluzii

Nu sunt sigur că mi-am atins obiectivul utilitate Înțelept, deoarece rularea unui astfel de tunel vă poate face să telefonați destul de fierbinte și să pierdeți o mulțime de baterii, dar să-l aveți ca o conexiune de rezervă poate fi liniștitor ... dacă m-am deranjat efectiv să-l fac suficient de stabil :)

[1]de obicei, atunci când o cartelă SIM nu mai are date pentru a naviga pe web, solicitările web sunt redirecționate către gateway-ul de captură (pentru a vă spune să cumpărați mai multe date)
[2]planurile de date mobile pot oferi o conexiune mai bună în timpul nopții
[3]Acest număr, oarecum aliniat la numărul de nuclee obișnuit, ar putea să vă inducă să bănuiți că nucleul limitează cumva conexiunile, scenariul conexiunilor deschise al tunelului nostru este cu siguranță neobișnuit, dar reglarea butoanelor Linux nu a dat niciodată rezultate mai bune la sfârșitul meu.

Post Tag-uri: