TCP / IP 재설정 (RST) 플래그가 전송되는 원인은 무엇입니까?

123

내 앱의 TCP / IP 연결이 10 분마다 (정확히 1 ~ 2 초 내에) 계속 딸꾹질하는 이유를 알아 내려고합니다. Wireshark를 실행 한 결과 10 분 동안 활동이 없으면 상대방이 재설정 (RST) 플래그가 설정된 패킷을 보내는 것을 발견했습니다. Google 검색에서 "RESET 플래그는 수신자가 혼란스러워서 연결을 중단하려고 함을 나타냅니다."라는 메시지가 표시되지만 필요한 세부 정보가 조금 부족합니다. 원인은 무엇입니까? 그리고 도중에 일부 라우터가이를 담당 할 수 있습니까? 아니면 항상 다른 엔드 포인트에서 올 수 있습니까?

편집 : 내 컴퓨터와 다른 엔드 포인트 사이에 라우터 (특히 Linksys WRT-54G)가 있습니다. 라우터 설정에서 찾아봐야 할 것이 있습니까?

networking tcp

— 루크
소스

12

여기에 또 다른 정보가 있습니다. Comcast

— Tom Ritter

1

운 좋게도 이것이 LAN 내에서 발생하기 때문에 Comcast에 의존하지 않습니다. 나는 쉽게 비난을 옮길 수 있기를 바란다.)

— Luke

이것을 알아 낸 적이 있습니까? 점수가 충분하지 않아 댓글을 달 수 없습니다.하지만 귀하가 겪고 있던 문제와 똑같은 문제가 있으며 해결 방법을 찾고 있습니다.

이 특정 사례는 어떤 서비스를 의미합니까? 긴 유휴 기간이 리소스 부족으로 인해 연결 재설정을 강제로 시도하지 않도록 (앱 수준에서) 소켓에 Keepalive를 설정할 수 있습니다.

— arielf

"컴캐스트"라고? : D 관련 리포지토리를

— joonas.fi

89

'라우터'는 무엇이든 할 수 있습니다. 특히 NAT는 트래픽에 버그가 많은 엉망이 될 수 있습니다.

장치가 RST를 보내는 한 가지 이유는 닫힌 소켓에 대한 패킷 수신에 대한 응답입니다.

TCP가 시작된 이래로 가능한 모든 변태가 TCP에서 방문되었고 모든 종류의 사람들이 트래픽을 차단하기 위해 RST를 삽입 할 수 있기 때문에 확고하지만 일반적인 대답을하기는 어렵습니다. (예를 들어 일부 '국가 방화벽'은 이와 같이 작동합니다.)

— 윌 딘
소스

6

라우터가 TCP 연결에 대해 10 분 제한 시간을 갖고 있거나 라우터에 "게이트웨이 스마트 패킷 감지"가 활성화되어 있습니다.

— David Schwartz

2

라우터에 버그가있을 수 있다고 제안하는 것은 약간 풍부합니다.

— Marquis of Lorne

23

피어에서 패킷 스니퍼 (예 : Wireshark)를 실행하여 RST를 보내는 피어인지 중간에있는 사람인지 확인합니다.

— 알렉산더
소스

14

이 문제를 해결하는 데 상당한 시간을 보냈습니다. 제안 된 솔루션 중 어느 것도 작동하지 않았습니다. 우리 시스템 관리자가 실수로 서로 다른 그룹에 속하는 두 개의 관련없는 서버에 동일한 고정 IP를 할당했지만 동일한 네트워크에있는 것으로 나타났습니다. 최종 결과는 간헐적으로 vnc 연결이 끊어졌고, 웹 페이지를 가져 오기 위해 여러 번 새로 고쳐야하는 브라우저 및 기타 이상한 것들이었습니다.

— OutputLogic
소스

7

일부 방화벽은 연결이 x 분 동안 유휴 상태 인 경우이를 수행합니다. 일부 ISP는 다양한 이유로 라우터를 설정합니다.

이 시대에는 그 상태를 우아하게 처리 (필요에 따라 다시 설정)해야합니다.

— 브라이언 노블 라 우치
소스

2

연결이 정상적으로 다시 설정됩니다. 문제는 짧은 연결 해제 기간으로 인해 불필요하게 경고가 발생한다는 것입니다.

— Luke

1

특히 Cisco PIX / ASA 장비에 문제가 있습니다. 기본값으로 특히 짧은 시간 제한이 있습니다. 저렴한 장비는 일반적으로 이와 관련하여 "더 좋습니다"(실제로 시간 초과가 발생하지 않기 때문에) ...

— Brian Knoblauch

1

나는 TCP가 영구 연결 관점에서 실제로 완전히 신뢰할 수 없다고 덧붙일 것입니다. 때때로 더 눈에 띄게됩니다. 또 다른 흥미로운 예 : 어떤 사람들은 연결 종료 또는 재설정이 감지되는 즉시 TCP 클라이언트를 오프라인으로 표시하는 논리를 구현할 수 있습니다. 그리고 때때로 그들은 고객에게 다시 연결될 기회를주지 않습니다. 이것은 분명히 완전히 정확하지 않습니다.

— Victor Yarema

7

RST는 마지막 ACK를 보내는 쪽이기 때문에 액티브 클로즈를하는 쪽에서 보냅니다. 따라서 잘못된 상태에서 패시브 클로즈를 한 쪽에서 FIN을 받으면 상대방에게 오류가 발생했음을 알리는 RST 패킷을 보냅니다.

— 비샬 굽타
소스

6

양측은 정상적인 폐쇄로 FIN을 보내고받습니다. 이 상황에는 아무런 문제가 없으므로 한쪽에서 재설정을 실행할 이유가 없습니다. 첫 번째 문장은 말도 안됩니다.

— Marquis of Lorne

2

[RST, ACK]는 수신되지 않는 포트에서 SYN을 수신하는 측에서도 전송할 수 있습니다. 내가 우연히 만난 경우 RST / ACK는 첫 번째 SYN 후 약 60 초 후에 왔습니다. FWIW

— Les

@MarquisofLorne, 첫 번째 문장 자체가 잘못된 것으로 취급 될 수 있습니다. 그러나 두 번째 문장의 "잘못된 상태"라는 문구는 어떻게 든 유효하게 만듭니다.

— Victor Yarema

7

NAT를 수행하는 라우터, 특히 리소스가 거의없는 로우 엔드 라우터가있는 경우 가장 오래된 TCP 세션을 먼저 에이징합니다. 이를 위해 RST수신 스테이션에 (매우 비정상적으로) 연결을 종료하도록 효과적으로 알리는 패킷에 플래그를 설정합니다 . 이것은 자원을 절약하기 위해 수행됩니다.

— MKII
소스

3

주의해야 할 한 가지는 많은 Linux netfilter 방화벽이 잘못 구성되어 있다는 것입니다.

다음과 같은 경우 :

-A FORWARD -m state --state RELATED, ESTABLISHED -j ACCEPT

-A 앞으로 -p tcp -j REJECT --reject-with tcp-reset

그런 다음 패킷 재정렬로 인해 방화벽이 패킷이 유효하지 않은 것으로 간주하고 재설정을 생성하여 정상적인 연결을 끊을 수 있습니다.

재정렬은 특히 무선 네트워크에서 발생할 가능성이 높습니다.

대신 다음과 같아야합니다.

-A FORWARD -m state --state RELATED, ESTABLISHED -j ACCEPT

-A FORWARD -m 상태 --state INVALID -j DROP

-A 앞으로 -p tcp -j REJECT --reject-with tcp-reset

기본적으로 다음이있을 때마다 :

... -m state --state RELATED, ESTABLISHED -j ACCEPT

바로 뒤에 다음이 와야합니다.

... -m state --state INVALID -j DROP

패킷을 삭제 한 다음 tcp 재설정을 방해하는 잠재적 인 프로토콜을 생성하는 것이 좋습니다. 재설정은 보낼 수있는 올바른 것일 때 더 좋습니다. 이렇게하면 시간 초과가 제거되기 때문입니다. 그러나 그들이 무효 일 가능성이 있다면 이런 종류의 고통을 유발할 수 있습니다.

— 미로
소스

0

이는 네트워크에 RST를 TCP 연결로 보내는 다른 프로세스가 있기 때문입니다.

일반적으로 RST는 다음과 같은 경우에 전송됩니다.

SO_LINGER 옵션을 사용하는 소켓이 활성화되면 프로세스가 소켓을 닫습니다.
OS는 소켓을 닫지 않고 프로세스가 종료 될 때 리소스 정리를 수행합니다.

귀하의 경우 프로세스가 연결 (IP + 포트)을 연결하고 연결을 설정 한 후 RST를 계속 전송하는 것처럼 들립니다.

— 벤
소스