•  ανοικτό φως

TCSplitter

Μια σήραγγα για τη διάσπαση της σύνδεσης TCP ή UDP σε πολλές συνδέσεις TCP

Στόχος

Πότε θα θέλατε να χωρίσετε μία σύνδεση TCP σε πολλές; Συνήθως χρησιμοποιείτε α σήραγγα να επιτύχω το ακριβώς αντίθετο Το Η περίπτωση χρήσης μου ήταν η παράκαμψη των περιορισμών εύρους ζώνης σε δίκτυο κινητής τηλεφωνίας, οπότε οι δοκιμές πραγματοποιήθηκαν με κάρτα SIM χωρίς να απομένουν περισσότερα δεδομένα στο σχέδιό της[1].

Πώς λειτουργεί

ο σήραγγα γράφτηκε στο golang δεδομένου ότι είναι αρκετά γρήγορος και χρησιμοποιείται συνήθως για εργαλεία δικτύου. Το cli είναι ελάχιστα χρησιμοποιήσιμο αφού οι περισσότερες από τις επιλογές επαναλειτουργήθηκαν καθώς δοκίμασα διαφορετικές μεθόδους.

Αρχικά υπήρχαν "flings" και "lassos", για να χωρίσουν τον αριθμό των συνδέσεων για εξερχόμενες (εισερχόμενες) και εισερχόμενες (lassoed), αλλά αυτό ήταν μια περιττή αφαίρεση αφού είναι προτιμότερο να επισημαίνονται τα πακέτα με τον προορισμό τους, αν και η κύρια πρόθεση ήταν να προσφέρει διαφορετικά όρια τιμών για εξερχόμενες και εισερχόμενες συνδέσεις, οπότε ένας υψηλότερος διαχωρισμός μεταξύ άνω/κάτω φαινόταν πρακτικός.

Ο πελάτης πρέπει να υποδείξει όλες τις συνδέσεις αφού υποθέτουμε ότι ο διακομιστής δεν μπορεί να ανοίξει εξερχόμενες συνδέσεις. Όταν οι υπολογιστές -πελάτες λαμβάνουν μια σύνδεση από μια εφαρμογή χρήστη, δημιουργεί την απαιτούμενη ομάδα συνδέσεων με τον διακομιστή και όποια δεδομένα λαμβάνει, τη χωρίζει μεταξύ των αποκλειστικών συνδέσεων, σύμφωνα με ένα όριο που καθορίζεται από τον χρήστη.

Τα πακέτα κατόπιν αποστέλλεται στο διακομιστή, η οποία έχει να τους ανακατασκευάσει στη σωστή σειρά, επειδή διαφορετικές συνδέσεις TCP μπορεί να τελειώσει το ρεύμα δεδομένων ανά πάσα στιγμή (παραγγελίας που έχει αποσταλεί δεν τηρείται, επειδή δρομολόγηση ), και στη συνέχεια προωθήθηκε στην εφαρμογή λήψης.

Οι συνδέσεις κλείνουν και νέες ανοίγουν καθώς επιτυγχάνεται το όριο δεδομένων που έχει ρυθμιστεί ανά σύνδεση, παρόμοια με το πώς σκιώδεις κηλίδεςμεσολάβησης σηράγγει δεδομένα σε διαφορετική ροή με στόχο τη συγκάλυψη της συμπεριφοράς των ροών δεδομένων, εκτός από το ότι η σήραγγά μας το κάνει αυτό όσο πιο συχνά γίνεται.

Γιατί λειτουργεί

Η πρόθεση εδώ είναι να ελέγξουμε πόσα δεδομένα πρέπει να χειρίζεται κάθε σύνδεση. Για τους σκοπούς μας, δεν ήταν ποτέ πέρα ​​ήταν συνήθως είναι MTU μέγεθος παραθύρου. Μπορείτε να σκεφτείτε το MTU ως το ανώτερο όριο ενός τεμαχίου δεδομένων που περνά ολόκληρο στο δίκτυο και ήταν ο στόχος μας επειδή θέλαμε να παρακάμψουμε τα όρια του εύρους ζώνης ενός κλειστού δικτύου. Για να περιορίσετε πόσα δεδομένα μπορεί να περάσει ένας πελάτης, πρέπει μετρώ αυτό, σωστά; Εάν η λογική σας λειτουργεί με κάτι σαν αdo-while

Τότε πρέπει τουλάχιστον λαμβάνω αpacket Το Δεν είμαι σίγουρος αν αυτό συμβαίνει στην πραγματικότητα ή ο λόγος που λειτουργεί το τούνελ μου είναι άλλος. Maybeσως είναι εντελώς δυνατό να ελέγξετε ακόμη και το πρώτο πακέτο, αλλά από την άποψη της σχεδίασης, αυτό θα σήμαινε ότι θα έπρεπε να το ελέγξετε κάθε απλή σύνδεση, η οποία θα έκανε το σύστημα πιο αδύναμο σε επιθέσεις DOS και ναι, η σήραγγά μου θα μπορούσε εύκολα να χρησιμοποιηθεί ως αποτελεσματικό εργαλείο DOS/Stress, καθώς μπορείτε να χωρίσετε τα δεδομένα σε πολύ μικρά πακέτα (πράγμα που σημαίνει ότι οι συνδέσεις TCP θα έχουν υψηλή πίεση ανακύκλωσης ) και έχετε μια δεξαμενή συνδέσεων όσο μεγάλη θέλετε.

Οι δοκιμές σε διαφορετικές θύρες έδειξαν επίσης ότι ήταν εφικτό μόνο μερικοί λιμένες, και ότι το όριο ήταν συνεχώς διαφορετικό μεταξύ των λιμένων, με443 δίνοντας ένα από τα υψηλότερα παράθυρα, γύρω20kb , μαντεύοντας γιατίTLS Οι χειραψίες απαιτούν περισσότερα δεδομένα και ότι αυτά τα όρια ποσοστών θα αλλάξουν ανάλογα με την ώρα της ημέρας[2].

Αποτελέσματα

Προσπάθησα να σβήσω την κωδικοποίηση με την ελπίδα να αυξήσω την απόδοση δεδομένων. Χρησιμοποιώντας μια βιβλιοθήκη κωδικοποίησης διαγραφής και κωδικοποιώντας/αποκωδικοποιώντας τα ίδια τα δεδομένα, και επίσης επικαλύπτοντας το KCP πρωτόκολλο πάνω από το πρωτόκολλο διαχωρισμού μου. Η δοκιμή του KCP μπορεί να φαίνεται μια αντίστροφη προσέγγιση, δεδομένου ότι ανταλλάσσει καλύτερη καθυστέρηση για χαμηλότερη απόδοση, αλλά η αρχική μου υπόθεση ήταν ότι η συμφόρησή μου ήταν σε συνδέσεις που έπεσαν στη μέση μετάδοσης, κάτι που θα προκαλούσε πολλά κατεστραμμένα πακέτα, οπότε θα μπορούσα να είχα επιτύχει υψηλότερο απόδοση με διόρθωση σφάλματος.

Αποδείχθηκε ότι ήταν απλώς ένα όριο τιμών για το πόσες συνδέσεις TCP μπορεί να στείλει ένας πελάτης μέσω του δικτύου, επομένως μόνο μια προστασία DOS για την οποία δεν μπορώ να κάνω τίποτα. Μετά από Χ ποσότητες συνδέσεων οποιαδήποτεSYN οι προσπάθειες σταματούν να λαμβάνουν την οφειλή τουςACK , γεμίζοντας τις εκκρεμότητες και τελικά κάνοντας το τούνελ να σταματήσει. Η δοκιμή και το λάθος έδειξαν ότι ήταν δυνατό μεταξύ4-8[3] οι συνδέσεις ανοίγουν ανά πάσα στιγμή και με MTU500-1000 bytes μπορείτε να διατηρήσετε μια σταθερή ροή τουλάχιστον τουλάχιστον128kbps , εάν μια σταθερή ροή δεν ήταν απαίτηση, θα μπορούσατε να επιτύχετε υψηλότερες ταχύτητες σε μικρότερο χρονικό διάστημα σκάει πολλές συνδέσεις κατά παραγγελία.

Αντίθετα, ένα (αληθινό)DNS το τούνελ μετά βίας μπορεί να σπρώξει56kbps και μπορεί να γκρεμιστεί γρήγορα επειδή πιστεύω ότι ένας μεγάλος αριθμός αιτημάτων DNS φαίνεται πιο ύποπτος από τα αιτήματα TCP. Πρέπει να διευκρινίσουμε ότι αtrue Η σήραγγα DNS κωδικοποιεί (εξερχόμενα) δεδομένα σε ψευδείς υποτομείς και αποκωδικοποιεί (εισερχόμενα) δεδομένα που λαμβάνονται με ερώτηση εγγραφών DNS, ενώ μερικές φορές μια σήραγγα DNS μπορεί να θεωρηθεί ότι είναι μια ακατέργαστη σύνδεση UDP μέσω της θύρας DNS, η οποία πιθανώς κάποτε στο παρελθόν, διακομιστές DNS επιτρέπεται και προωθείται σωστά.

Συμπεράσματα

Δεν είμαι σίγουρος ότι έφτασα στο στόχο μου χρησιμότητα σοφό, δεδομένου ότι η εκτέλεση ενός τέτοιου είδους σήραγγας μπορεί να σας κάνει να ζεσταίνετε αρκετά και να χάσετε πολλή μπαταρία, αλλά το να το έχετε ως εφεδρική σύνδεση μπορεί να είναι καθησυχαστικό ... αν πραγματικά μπήκα στον κόπο να το κάνω αρκετά σταθερό :)

[1]συνήθως όταν μια κάρτα SIM δεν έχει περισσότερα δεδομένα για περιήγηση στον ιστό, τα αιτήματα ιστού ανακατευθύνονται στην πύλη καταγραφής (για να σας πει να αγοράσετε περισσότερα δεδομένα)
[2]τα σχέδια δεδομένων κινητής τηλεφωνίας μπορούν να παρέχουν καλύτερη σύνδεση κατά τις νυχτερινές ώρες
[3]Αυτός ο αριθμός, κάπως ευθυγραμμισμένος με τους κοινούς αριθμούς πυρήνων, μπορεί να σας κάνει να υποψιαστείτε ότι ο πυρήνας περιορίζει τις συνδέσεις με κάποιο τρόπο, το σενάριο των ανοιγμένων συνδέσεων της σήραγγας μας είναι σίγουρα ασυνήθιστο, αλλά η ρύθμιση των κουμπιών Linux δεν έδωσε ποτέ καλύτερα αποτελέσματα για μένα.

Ετικέτες ανάρτησης: