•  원더라이트

TCSplitter

여러 TCP 연결에서 TCP 또는 UDP 연결을 분할하는 터널

목표

언제 하나의 TCP 연결을 여러 연결로 분할하고 싶습니까? 일반적으로 사용하는 터널 달성하다 정반대 . 내 사용 사례는 모바일 네트워크의 대역폭 제한을 우회하는 것이었으므로 계획에 더 이상 데이터가 남아 있지 않은 SIM 카드로 테스트를 수행했습니다.[1].

작동 원리

NS 터널 에 쓰여졌다 골랑 충분히 빠르기 때문에 일반적으로 네트워크 도구에 사용됩니다. 다른 방법을 테스트하면서 대부분의 옵션이 재작업되었기 때문에 cli는 거의 사용할 수 없습니다.

초기에는 발신(flinged) 및 수신(lassoed)에 대한 연결 수를 분할하기 위해 "flings" 및 "lassos"가 있었지만 주요 의도는 패킷에 대상에 태그를 지정하는 것이 더 좋기 때문에 불필요한 추상화였습니다. 나가는 연결과 들어오는 연결에 대해 서로 다른 속도 제한을 제공하기 위해 위/아래를 더 높은 수준으로 분리하는 것이 실용적으로 보였습니다.

서버가 나가는 연결을 열 수 없다고 가정하기 때문에 클라이언트는 모든 연결을 인스턴스화해야 합니다. 클라이언트가 사용자 응용 프로그램에서 연결을 수신하면 서버에 필요한 연결 풀을 설정하고 수신한 데이터가 무엇이든 사용자 정의 제한에 따라 전용 연결 간에 분할합니다.

다른 TCP 연결이 언제든지 데이터 스트림을 마칠 수 있기 때문에 패킷은 올바른 순서로 재구성해야 하는 서버로 전송됩니다(전송된 순서는 존중되지 않으며, 라우팅 때문에 ) 그런 다음 수신 앱으로 전달됩니다.

연결당 구성된 데이터 제한에 도달하면 연결이 닫히고 새 연결이 열립니다. 그림자 양말우리 터널이 가능한 한 자주 그렇게 하는 것을 제외하고 데이터 스트림의 동작을 마스킹하는 것을 목표로 서로 다른 스트림에서 데이터 터널링을 프록시합니다.

작동하는 이유

여기서 의도는 모든 연결이 처리해야 하는 데이터의 양을 제어하는 ​​것입니다. 우리의 목적을 위해, 그것은 결코 넘지 않았으며 일반적으로 MTU 창 크기. MTU는 네트워크 전체를 통과하는 데이터의 상한선으로 생각할 수 있으며 게이트 네트워크의 대역폭 속도 제한을 우회하기를 원했기 때문에 MTU가 목표였습니다. 클라이언트가 전달할 수 있는 데이터의 양을 제한하려면 다음을 수행해야 합니다. 세다 그렇지, 그렇지? 논리가 다음과 같이 작동하는 경우do-while

그럼 당신은해야합니다 적어도 받다packet . 이것이 실제로 일어나는 것인지, 아니면 내 터널이 작동하는 이유가 다른 것인지 확실하지 않습니다. 어쩌면 첫 번째 패킷을 확인하는 것이 완전히 가능할 수도 있지만 디자인 관점에서는 확인해야 한다는 것을 의미합니다. 모든 단일 연결은 시스템을 DOS 공격에 약하게 만들고, 내 터널은 데이터를 매우 작은 패킷으로 분할할 수 있기 때문에 효율적인 DOS/스트레스 도구로 쉽게 사용할 수 있습니다. ) 원하는 만큼 큰 연결 풀이 있습니다.

다른 포트에서 테스트한 결과 일부 포트 간에 제한이 지속적으로 다르며,443 주위에 더 높은 창 중 하나를 제공20kb , 추측하기 때문에TLS 핸드셰이크에는 더 많은 데이터가 필요하며 이러한 속도 제한은 시간에 따라 변경됩니다.[2].

결과

데이터 처리량을 늘리기 위해 이레이저 코딩을 시도했습니다. 이레이저 코딩 라이브러리를 사용하여 데이터 자체를 인코딩/디코딩하고, KCP 내 분할 프로토콜을 통한 프로토콜. KCP를 시도하는 것은 더 낮은 처리량에 대해 더 나은 대기 시간을 교환하기 때문에 역방향 접근 방식으로 보일 수 있지만 내 초기 가정은 내 병목 현상이 전송 도중 연결이 끊어져 패킷이 많이 손상될 수 있다는 것이었습니다. 오류 수정을 통한 처리량.

클라이언트가 네트워크를 통해 보낼 수 있는 TCP 연결 수에 대한 속도 제한이라는 것이 밝혀졌습니다. 따라서 DOS 보호에 대해서는 아무 것도 할 수 없습니다. X 양의 연결 후SYN 시도는 그들의 정당한 수신을 중지합니다ACK , 백로그를 채우고 결국 터널을 정지시킵니다. 시행착오를 통해4-8[3] 주어진 시간에 연결이 열리고 MTU가500-1000 적어도 일정한 스트림을 유지할 수 있는 바이트128kbps , 일정한 스트림이 요구 사항이 아닌 경우 다음을 통해 더 짧은 시간 동안 더 높은 속도를 얻을 수 있습니다. 파열 요청 시 많은 연결.

이에 반해 (사실)DNS 터널은 간신히 밀 수 있습니다56kbps 많은 수의 DNS 요청이 TCP 요청보다 더 의심스러워 보이기 때문에 빠르게 제한될 수 있습니다. 우리는 다음을 지정해야 합니다.true DNS 터널은 가짜 하위 도메인을 통해 데이터를 인코딩(나가는)하고 DNS 레코드를 쿼리하여 수신한 데이터를 디코딩(들어오는)하는 반면, 때때로 DNS 터널은 DNS 포트를 통한 원시 UDP 연결로 생각할 수 있습니다. 허용되고 올바르게 전달되었습니다.

결론

목표에 도달했는지 확신할 수 없음 공익 사업 현명하게, 이러한 종류의 터널을 실행하면 전화기가 상당히 뜨거워지고 많은 배터리가 낭비될 수 있기 때문에 백업 연결로 사용하면 안심할 수 있습니다.

[1]일반적으로 SIM 카드에 웹을 탐색할 데이터가 더 이상 없으면 웹 요청이 캡처 게이트웨이로 리디렉션됩니다(더 많은 데이터를 구매하라고 알려줌)
[2]모바일 데이터 요금제는 야간에 더 나은 연결을 제공할 수 있습니다.
[3]일반적인 코어 수와 어느 정도 일치하는 이 숫자는 커널이 어떻게든 연결을 제한하고 있다고 의심하게 만들 수 있습니다. 터널의 열린 연결 시나리오는 확실히 이례적이지만 Linux 손잡이를 조정해도 내 입장에서는 더 나은 결과를 얻지 못했습니다.

게시물 태그: