•  untoreh-lumière

Séparateur TCS

Un tunnel pour diviser la connexion TCP ou UDP sur plusieurs connexions TCP

But

Quand voudriez-vous diviser une connexion TCP en plusieurs ? Habituellement, vous utilisez un tunnel atteindre l'exact opposé . Mon cas d'utilisation contournait les limitations de bande passante dans un réseau mobile, les tests ont donc été effectués avec une carte SIM sans plus de données sur son plan[1].

Comment ça marche

Les tunnel a été écrit en golang car il est assez rapide et couramment utilisé pour l'outillage réseau. Le cli est à peine utilisable puisque la plupart des options ont été retravaillées au fur et à mesure que j'ai testé différentes méthodes.

Initialement, il y avait des "flings" et des "lassos", pour diviser le nombre de connexions sortantes (flinged) et entrantes (lassoed), mais c'était une abstraction inutile car il est préférable d'étiqueter les paquets avec leur destination, bien que l'intention principale était d'offrir différentes limites de débit pour les connexions sortantes et entrantes, de sorte qu'une séparation de niveau plus élevé entre haut/bas semblait pratique.

Le client doit instancier toutes les connexions car nous supposons que le serveur ne peut pas ouvrir les connexions sortantes. Lorsque les clients reçoivent une connexion d'une application utilisateur, il configure le pool de connexions requis avec le serveur, et quelles que soient les données qu'il reçoit, il les répartit entre les connexions dédiées, selon une limite définie par l'utilisateur.

Les paquets sont ensuite envoyés au serveur, qui doit les reconstruire dans le bon ordre, car différentes connexions TCP peuvent terminer le flux de données à tout moment (l'ordre d'envoi n'est pas respecté, parce que le routage ), puis transmis à l'application de réception.

Les connexions sont fermées et de nouvelles ouvertes lorsque la limite de données configurée par connexion est atteinte, comme chaussettes d'ombreproxies tunnel les données à travers différents flux dans le but de masquer le comportement des flux de données, sauf que notre tunnel le fait aussi souvent que possible.

Pourquoi ça marche

L'intention ici est de contrôler la quantité de données que chaque connexion doit gérer. Pour nos besoins, il n'a jamais été au-delà de ce qui est habituellement le UMT la taille de la fenêtre. Vous pouvez considérer le MTU comme la limite supérieure d'une donnée qui passe entièrement sur le réseau, et c'était notre cible car nous voulions contourner les limites de débit de bande passante d'un réseau fermé. Pour limiter la quantité de données qu'un client peut traverser, vous devez compter ça, non ? Si votre logique fonctionne avec quelque chose comme undo-while

Ensuite, vous devez au moins recevoir unepacket . Je ne sais pas si c'est ce qui se passe réellement, ou la raison pour laquelle mon tunnel fonctionne en est une autre. Peut-être qu'il est tout à fait possible de vérifier même le premier paquet, mais du point de vue de la conception, cela signifierait que vous devriez vérifier tous connexion unique, ce qui rendrait le système plus faible face aux attaques DOS, et oui, mon tunnel pourrait être facilement utilisé comme un outil DOS/Stress efficace, car vous pouvez diviser les données en très petits paquets (ce qui signifie que les connexions TCP auront une pression de recyclage élevée ) et disposez d'un pool de connexions aussi grand que vous le souhaitez.

Des tests sur différents ports ont également montré qu'il n'était possible que sur certains ports, et que la limite était constamment différente entre les ports, avec443 donnant l'une des fenêtres les plus hautes, autour20kb , devinant parce queTLS les poignées de main nécessitent plus de données et que ces limites de débit changeraient en fonction de l'heure de la journée[2].

Résultats

J'ai essayé le codage par effacement dans l'espoir d'augmenter le débit de données. En utilisant une bibliothèque de codage d'effacement et en enc/décodant les données elles-mêmes, et aussi en superposant le KCP protocole sur mon protocole de division. Essayer KCP peut sembler une approche à rebours, car il échange une meilleure latence pour un débit plus faible, mais mon hypothèse initiale était que mon goulot d'étranglement était dans les connexions abandonnées à mi-transmission, ce qui entraînerait beaucoup de paquets corrompus, donc j'aurais pu atteindre un plus haut débit avec correction d'erreur.

Il s'est avéré que c'était juste une limite de débit sur le nombre de connexions TCP qu'un client peut envoyer sur le réseau, donc juste une protection DOS contre laquelle je ne peux rien faire. Après X quantités de connexions toutSYN les tentatives cessent de recevoir leur dûACK , comblant l'arriéré et faisant finalement caler le tunnel. Des essais et des erreurs ont montré qu'il était possible entre4-8[3] connexions ouvertes à tout moment, et avec un MTU de500-1000 octets, vous pourriez garder un flux constant autour d'au moins128kbps , si un flux constant n'était pas une exigence, vous pourriez atteindre des vitesses plus élevées sur une période plus courte en éclatement nombreuses connexions à la demande.

En revanche, un (vrai)DNS le tunnel peut à peine pousser56kbps et peut être rapidement limité car je pense qu'un nombre élevé de requêtes DNS semble plus suspect que les requêtes TCP. Il faut préciser qu'untrue Le tunnel DNS encode les données (sortantes) sur de faux sous-domaines et décode les données (entrantes) reçues en interrogeant les enregistrements DNS, alors qu'un tunnel DNS peut parfois être considéré comme une connexion UDP brute sur le port DNS, qui a probablement déjà été des serveurs DNS. autorisé et transmis correctement.

Conclusion

Je ne suis pas sûr d'avoir atteint mon objectif utilitaire sage, puisque l'exécution d'un tel type de tunnel peut rendre votre téléphone assez chaud et gaspiller beaucoup de batterie, mais l'avoir comme connexion de secours peut être rassurant... si je prends la peine de le rendre suffisamment stable :)

[1]généralement, lorsqu'une carte SIM n'a plus de données pour naviguer sur le Web, les requêtes Web sont redirigées vers la passerelle de capture (pour vous dire d'acheter plus de données)
[2]les plans de données mobiles peuvent fournir une meilleure connexion pendant les heures de nuit
[3]Ce nombre, quelque peu aligné sur le nombre de noyaux communs, pourrait vous amener à soupçonner que le noyau limite les connexions d'une manière ou d'une autre, le scénario des connexions ouvertes de notre tunnel est certainement inhabituel, mais le réglage des boutons Linux n'a jamais donné de meilleurs résultats de mon côté.

Mots-clés :