•  untoreh-luce

TCSplitter

Un tunnel per dividere la connessione TCP o UDP su più connessioni TCP

Obiettivo

Quando vorresti dividere una connessione TCP in più connessioni? Di solito usi a tunnel realizzare l'esatto contrario . Il mio caso d'uso era aggirare i limiti di larghezza di banda in una rete mobile, quindi i test sono stati eseguiti con una scheda SIM senza più dati sul suo piano[1].

Come funziona

Il tunnel è stato scritto in golang poiché è abbastanza veloce e comunemente usato per gli strumenti di rete. Il cli è a malapena utilizzabile poiché la maggior parte delle opzioni è stata rielaborata mentre testavo metodi diversi.

Inizialmente c'erano "fling" e "lassos", per dividere il numero di connessioni in uscita (flinged) e in entrata (lasso), ma questa era un'astrazione inutile poiché è meglio etichettare i pacchetti con la loro destinazione, sebbene l'intenzione principale fosse offrire limiti di velocità diversi per le connessioni in uscita e in entrata, quindi sembrava pratica una separazione di livello più alto tra up/down.

Il client deve istanziare tutte le connessioni poiché presumiamo che il server non possa aprire connessioni in uscita. Quando i client ricevono una connessione da un'applicazione utente, imposta il pool di connessioni richiesto con il server e, qualunque dato riceva, lo divide tra le connessioni dedicate, in base a un limite definito dall'utente.

I pacchetti vengono quindi inviati al server, che deve ricostruirli nell'ordine corretto, poiché diverse connessioni TCP possono terminare il flusso di dati in qualsiasi momento (l'ordine inviato non viene rispettato, perché il routing ), quindi inoltrato all'app ricevente.

Le connessioni vengono chiuse e ne vengono aperte di nuove quando viene raggiunto il limite di dati configurato per connessione, in modo simile a come calze d'ombra i proxy eseguono il tunnel dei dati attraverso flussi diversi con l'obiettivo di mascherare il comportamento dei flussi di dati, tranne per il fatto che il nostro tunnel lo fa il più frequentemente possibile.

Perché funziona

L'intenzione è quella di controllare la quantità di dati che ogni connessione dovrebbe gestire. Per i nostri scopi, non è mai stato al di là di solito è il MTU dimensione della finestra. Puoi pensare all'MTU come al limite superiore di un pezzo di dati che passa per intero attraverso la rete, ed era il nostro obiettivo perché volevamo bypassare i limiti di larghezza di banda di una rete chiusa. Per limitare la quantità di dati che un cliente può attraversare, è necessario contare questo, giusto? Se la tua logica funziona con qualcosa come ado-while

Allora devi almeno ricevere unpacket. Non sono sicuro se questo è ciò che accade realmente, o il motivo per cui il mio tunnel funziona è un altro. Forse è del tutto possibile controllare anche il primo pacchetto, ma dal punto di vista del design, ciò significherebbe che dovresti controllare ogni connessione singola, che renderebbe il sistema più debole agli attacchi DOS, e sì, il mio tunnel potrebbe essere facilmente utilizzato come un efficiente strumento DOS/Stress, poiché è possibile dividere i dati in pacchetti molto piccoli (il che significa che le connessioni TCP avranno un'elevata pressione di riciclo ) e disponi di un pool di connessioni grande quanto vuoi.

Anche i test su porte diverse hanno mostrato che era possibile solo oltre alcuni porti, e che il limite era costantemente diverso tra i porti, con443 dando una delle finestre più alte, intorno20kb , indovinando perchéTLS le strette di mano richiedono più dati e che questi limiti di velocità cambierebbero in base all'ora del giorno[2].

Risultati

Ho provato a cancellare la codifica nella speranza di aumentare il throughput dei dati. Usando una libreria di codifica di cancellazione e codificando/decodificando i dati stessi, e anche sovrapponendo il KCP protocollo sul mio protocollo di suddivisione. Provare KCP potrebbe sembrare un approccio all'indietro, dal momento che scambia una migliore latenza per un throughput inferiore, ma la mia ipotesi iniziale era che il mio collo di bottiglia fosse nelle connessioni interrotte a metà della trasmissione, il che avrebbe causato molti pacchetti danneggiati, quindi avrei potuto ottenere un maggiore throughput con correzione degli errori.

Si è scoperto che era solo un limite di velocità su quante connessioni TCP un client può inviare sulla rete, quindi solo una protezione DOS su cui non posso fare nulla. Dopo X quantità di connessioni qualsiasiSYN i tentativi smettono di ricevere il dovutoACK, riempiendo l'arretrato ed eventualmente facendo stallo il tunnel. Prove ed errori hanno dimostrato che era possibile tra4-8[3] connessioni aperte in qualsiasi momento e con un MTU di500-1000 byte che potresti mantenere almeno un flusso costante128kbps , se un flusso costante non fosse un requisito, potresti raggiungere velocità più elevate in un periodo di tempo più breve di scoppiare molti collegamenti su richiesta.

Al contrario, un (vero)DNS il tunnel riesce a malapena a spingere56kbps e può essere rapidamente limitato perché penso che un numero elevato di richieste DNS appaia più sospetto delle richieste TCP. Dobbiamo specificare che atrue Il tunnel DNS codifica i dati (in uscita) su sottodomini fasulli e decodifica i dati (in entrata) ricevuti interrogando i record DNS, mentre a volte si può pensare che un tunnel DNS sia una connessione UDP grezza sulla porta DNS, che probabilmente in passato, i server DNS consentito e inoltrato correttamente.

Conclusioni

Non sono sicuro di aver raggiunto il mio obiettivo utilità saggio, dal momento che l'esecuzione di questo tipo di tunnel può far surriscaldare il telefono e sprecare molta batteria, ma averlo come connessione di backup può essere rassicurante ... se davvero mi fossi preso la briga di renderlo abbastanza stabile :)

[1]di solito quando una scheda SIM non ha più dati per navigare sul web, le richieste web reindirizzano al gateway di acquisizione (per dirti di acquistare più dati)
[2]i piani dati mobili possono fornire una connessione migliore durante le ore notturne
[3]Questo numero, in qualche modo allineato ai conteggi dei core comuni, potrebbe indurre a sospettare che il kernel stia in qualche modo limitando le connessioni, lo scenario di connessioni aperte del nostro tunnel è decisamente insolito, ma la messa a punto delle manopole di linux non ha mai dato risultati migliori da parte mia.

Tag degli articoli: