•  notreh-light

TCSplitter

ช่องสัญญาณเพื่อแยกการเชื่อมต่อ TCP หรือ UDP ข้ามการเชื่อมต่อ TCP หลายรายการ

เป้าหมาย

คุณต้องการแยกการเชื่อมต่อ TCP หนึ่งรายการออกเป็นหลาย ๆ การเชื่อมต่อเมื่อใด โดยปกติคุณใช้ a อุโมงค์ เพื่อให้ได้ ตรงกันข้าม . กรณีการใช้งานของฉันหลีกเลี่ยงข้อจำกัดแบนด์วิดท์ในเครือข่ายมือถือ ดังนั้นการทดสอบจึงดำเนินการด้วยซิมการ์ดที่ไม่มีข้อมูลเหลืออยู่ในแผน[1].

มันทำงานอย่างไร

NS อุโมงค์ ถูกเขียนใน golang เนื่องจากมันเร็วพอ และมักใช้สำหรับเครื่องมือเครือข่าย cli ใช้งานไม่ได้เนื่องจากตัวเลือกส่วนใหญ่ถูกทำใหม่ในขณะที่ฉันทดสอบวิธีการต่างๆ

เริ่มแรกมี "flings" และ "lassos" เพื่อแบ่งจำนวนการเชื่อมต่อสำหรับขาออก (flinged) และขาเข้า (lassoed) แต่นี่เป็นนามธรรมที่ไม่จำเป็น เนื่องจากเป็นการดีกว่าที่จะแท็กแพ็กเก็ตที่มีปลายทาง แม้ว่าจุดประสงค์หลักจะเป็น เพื่อเสนอขีดจำกัดอัตราที่แตกต่างกันสำหรับการเชื่อมต่อขาออกและขาเข้า ดังนั้นการแยกระดับที่สูงขึ้นระหว่างขึ้น/ลงจึงดูเหมือนเป็นประโยชน์

ลูกค้าต้องสร้างอินสแตนซ์ของการเชื่อมต่อทั้งหมด เนื่องจากเราคิดว่าเซิร์ฟเวอร์ไม่สามารถเปิดการเชื่อมต่อขาออกได้ เมื่อไคลเอ็นต์ได้รับการเชื่อมต่อจากแอปพลิเคชันของผู้ใช้ ไคลเอ็นต์จะตั้งค่าพูลการเชื่อมต่อกับเซิร์ฟเวอร์ที่ต้องการ และข้อมูลใดก็ตามที่ได้รับ จะแยกการเชื่อมต่อระหว่างการเชื่อมต่อเฉพาะตามขีดจำกัดที่ผู้ใช้กำหนด

แพ็กเก็ตจะถูกส่งไปยังเซิร์ฟเวอร์ ซึ่งต้องสร้างใหม่ตามลำดับที่ถูกต้อง เนื่องจากการเชื่อมต่อ TCP ที่แตกต่างกันสามารถเสร็จสิ้นการสตรีมข้อมูลเมื่อใดก็ได้ (ไม่เคารพคำสั่งที่ส่ง เพราะการกำหนดเส้นทาง ) แล้วส่งต่อไปยังแอปที่รับ

การเชื่อมต่อถูกปิดและเปิดใหม่เมื่อถึงขีดจำกัดข้อมูลที่กำหนดค่าต่อการเชื่อมต่อ คล้ายกับวิธีการ ถุงเท้าพร็อกซีข้อมูลทันเนลในสตรีมต่างๆ โดยมีเป้าหมายเพื่อปกปิดพฤติกรรมของสตรีมข้อมูล ยกเว้นว่าทันเนลของเราจะทำเช่นนั้นบ่อยที่สุด

ทำไมมันถึงได้ผล

ความตั้งใจที่นี่คือการควบคุมปริมาณข้อมูลที่ทุกการเชื่อมต่อควรจัดการ สำหรับจุดประสงค์ของเรา มันไม่เคยเกินเลย ปกติคือ MTU ขนาดหน้าต่าง. คุณสามารถมองว่า MTU เป็นขอบเขตบนของชิ้นส่วนข้อมูลที่ส่งผ่านทั้งหมดทั่วทั้งเครือข่าย และเป็นเป้าหมายของเราเพราะเราต้องการเลี่ยงการจำกัดอัตราแบนด์วิดท์ของเครือข่ายแบบมีรั้วรอบขอบชิด เพื่อจำกัดจำนวนข้อมูลที่ลูกค้าสามารถผ่านได้ คุณต้อง นับ มันใช่มั้ย? ถ้าตรรกะของคุณใช้ได้กับบางอย่างเช่น ado-while

จากนั้นคุณต้อง อย่างน้อย รับpacket . ฉันไม่แน่ใจว่านี่คือสิ่งที่เกิดขึ้นจริงหรือเหตุผลที่อุโมงค์ของฉันทำงานเป็นอีกสาเหตุหนึ่ง อาจเป็นไปได้ทั้งหมดที่จะตรวจสอบแม้แต่แพ็กเก็ตแรก แต่จากมุมมองของการออกแบบ นั่นหมายความว่าคุณจะต้องตรวจสอบ ทั้งหมด การเชื่อมต่อเดียว ซึ่งจะทำให้ระบบอ่อนแอต่อการโจมตี DOS และใช่ อุโมงค์ของฉันสามารถใช้เป็นเครื่องมือ DOS/Stress ที่มีประสิทธิภาพได้อย่างง่ายดาย เนื่องจากคุณสามารถแบ่งข้อมูลเป็นแพ็กเก็ตขนาดเล็กมาก (ซึ่งหมายความว่าการเชื่อมต่อ TCP จะมีแรงกดดันในการรีไซเคิลสูง ) และเชื่อมต่อได้มากเท่าที่คุณต้องการ

การทดสอบผ่านพอร์ตต่าง ๆ ยังแสดงให้เห็นว่าเป็นไปได้มากกว่า .เท่านั้น บาง พอร์ตและขีดจำกัดนั้นแตกต่างกันอย่างต่อเนื่องระหว่างพอร์ตด้วย443 ให้หน้าต่างบานหนึ่งที่อยู่สูงขึ้นไปรอบ ๆ20kb เดาเพราะTLS การจับมือกันต้องการข้อมูลเพิ่มเติม และการจำกัดอัตราเหล่านี้จะเปลี่ยนแปลงตามเวลาของวัน[2].

ผลลัพธ์

ฉันพยายามลบการเข้ารหัสโดยหวังว่าจะเพิ่มปริมาณข้อมูล โดยใช้ไลบรารีการเข้ารหัสการลบและเข้ารหัส/ถอดรหัสข้อมูลเอง และโดยการซ้อนทับ KCP โปรโตคอลบนโปรโตคอลการแยกของฉัน การลองใช้ KCP อาจดูเหมือนเป็นแนวทางย้อนหลัง เนื่องจากมันแลกเวลาแฝงที่ดีกว่าสำหรับปริมาณงานที่ต่ำกว่า แต่ข้อสันนิษฐานเบื้องต้นของฉันคือคอขวดของฉันอยู่ในการเชื่อมต่อหลุดระหว่างการส่ง ซึ่งจะทำให้แพ็กเก็ตเสียหายจำนวนมาก ดังนั้นฉันจึงสามารถบรรลุผลที่สูงขึ้นได้ ปริมาณงานที่มีการแก้ไขข้อผิดพลาด

ปรากฎว่ามันเป็นเพียงอัตราจำกัดสำหรับจำนวนการเชื่อมต่อ TCP ที่ไคลเอนต์สามารถส่งผ่านเครือข่าย ดังนั้นเพียงแค่การป้องกัน DOS ที่ฉันไม่สามารถทำอะไรได้เลย หลังจาก X จำนวนการเชื่อมต่อใด ๆSYN พยายามที่จะหยุดรับเนื่องจากพวกเขาACK เติมงานค้างและในที่สุดก็ทำอุโมงค์แผงลอย การลองผิดลองถูกพบว่าเป็นไปได้ระหว่าง4-8[3] การเชื่อมต่อเปิดในเวลาใดก็ตามและด้วย MTU ของ500-1000 ไบต์คุณสามารถเก็บกระแสข้อมูลได้อย่างน้อย128kbps หากกระแสคงที่ไม่ใช่ข้อกำหนด คุณสามารถบรรลุความเร็วที่สูงขึ้นในช่วงเวลาที่สั้นลงได้ ระเบิด การเชื่อมต่อมากมายตามความต้องการ

ในทางตรงกันข้าม a (จริง)DNS อุโมงค์แทบไม่ดัน56kbps และสามารถควบคุมปริมาณได้อย่างรวดเร็ว เพราะฉันคิดว่าคำขอ DNS จำนวนมากดูน่าสงสัยมากกว่าคำขอ TCP เราต้องระบุว่า atrue อุโมงค์ข้อมูล DNS เข้ารหัสข้อมูล (ขาออก) บนโดเมนย่อยปลอมและถอดรหัสข้อมูล (ขาเข้า) ที่ได้รับจากการสืบค้นระเบียน DNS ในขณะที่บางครั้งช่องสัญญาณ DNS อาจคิดว่าเป็นการเชื่อมต่อ UDP ดิบผ่านพอร์ต DNS ซึ่งอาจเป็นบางครั้งในอดีต เซิร์ฟเวอร์ DNS อนุญาตและส่งต่ออย่างถูกต้อง

บทสรุป

ฉันไม่แน่ใจว่าฉันบรรลุเป้าหมายของฉัน คุณประโยชน์ ที่ฉลาดเนื่องจากการเรียกใช้อุโมงค์แบบนี้อาจทำให้โทรศัพท์ของคุณค่อนข้างร้อนและเปลืองแบตเตอรี่มาก แต่การมีไว้เป็นการเชื่อมต่อสำรองสามารถทำให้เกิดความมั่นใจ...ถ้าฉันใส่ใจที่จะทำให้มันเสถียรพอ :)

[1]โดยปกติเมื่อซิมการ์ดไม่มีข้อมูลในการท่องเว็บอีกต่อไป คำขอเว็บจะเปลี่ยนเส้นทางไปยังเกตเวย์การดักจับ (เพื่อบอกให้คุณซื้อข้อมูลเพิ่มเติม)
[2]แผนข้อมูลมือถือสามารถให้การเชื่อมต่อที่ดีขึ้นในช่วงเวลากลางคืน
[3]ตัวเลขนี้ ซึ่งค่อนข้างจะสอดคล้องกับจำนวนคอร์ทั่วไป อาจทำให้คุณสงสัยว่าเคอร์เนลกำลังจำกัดการเชื่อมต่อ สถานการณ์ของการเชื่อมต่อแบบเปิดของอุโมงค์ของเรานั้นผิดปกติแน่นอน แต่การปรับแต่งปุ่ม linux ไม่เคยให้ผลลัพธ์ที่ดีกว่าในส่วนของฉัน

โพสต์แท็ก: