☰

서버가 TCP SYN 패킷에 대한 응답을 지연함

tag-icon • tag-icon tcp
서버가 TCP SYN 패킷에 대한 응답을 지연함

다음과 같은 네트워크 토폴로지가 있습니다. 워크스테이션 및 서버 네트워크 토폴로지

언제워크스테이션HTTPS 서버에 연결섬기는 사람, 그러면 일반적으로섬기는 사람약 60초의 지연을 두고 SYN+ACK 패킷을 보냅니다. 서버에서 패킷을 캡처하는 방법은 다음과 같습니다.

10:15:21.310878 00:19:e2:9e:df:f0 > 00:11:25:8c:7a:1a, ethertype IPv4 (0x0800), length 74: 10.10.10.160.38256 > 10.10.10.16.443: S 3411497795:3411497795(0) win 29200 <mss 1460,sackOK,timestamp 2503046494 0,nop,wscale 7>
10:15:23.102826 00:19:e2:9e:df:f0 > 00:11:25:8c:7a:1a, ethertype IPv4 (0x0800), length 74: 10.10.10.160.38244 > 10.10.10.16.443: S 3008273869:3008273869(0) win 29200 <mss 1460,sackOK,timestamp 2503046942 0,nop,wscale 7>
10:15:23.326801 00:19:e2:9e:df:f0 > 00:11:25:8c:7a:1a, ethertype IPv4 (0x0800), length 74: 10.10.10.160.38256 > 10.10.10.16.443: S 3411497795:3411497795(0) win 29200 <mss 1460,sackOK,timestamp 2503046998 0,nop,wscale 7>
10:15:27.230802 00:19:e2:9e:df:f0 > 00:11:25:8c:7a:1a, ethertype IPv4 (0x0800), length 74: 10.10.10.160.38244 > 10.10.10.16.443: S 3008273869:3008273869(0) win 29200 <mss 1460,sackOK,timestamp 2503047974 0,nop,wscale 7>
10:15:27.486804 00:19:e2:9e:df:f0 > 00:11:25:8c:7a:1a, ethertype IPv4 (0x0800), length 74: 10.10.10.160.38256 > 10.10.10.16.443: S 3411497795:3411497795(0) win 29200 <mss 1460,sackOK,timestamp 2503048038 0,nop,wscale 7>
10:15:35.422853 00:19:e2:9e:df:f0 > 00:11:25:8c:7a:1a, ethertype IPv4 (0x0800), length 74: 10.10.10.160.38244 > 10.10.10.16.443: S 3008273869:3008273869(0) win 29200 <mss 1460,sackOK,timestamp 2503050022 0,nop,wscale 7>
10:15:35.678797 00:19:e2:9e:df:f0 > 00:11:25:8c:7a:1a, ethertype IPv4 (0x0800), length 74: 10.10.10.160.38256 > 10.10.10.16.443: S 3411497795:3411497795(0) win 29200 <mss 1460,sackOK,timestamp 2503050086 0,nop,wscale 7>
10:15:51.550815 00:19:e2:9e:df:f0 > 00:11:25:8c:7a:1a, ethertype IPv4 (0x0800), length 74: 10.10.10.160.38244 > 10.10.10.16.443: S 3008273869:3008273869(0) win 29200 <mss 1460,sackOK,timestamp 2503054054 0,nop,wscale 7>
10:15:51.806784 00:19:e2:9e:df:f0 > 00:11:25:8c:7a:1a, ethertype IPv4 (0x0800), length 74: 10.10.10.160.38256 > 10.10.10.16.443: S 3411497795:3411497795(0) win 29200 <mss 1460,sackOK,timestamp 2503054118 0,nop,wscale 7>
10:16:24.062769 00:19:e2:9e:df:f0 > 00:11:25:8c:7a:1a, ethertype IPv4 (0x0800), length 74: 10.10.10.160.38256 > 10.10.10.16.443: S 3411497795:3411497795(0) win 29200 <mss 1460,sackOK,timestamp 2503062182 0,nop,wscale 7>
10:16:24.062832 00:11:25:8c:7a:1a > 1c:87:2c:5a:43:e2, ethertype IPv4 (0x0800), length 74: 10.10.10.16.443 > 10.10.10.160.38256: S 561747608:561747608(0) ack 3411497796 win 5792 <mss 1460,sackOK,timestamp 3558683637 2503062182,nop,wscale 2>
10:16:24.062843 00:19:e2:9e:df:f0 > 00:11:25:8c:7a:1a, ethertype IPv4 (0x0800), length 74: 10.10.10.160.38244 > 10.10.10.16.443: S 3008273869:3008273869(0) win 29200 <mss 1460,sackOK,timestamp 2503062182 0,nop,wscale 7>
10:16:24.062860 00:11:25:8c:7a:1a > 1c:87:2c:5a:43:e2, ethertype IPv4 (0x0800), length 74: 10.10.10.16.443 > 10.10.10.160.38244: S 562554685:562554685(0) ack 3008273870 win 5792 <mss 1460,sackOK,timestamp 3558683637 2503062182,nop,wscale 2>
10:16:24.063075 00:19:e2:9e:df:f0 > 00:11:25:8c:7a:1a, ethertype IPv4 (0x0800), length 66: 10.10.10.160.38256 > 10.10.10.16.443: . ack 1 win 229 <nop,nop,timestamp 2503062182 3558683637>
10:16:24.063116 00:19:e2:9e:df:f0 > 00:11:25:8c:7a:1a, ethertype IPv4 (0x0800), length 66: 10.10.10.160.38244 > 10.10.10.16.443: . ack 1 win 229 <nop,nop,timestamp 2503062182 3558683637>

ARP 관련 문제를 배제하기 위해 정적 ARP 항목을 설치했습니다.워크스테이션존재하다섬기는 사람:

# ip neigh show 10.10.10.160                               
10.10.10.160 dev eth0 lladdr 1c:87:2c:5a:43:e2 PERMANENT                      
#

마지막으로 중요한 점은 항상 10.10.10.16에서 10.10.10.160으로 ping을 보낼 수 있다는 점입니다. 예를 들어, 나는 while :; do ping -c 1 -I 10.10.10.16 10.10.10.160 &>/dev/null || date; sleep 2; done달렸다섬기는 사람하루 종일 단 한 번의 핑도 실패하지 않았습니다.

마지막으로 클라이언트가 보낸 TCP SYN 패킷을 비교해 보면 10:15:51.806784(클라이언트에서 아무것도 수신되지 않음)섬기는 사람) 및 10:16:24.062769(에서섬기는 사람) Wireshark에서는 체크섬을 제외하고 동일합니다.

게다가,섬기는 사람측면 방화벽을 구성하는 방법이 첫 번째 규칙입니다.입력하다체인은 10.10.10.160( )의 iptables -I INPUT -s 10.10.10.160 -d 10.10.10.16 -p tcp --syn --dport 443 -j LOGTCP SYN 패킷을 기록하는 것이며 두 번째 규칙은 10.10.10.160의 모든 트래픽을 수락하는 것입니다. 예를 들어 다음 줄은 커널 링 버퍼에 기록됩니다.

IN=eth0 OUT= MAC=00:11:25:8c:7a:1a:00:19:e2:9e:df:f0:08:00 SRC=10.10.10.160 DST=10.10.10.16 LEN=60 TOS=0x00 PREC=0x00 TTL=63 ID=65477 DF PROTO=TCP SPT=40066 DPT=443 WINDOW=29200 RES=0x00 SYN URGP=0

이미 말했듯이 다음 규칙에서 허용됩니다. 이는 tc모든 관련 문제를 배제해야 합니다 netfilter.

다른 클라이언트(예: 10.10.10.170)는 정상적으로 작동합니다.

이 동작의 원인은 무엇입니까?

답변1

여기서 중요한 문제가 보입니다. 서버의 응답이 서버로 전송된 패킷과 다른 경로를 사용한다는 것입니다.

워크스테이션은 WS와 동일한 LAN 세그먼트에 있는 10.10.10.148 주소를 사용하는 대신 라우터 10.10.10.190을 사용하여 해당 10.10.10.16/32 주소(/32? 도면에도 /28이 표시됨)를 통해 서버에 액세스합니다.

그러나 서버에서 WS로의 TCP 패킷은 서버가 WS에 직접 연결할 수 있으므로 라우터를 사용하지 않습니다.

이것이 왜 중요합니까?

그 결과 라우터는 서버의 응답을 볼 수 없으며 연결 상태에 대해 잘못된 생각을 갖게 됩니다(서버가 SYN+ACK로 응답했지만 라우터의 관점에서 보면 연결 상태는 여전히 초기 SYN에 있습니다). .

오늘날 대부분의 라우터와 마찬가지로 서버에서 SYN+ACK가 확인될 때까지(발생하지 않음) WS에서 서버로 향하는 모든 후속 TCP 패킷을 차단할 것입니다.

따라서 실제 문제는 서버가 SYN+ACK를 보내기 전에 60초를 기다리는 것이 아니라 라우터가 초기 SYN 이후 WS에서 서버로의 TCP 트래픽을 차단하는 것일 수 있습니다.

그렇다면 트래픽 덤프는 왜 발생하는 걸까요?

내 이론이 맞다면 귀하의 질문에 게시한 트래픽 덤프는 완전한 덤프가 없기 때문에 사기성입니다.

  • 서버는 이미 첫 번째 요청에 응답했고 이러한 요청은 중복된 요청으로 간주되므로 SYN 요청에 응답하지 않습니다.
  • 10:16:24.062769 및 10:16:24.062860에서 볼 수 있는 것은 아마도 서버가 WS로부터 아무것도 수신하지 않고 약간의 지연 후에 SYN+ACK 응답을 다시 보내는 것일 것입니다.

이 문제를 어떻게 해결하나요?

여러 가지 옵션이 있습니다:

  • 10.10.10.148 IP 주소를 통해 직접 서버에 연결(실제로 수정 사항은 아님)
  • 서버에서 10.10.10.148 IP 주소를 제거합니다. (옵션이 아닌 것 같습니다.)
  • 라우터에서 방화벽 연결 추적을 비활성화합니다. (이것은 옵션이 아니며 결코 이상적이지 않은 것 같습니다.)
  • 라우터의 MAC 주소 00:19:e2:9e:df:f0을 서버의 10.10.10.160에 대한 ARP 테이블에 입력합니다. (IMHO 이것은 10.10.10.148 IP를 통해 서버에 직접 연결할 때 보기 흉한 해킹입니다. 결국 또 다른 유사한 문제가 발생합니다. 주소(SYN 패킷은 라우터를 사용하지 않지만 서버의 응답은 라우터를 사용하므로)
  • 소스 기반 라우팅(정책 라우팅)을 사용하여 나가는 패킷의 소스 주소가 10.10.10.16인 경우 대상 주소에 관계없이 라우터를 사용하도록 서버에 알립니다.

물론, 실제로 실제 옵션이 아닌 옵션도 제시하여 제 이론을 실험하고 검증해 보실 수 있도록 해드립니다. 소스 기반 라우팅이 당신이 해야 할 일입니다.

관련 정보