안녕하세요 여러분, 제 이름은 Sasha입니다. 저는 FunCorp에서 백엔드 테스트를 이끌고 있습니다. 다른 많은 기업과 마찬가지로 우리도 서비스 지향 아키텍처를 구현했습니다. 한편으로는 작업이 단순화됩니다. 왜냐하면... 각 서비스를 개별적으로 테스트하는 것이 더 쉽지만, 반면 네트워크를 통해 자주 발생하는 서비스 간 상호 작용을 테스트할 필요가 있습니다.

이 기사에서는 네트워크 문제가 있는 경우 애플리케이션의 작동을 설명하는 기본 시나리오를 확인하는 데 사용할 수 있는 두 가지 유틸리티에 대해 설명합니다.

네트워크 문제 시뮬레이션

일반적으로 소프트웨어는 인터넷 연결이 양호한 테스트 서버에서 테스트됩니다. 열악한 제작 환경에서는 일이 순조롭게 진행되지 않을 수 있으므로 연결 상태가 좋지 않은 상태에서 프로그램을 테스트해야 하는 경우도 있습니다. Linux에서 이 유틸리티는 이러한 조건을 시뮬레이션하는 작업에 도움이 됩니다. tc.

티씨(약어 교통 통제에서)을 사용하면 시스템에서 네트워크 패킷 전송을 구성할 수 있습니다. 이 유틸리티에는 뛰어난 기능이 있습니다. 이에 대한 자세한 내용을 읽을 수 있습니다. 여기에. 여기서는 그 중 몇 가지만 고려할 것입니다. 우리는 트래픽 스케줄링에 관심이 있습니다. qdisc, 불안정한 네트워크를 에뮬레이트해야 하므로 클래스 없는 qdisc를 사용하겠습니다. 네템.

서버에서 에코 서버를 실행해 보겠습니다. nmap-ncat):

ncat -l 127.0.0.1 12345 -k -c 'xargs -n1 -i echo "Response: {}"'

클라이언트와 서버 간 상호 작용의 각 단계에서 모든 타임스탬프를 자세히 표시하기 위해 요청을 보내는 간단한 Python 스크립트를 작성했습니다. Test 우리 에코 서버에.

클라이언트 소스 코드

#!/bin/python

import socket
import time

HOST = '127.0.0.1'
PORT = 12345
BUFFER_SIZE = 1024
MESSAGE = "Testn"

s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
t1 = time.time()
print "[time before connection: %.5f]" % t1
s.connect((HOST, PORT))
print "[time after connection, before sending: %.5f]" % time.time()
s.send(MESSAGE)
print "[time after sending, before receiving: %.5f]" % time.time()
data = s.recv(BUFFER_SIZE)
print "[time after receiving, before closing: %.5f]" % time.time()
s.close()
t2 = time.time()
print "[time after closing: %.5f]" % t2
print "[total duration: %.5f]" % (t2 - t1)

print data

이를 실행하고 인터페이스의 트래픽을 살펴보겠습니다. lo 포트 12345:

[user@host ~]# python client.py
[time before connection: 1578652979.44837]
[time after connection, before sending: 1578652979.44889]
[time after sending, before receiving: 1578652979.44894]
[time after receiving, before closing: 1578652979.45922]
[time after closing: 1578652979.45928]
[total duration: 0.01091]
Response: Test

트래픽 덤프

[user@host ~]# tcpdump -i lo -nn port 12345
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on lo, link-type EN10MB (Ethernet), capture size 262144 bytes
10:42:59.448601 IP 127.0.0.1.54054 > 127.0.0.1.12345: Flags [S], seq 3383332866, win 43690, options [mss 65495,sackOK,TS val 606325685 ecr 0,nop,wscale 7], length 0
10:42:59.448612 IP 127.0.0.1.12345 > 127.0.0.1.54054: Flags [S.], seq 2584700178, ack 3383332867, win 43690, options [mss 65495,sackOK,TS val 606325685 ecr 606325685,nop,wscale 7], length 0
10:42:59.448622 IP 127.0.0.1.54054 > 127.0.0.1.12345: Flags [.], ack 1, win 342, options [nop,nop,TS val 606325685 ecr 606325685], length 0
10:42:59.448923 IP 127.0.0.1.54054 > 127.0.0.1.12345: Flags [P.], seq 1:6, ack 1, win 342, options [nop,nop,TS val 606325685 ecr 606325685], length 5
10:42:59.448930 IP 127.0.0.1.12345 > 127.0.0.1.54054: Flags [.], ack 6, win 342, options [nop,nop,TS val 606325685 ecr 606325685], length 0
10:42:59.459118 IP 127.0.0.1.12345 > 127.0.0.1.54054: Flags [P.], seq 1:15, ack 6, win 342, options [nop,nop,TS val 606325696 ecr 606325685], length 14
10:42:59.459213 IP 127.0.0.1.54054 > 127.0.0.1.12345: Flags [.], ack 15, win 342, options [nop,nop,TS val 606325696 ecr 606325696], length 0
10:42:59.459268 IP 127.0.0.1.54054 > 127.0.0.1.12345: Flags [F.], seq 6, ack 15, win 342, options [nop,nop,TS val 606325696 ecr 606325696], length 0
10:42:59.460184 IP 127.0.0.1.12345 > 127.0.0.1.54054: Flags [F.], seq 15, ack 7, win 342, options [nop,nop,TS val 606325697 ecr 606325696], length 0
10:42:59.460196 IP 127.0.0.1.54054 > 127.0.0.1.12345: Flags [.], ack 16, win 342, options [nop,nop,TS val 606325697 ecr 606325697], length 0

모든 것이 표준입니다. XNUMX방향 핸드셰이크, 두 번 응답하는 PSH/ACK 및 ACK(클라이언트와 서버 간의 요청 및 응답 교환, FIN/ACK 및 ACK 두 번)로 연결이 완료됩니다.

패킷 지연

이제 지연을 500밀리초로 설정해 보겠습니다.

tc qdisc add dev lo root netem delay 500ms

클라이언트를 시작하고 이제 스크립트가 2초 동안 실행되는 것을 확인합니다.

[user@host ~]# ./client.py
[time before connection: 1578662612.71044]
[time after connection, before sending: 1578662613.71059]
[time after sending, before receiving: 1578662613.71065]
[time after receiving, before closing: 1578662614.72011]
[time after closing: 1578662614.72019]
[total duration: 2.00974]
Response: Test

교통 정체는 무엇입니까? 한번 보자:

트래픽 덤프

13:23:33.210520 IP 127.0.0.1.58694 > 127.0.0.1.12345: Flags [S], seq 1720950927, win 43690, options [mss 65495,sackOK,TS val 615958947 ecr 0,nop,wscale 7], length 0
13:23:33.710554 IP 127.0.0.1.12345 > 127.0.0.1.58694: Flags [S.], seq 1801168125, ack 1720950928, win 43690, options [mss 65495,sackOK,TS val 615959447 ecr 615958947,nop,wscale 7], length 0
13:23:34.210590 IP 127.0.0.1.58694 > 127.0.0.1.12345: Flags [.], ack 1, win 342, options [nop,nop,TS val 615959947 ecr 615959447], length 0
13:23:34.210657 IP 127.0.0.1.58694 > 127.0.0.1.12345: Flags [P.], seq 1:6, ack 1, win 342, options [nop,nop,TS val 615959947 ecr 615959447], length 5
13:23:34.710680 IP 127.0.0.1.12345 > 127.0.0.1.58694: Flags [.], ack 6, win 342, options [nop,nop,TS val 615960447 ecr 615959947], length 0
13:23:34.719371 IP 127.0.0.1.12345 > 127.0.0.1.58694: Flags [P.], seq 1:15, ack 6, win 342, options [nop,nop,TS val 615960456 ecr 615959947], length 14
13:23:35.220106 IP 127.0.0.1.58694 > 127.0.0.1.12345: Flags [.], ack 15, win 342, options [nop,nop,TS val 615960957 ecr 615960456], length 0
13:23:35.220188 IP 127.0.0.1.58694 > 127.0.0.1.12345: Flags [F.], seq 6, ack 15, win 342, options [nop,nop,TS val 615960957 ecr 615960456], length 0
13:23:35.720994 IP 127.0.0.1.12345 > 127.0.0.1.58694: Flags [F.], seq 15, ack 7, win 342, options [nop,nop,TS val 615961457 ecr 615960957], length 0
13:23:36.221025 IP 127.0.0.1.58694 > 127.0.0.1.12345: Flags [.], ack 16, win 342, options [nop,nop,TS val 615961957 ecr 615961457], length 0

클라이언트와 서버 간의 상호 작용에서 예상되는 1초의 지연이 나타나는 것을 확인할 수 있습니다. 지연이 클수록 시스템은 훨씬 더 흥미롭게 작동합니다. 즉, 커널이 일부 TCP 패킷을 다시 보내기 시작합니다. 지연 시간을 4초로 변경하고 트래픽을 살펴보겠습니다(클라이언트의 출력은 표시하지 않으며 예상되는 총 지속 시간은 XNUMX초입니다).

tc qdisc change dev lo root netem delay 1s

트래픽 덤프

13:29:07.709981 IP 127.0.0.1.39306 > 127.0.0.1.12345: Flags [S], seq 283338334, win 43690, options [mss 65495,sackOK,TS val 616292946 ecr 0,nop,wscale 7], length 0
13:29:08.710018 IP 127.0.0.1.12345 > 127.0.0.1.39306: Flags [S.], seq 3514208179, ack 283338335, win 43690, options [mss 65495,sackOK,TS val 616293946 ecr 616292946,nop,wscale 7], length 0
13:29:08.711094 IP 127.0.0.1.39306 > 127.0.0.1.12345: Flags [S], seq 283338334, win 43690, options [mss 65495,sackOK,TS val 616293948 ecr 0,nop,wscale 7], length 0
13:29:09.710048 IP 127.0.0.1.39306 > 127.0.0.1.12345: Flags [.], ack 1, win 342, options [nop,nop,TS val 616294946 ecr 616293946], length 0
13:29:09.710152 IP 127.0.0.1.39306 > 127.0.0.1.12345: Flags [P.], seq 1:6, ack 1, win 342, options [nop,nop,TS val 616294947 ecr 616293946], length 5
13:29:09.711120 IP 127.0.0.1.12345 > 127.0.0.1.39306: Flags [S.], seq 3514208179, ack 283338335, win 43690, options [mss 65495,sackOK,TS val 616294948 ecr 616292946,nop,wscale 7], length 0
13:29:10.710173 IP 127.0.0.1.12345 > 127.0.0.1.39306: Flags [.], ack 6, win 342, options [nop,nop,TS val 616295947 ecr 616294947], length 0
13:29:10.711140 IP 127.0.0.1.39306 > 127.0.0.1.12345: Flags [.], ack 1, win 342, options [nop,nop,TS val 616295948 ecr 616293946], length 0
13:29:10.714782 IP 127.0.0.1.12345 > 127.0.0.1.39306: Flags [P.], seq 1:15, ack 6, win 342, options [nop,nop,TS val 616295951 ecr 616294947], length 14
13:29:11.714819 IP 127.0.0.1.39306 > 127.0.0.1.12345: Flags [.], ack 15, win 342, options [nop,nop,TS val 616296951 ecr 616295951], length 0
13:29:11.714893 IP 127.0.0.1.39306 > 127.0.0.1.12345: Flags [F.], seq 6, ack 15, win 342, options [nop,nop,TS val 616296951 ecr 616295951], length 0
13:29:12.715562 IP 127.0.0.1.12345 > 127.0.0.1.39306: Flags [F.], seq 15, ack 7, win 342, options [nop,nop,TS val 616297952 ecr 616296951], length 0
13:29:13.715596 IP 127.0.0.1.39306 > 127.0.0.1.12345: Flags [.], ack 16, win 342, options [nop,nop,TS val 616298952 ecr 616297952], length 0

클라이언트가 SYN 패킷을 두 번 보냈고, 서버가 SYN/ACK를 두 번 보낸 것을 볼 수 있습니다.

지연 시간은 상수 값 외에도 편차, 분포 함수, 상관 관계(이전 패킷 값과의 관계)로 설정할 수 있습니다. 이는 다음과 같이 수행됩니다.

tc qdisc change dev lo root netem delay 500ms 400ms 50 distribution normal

여기서는 100~900밀리초 사이의 지연을 설정했으며 값은 정규 분포에 따라 선택되며 이전 패킷의 지연 값과 50% 상관 관계가 있습니다.

내가 사용한 첫 번째 명령에서 눈치챘을 수도 있습니다. 더하다그런 다음 이전 단계로 돌아가기. 이 명령의 의미는 분명하므로 더 많은 것이 있다는 점만 추가하겠습니다. 델, 구성을 제거하는 데 사용할 수 있습니다.

패킷 손실

이제 패킷 손실을 시도해 보겠습니다. 문서에서 볼 수 있듯이 이는 세 가지 방법으로 수행될 수 있습니다. 일정 확률로 무작위로 패킷을 잃거나, 2, 3 또는 4 상태의 Markov 체인을 사용하여 패킷 손실을 계산하거나 Elliott-Gilbert 모델을 사용하는 것입니다. 이 기사에서는 첫 번째(가장 간단하고 가장 분명한) 방법을 고려할 것이며 다른 방법에 대해서도 읽을 수 있습니다. 여기에.

상관관계가 50%인 패킷의 25%가 손실된다고 가정해 보겠습니다.

tc qdisc add dev lo root netem loss 50% 25%

불행하게도, TCP 덤프 패킷 손실을 명확하게 보여줄 수 없으며 실제로 작동한다고 가정할 뿐입니다. 그리고 스크립트의 증가되고 불안정한 실행 시간은 이를 확인하는 데 도움이 될 것입니다. client.py (즉시 또는 20초 내에 완료될 수 있음) 재전송되는 패킷 수가 증가합니다.

[user@host ~]# netstat -s | grep retransmited; sleep 10; netstat -s | grep retransmited
    17147 segments retransmited
    17185 segments retransmited

패킷에 노이즈 추가

패킷 손실 외에도 패킷 손상을 시뮬레이션할 수 있습니다. 즉, 무작위 패킷 위치에 노이즈가 나타납니다. 상관관계 없이 50% 확률로 패킷 손상을 만들어 보겠습니다.

tc qdisc change dev lo root netem corrupt 50%

클라이언트 스크립트를 실행하고(흥미로운 것은 없지만 완료하는 데 2초가 걸렸습니다) 트래픽을 살펴봅니다.

트래픽 덤프

[user@host ~]# tcpdump -i lo -nn port 12345
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on lo, link-type EN10MB (Ethernet), capture size 262144 bytes
10:20:54.812434 IP 127.0.0.1.43666 > 127.0.0.1.12345: Flags [S], seq 2023663770, win 43690, options [mss 65495,sackOK,TS val 1037001049 ecr 0,nop,wscale 7], length 0
10:20:54.812449 IP 127.0.0.1.12345 > 127.0.0.1.43666: Flags [S.], seq 2104268044, ack 2023663771, win 43690, options [mss 65495,sackOK,TS val 1037001049 ecr 1037001049,nop,wscale 7], length 0
10:20:54.812458 IP 127.0.0.1.43666 > 127.0.0.1.12345: Flags [.], ack 1, win 342, options [nop,nop,TS val 1037001049 ecr 1037001049], length 0
10:20:54.812509 IP 127.0.0.1.43666 > 127.0.0.1.12345: Flags [P.], seq 1:6, ack 1, win 342, options [nop,nop,TS val 1037001049 ecr 1037001049], length 5
10:20:55.013093 IP 127.0.0.1.43666 > 127.0.0.1.12345: Flags [P.], seq 1:6, ack 1, win 342, options [nop,nop,TS val 1037001250 ecr 1037001049], length 5
10:20:55.013122 IP 127.0.0.1.12345 > 127.0.0.1.43666: Flags [.], ack 6, win 342, options [nop,nop,TS val 1037001250 ecr 1037001250], length 0
10:20:55.014681 IP 127.0.0.1.12345 > 127.0.0.1.43666: Flags [P.], seq 1:15, ack 6, win 342, options [nop,nop,TS val 1037001251 ecr 1037001250], length 14
10:20:55.014745 IP 127.0.0.1.43666 > 127.0.0.1.12345: Flags [.], ack 15, win 340, options [nop,nop,TS val 1037001251 ecr 1037001251], length 0
10:20:55.014823 IP 127.0.0.1.43666 > 127.0.0.5.12345: Flags [F.], seq 2023663776, ack 2104268059, win 342, options [nop,nop,TS val 1037001251 ecr 1037001251], length 0
10:20:55.214088 IP 127.0.0.1.12345 > 127.0.0.1.43666: Flags [P.], seq 1:15, ack 6, win 342, options [nop,unknown-65 0x0a3dcf62eb3d,[bad opt]>
10:20:55.416087 IP 127.0.0.1.43666 > 127.0.0.1.12345: Flags [F.], seq 6, ack 15, win 342, options [nop,nop,TS val 1037001653 ecr 1037001251], length 0
10:20:55.416804 IP 127.0.0.1.12345 > 127.0.0.1.43666: Flags [F.], seq 15, ack 7, win 342, options [nop,nop,TS val 1037001653 ecr 1037001653], length 0
10:20:55.416818 IP 127.0.0.1.43666 > 127.0.0.1.12345: Flags [.], ack 16, win 343, options [nop,nop,TS val 1037001653 ecr 1037001653], length 0
10:20:56.147086 IP 127.0.0.1.12345 > 127.0.0.1.43666: Flags [F.], seq 15, ack 7, win 342, options [nop,nop,TS val 1037002384 ecr 1037001653], length 0
10:20:56.147101 IP 127.0.0.1.43666 > 127.0.0.1.12345: Flags [.], ack 16, win 342, options [nop,nop,TS val 1037002384 ecr 1037001653], length 0

일부 패킷이 반복적으로 전송되었으며 메타데이터가 손상된 패킷이 하나 있음을 알 수 있습니다. 옵션 [nop,unknown-65 0x0a3dcf62eb3d,[잘못된 선택]>. 그러나 가장 중요한 것은 결국 모든 것이 올바르게 작동했다는 것입니다. TCP가 작업에 대처했습니다.

패킷 복제

또 무엇을 할 수 있나요? 네템? 예를 들어, 패킷 손실의 반대 상황인 패킷 복제를 시뮬레이션합니다. 이 명령에는 확률과 상관관계라는 두 가지 인수도 사용됩니다.

tc qdisc change dev lo root netem duplicate 50% 25%

패키지 순서 변경

두 가지 방법으로 가방을 섞을 수 있습니다.

첫 번째에서는 일부 패킷이 즉시 전송되고 나머지는 지정된 지연을 거쳐 전송됩니다. 문서의 예:

tc qdisc change dev lo root netem delay 10ms reorder 25% 50%

확률이 25%(상관관계 50%)이면 패킷이 즉시 전송되고 나머지는 10밀리초 지연된 후 전송됩니다.

두 번째 방법은 모든 N번째 패킷이 주어진 확률(및 상관 관계)로 즉시 전송되고 나머지는 지정된 지연으로 전송되는 것입니다. 문서의 예:

tc qdisc change dev lo root netem delay 10ms reorder 25% 50% gap 5

다섯 번째 패키지마다 지체 없이 배송될 확률은 25%입니다.

대역폭 변경

일반적으로 어디에서나 언급되는 TBF, 하지만 도움을 받아 네템 인터페이스 대역폭을 변경할 수도 있습니다.

tc qdisc change dev lo root netem rate 56kbit

이 팀은 주변을 트레킹할 것입니다. 로컬 호스트 전화 접속 모뎀을 통해 인터넷 서핑을 하는 것만큼 고통스럽습니다. 비트 전송률 설정 외에도 링크 계층 프로토콜 모델을 에뮬레이션할 수도 있습니다. 즉, 패킷에 대한 오버헤드, 셀 크기 및 셀에 대한 오버헤드를 설정할 수 있습니다. 예를 들어, 다음과 같이 시뮬레이션할 수 있습니다. ATM 비트 전송률 56kbit/초:

tc qdisc change dev lo root netem rate 56kbit 0 48 5

연결 시간 초과 시뮬레이션

소프트웨어를 승인할 때 테스트 계획의 또 다른 중요한 점은 시간 초과입니다. 이는 분산 시스템에서 서비스 중 하나가 비활성화되면 다른 서비스가 제 시간에 다른 서비스로 돌아가거나 클라이언트에 오류를 반환해야 하며 어떤 경우에도 단순히 응답이나 연결을 기다리면서 응답을 기다리기 때문에 중요합니다. 설립될 예정이다.

이를 수행하는 방법에는 여러 가지가 있습니다. 예를 들어 응답하지 않는 모의 개체를 사용하거나 디버거를 사용하여 프로세스에 연결하고, 올바른 위치에 중단점을 놓고 프로세스를 중지하는 것입니다(아마도 가장 왜곡된 방법일 것입니다). 그러나 가장 확실한 것 중 하나는 방화벽 포트나 호스트입니다. 이것은 우리에게 도움이 될 것입니다 iptables에.

데모를 위해 포트 12345를 방화벽으로 설정하고 클라이언트 스크립트를 실행하겠습니다. 발신자 측에서 이 포트로 나가는 패킷을 차단하거나 수신자 측에서 들어오는 패킷을 방화벽으로 차단할 수 있습니다. 내 예에서는 들어오는 패킷이 방화벽으로 보호됩니다(체인 INPUT을 사용하고 옵션을 사용함). --dport). 이러한 패킷은 TCP 플래그 RST를 사용하여 DROP, REJECT 또는 REJECT이거나 ICMP 호스트에 연결할 수 없는 경우일 수 있습니다(실제로 기본 동작은 다음과 같습니다). ICMP 포트에 연결할 수 없음, 답장을 보낼 기회도 있습니다 ICMP-NET-접근불가, icmp-proto-접근 불가, ICMP-NET 금지 и ICMP 호스트 금지).

DROP

DROP 규칙이 있으면 패킷은 단순히 "사라집니다".

iptables -A INPUT -p tcp --dport 12345 -j DROP

클라이언트를 실행하고 서버에 연결하는 단계에서 클라이언트가 정지되는 것을 확인합니다. 교통 상황을 살펴보겠습니다.
트래픽 덤프

[user@host ~]# tcpdump -i lo -nn port 12345
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on lo, link-type EN10MB (Ethernet), capture size 262144 bytes
08:28:20.213506 IP 127.0.0.1.32856 > 127.0.0.1.12345: Flags [S], seq 3019694933, win 43690, options [mss 65495,sackOK,TS val 1203046450 ecr 0,nop,wscale 7], length 0
08:28:21.215086 IP 127.0.0.1.32856 > 127.0.0.1.12345: Flags [S], seq 3019694933, win 43690, options [mss 65495,sackOK,TS val 1203047452 ecr 0,nop,wscale 7], length 0
08:28:23.219092 IP 127.0.0.1.32856 > 127.0.0.1.12345: Flags [S], seq 3019694933, win 43690, options [mss 65495,sackOK,TS val 1203049456 ecr 0,nop,wscale 7], length 0
08:28:27.227087 IP 127.0.0.1.32856 > 127.0.0.1.12345: Flags [S], seq 3019694933, win 43690, options [mss 65495,sackOK,TS val 1203053464 ecr 0,nop,wscale 7], length 0
08:28:35.235102 IP 127.0.0.1.32856 > 127.0.0.1.12345: Flags [S], seq 3019694933, win 43690, options [mss 65495,sackOK,TS val 1203061472 ecr 0,nop,wscale 7], length 0

클라이언트가 기하급수적으로 증가하는 시간 제한으로 SYN 패킷을 보내는 것을 볼 수 있습니다. 그래서 우리는 클라이언트에서 작은 버그를 발견했습니다: 당신은 메소드를 사용해야 합니다 설정 시간 초과()클라이언트가 서버에 연결을 시도하는 시간을 제한합니다.

규칙을 즉시 제거합니다.

iptables -D INPUT -p tcp --dport 12345 -j DROP

모든 규칙을 한 번에 삭제할 수 있습니다.

iptables -F

Docker를 사용하고 있고 컨테이너로 이동하는 모든 트래픽을 방화벽으로 설정해야 하는 경우 다음과 같이 수행할 수 있습니다.

iptables -I DOCKER-USER -p tcp -d CONTAINER_IP -j DROP

받지 않다

이제 REJECT를 사용하여 비슷한 규칙을 추가해 보겠습니다.

iptables -A INPUT -p tcp --dport 12345 -j REJECT

클라이언트가 오류와 함께 XNUMX초 후에 종료됩니다. [Errno 111] 연결이 거부되었습니다.. ICMP 트래픽을 살펴보겠습니다.

[user@host ~]# tcpdump -i lo -nn icmp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on lo, link-type EN10MB (Ethernet), capture size 262144 bytes
08:45:32.871414 IP 127.0.0.1 > 127.0.0.1: ICMP 127.0.0.1 tcp port 12345 unreachable, length 68
08:45:33.873097 IP 127.0.0.1 > 127.0.0.1: ICMP 127.0.0.1 tcp port 12345 unreachable, length 68

클라이언트가 두 번 수신한 것을 볼 수 있습니다. 포트에 연결할 수 없음 그리고 오류로 끝났습니다.

tcp-reset으로 거부

옵션을 추가해 보도록 하겠습니다 --tcp-reset으로 거부:

iptables -A INPUT -p tcp --dport 12345 -j REJECT --reject-with tcp-reset

이 경우 첫 번째 요청이 RST 패킷을 수신했기 때문에 클라이언트는 오류와 함께 즉시 종료됩니다.

[user@host ~]# tcpdump -i lo -nn port 12345
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on lo, link-type EN10MB (Ethernet), capture size 262144 bytes
09:02:52.766175 IP 127.0.0.1.60658 > 127.0.0.1.12345: Flags [S], seq 1889460883, win 43690, options [mss 65495,sackOK,TS val 1205119003 ecr 0,nop,wscale 7], length 0
09:02:52.766184 IP 127.0.0.1.12345 > 127.0.0.1.60658: Flags [R.], seq 0, ack 1889460884, win 0, length 0

icmp-host-unreachable로 거부

REJECT를 사용하는 다른 옵션을 시도해 보겠습니다.

iptables -A INPUT -p tcp --dport 12345 -j REJECT --reject-with icmp-host-unreachable

클라이언트가 오류와 함께 XNUMX초 후에 종료됩니다. [Errno 113] 호스트 경로가 없습니다., ICMP 트래픽에서 확인 가능 ICMP 호스트 127.0.0.1에 연결할 수 없습니다..

다른 REJECT 매개변수를 사용해 볼 수도 있습니다. 저는 이것에 중점을 두겠습니다. :)

요청 시간 초과 시뮬레이션

또 다른 상황은 클라이언트가 서버에 연결할 수 있었지만 서버에 요청을 보낼 수 없는 경우입니다. 필터링이 즉시 시작되지 않도록 패킷을 필터링하는 방법은 무엇입니까? 클라이언트와 서버 간의 통신 트래픽을 살펴보면 연결을 설정할 때 SYN 및 ACK 플래그만 사용되지만 데이터를 교환할 때는 마지막 요청 패킷에 PSH 플래그가 포함된다는 것을 알 수 있습니다. 버퍼링을 방지하기 위해 자동으로 설치됩니다. 이 정보를 사용하여 필터를 만들 수 있습니다. 필터는 PSH 플래그가 포함된 패킷을 제외한 모든 패킷을 허용합니다. 따라서 연결은 설정되지만 클라이언트는 서버에 데이터를 보낼 수 없습니다.

DROP

DROP의 경우 명령은 다음과 같습니다.

iptables -A INPUT -p tcp --tcp-flags PSH PSH --dport 12345 -j DROP

클라이언트를 시작하고 트래픽을 관찰합니다.

트래픽 덤프

[user@host ~]# tcpdump -i lo -nn port 12345
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on lo, link-type EN10MB (Ethernet), capture size 262144 bytes
10:02:47.549498 IP 127.0.0.1.49594 > 127.0.0.1.12345: Flags [S], seq 2166014137, win 43690, options [mss 65495,sackOK,TS val 1208713786 ecr 0,nop,wscale 7], length 0
10:02:47.549510 IP 127.0.0.1.12345 > 127.0.0.1.49594: Flags [S.], seq 2341799088, ack 2166014138, win 43690, options [mss 65495,sackOK,TS val 1208713786 ecr 1208713786,nop,wscale 7], length 0
10:02:47.549520 IP 127.0.0.1.49594 > 127.0.0.1.12345: Flags [.], ack 1, win 342, options [nop,nop,TS val 1208713786 ecr 1208713786], length 0
10:02:47.549568 IP 127.0.0.1.49594 > 127.0.0.1.12345: Flags [P.], seq 1:6, ack 1, win 342, options [nop,nop,TS val 1208713786 ecr 1208713786], length 5
10:02:47.750084 IP 127.0.0.1.49594 > 127.0.0.1.12345: Flags [P.], seq 1:6, ack 1, win 342, options [nop,nop,TS val 1208713987 ecr 1208713786], length 5
10:02:47.951088 IP 127.0.0.1.49594 > 127.0.0.1.12345: Flags [P.], seq 1:6, ack 1, win 342, options [nop,nop,TS val 1208714188 ecr 1208713786], length 5
10:02:48.354089 IP 127.0.0.1.49594 > 127.0.0.1.12345: Flags [P.], seq 1:6, ack 1, win 342, options [nop,nop,TS val 1208714591 ecr 1208713786], length 5

연결이 설정되었지만 클라이언트가 서버로 데이터를 보낼 수 없음을 알 수 있습니다.

받지 않다

이 경우 동작은 동일합니다. 클라이언트는 요청을 보낼 수 없지만 수신하게 됩니다. ICMP 127.0.0.1 tcp 포트 12345에 연결할 수 없습니다. 요청 재제출 사이의 시간이 기하급수적으로 늘어납니다. 명령은 다음과 같습니다.

iptables -A INPUT -p tcp --tcp-flags PSH PSH --dport 12345 -j REJECT

tcp-reset으로 거부

명령은 다음과 같습니다.

iptables -A INPUT -p tcp --tcp-flags PSH PSH --dport 12345 -j REJECT --reject-with tcp-reset

우리는 이미 그것을 사용할 때 그것을 알고 있습니다. --tcp-reset으로 거부 클라이언트는 응답으로 RST 패킷을 수신하므로 동작을 예측할 수 있습니다. 연결이 설정되는 동안 RST 패킷을 수신한다는 것은 소켓이 반대편에서 예기치 않게 닫혔다는 것을 의미합니다. 피어에 의한 연결 재설정. 스크립트를 실행하고 이를 확인해 보겠습니다. 트래픽은 다음과 같습니다.

트래픽 덤프

[user@host ~]# tcpdump -i lo -nn port 12345
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on lo, link-type EN10MB (Ethernet), capture size 262144 bytes
10:22:14.186269 IP 127.0.0.1.52536 > 127.0.0.1.12345: Flags [S], seq 2615137531, win 43690, options [mss 65495,sackOK,TS val 1209880423 ecr 0,nop,wscale 7], length 0
10:22:14.186284 IP 127.0.0.1.12345 > 127.0.0.1.52536: Flags [S.], seq 3999904809, ack 2615137532, win 43690, options [mss 65495,sackOK,TS val 1209880423 ecr 1209880423,nop,wscale 7], length 0
10:22:14.186293 IP 127.0.0.1.52536 > 127.0.0.1.12345: Flags [.], ack 1, win 342, options [nop,nop,TS val 1209880423 ecr 1209880423], length 0
10:22:14.186338 IP 127.0.0.1.52536 > 127.0.0.1.12345: Flags [P.], seq 1:6, ack 1, win 342, options [nop,nop,TS val 1209880423 ecr 1209880423], length 5
10:22:14.186344 IP 127.0.0.1.12345 > 127.0.0.1.52536: Flags [R], seq 3999904810, win 0, length 0

icmp-host-unreachable로 거부

명령이 어떻게 보일지는 모든 사람에게 이미 분명하다고 생각합니다. :) 이 경우 클라이언트의 동작은 간단한 REJECT의 동작과 약간 다를 것입니다. 클라이언트는 패킷 재전송 시도 사이의 시간 제한을 늘리지 않습니다.

[user@host ~]# tcpdump -i lo -nn icmp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on lo, link-type EN10MB (Ethernet), capture size 262144 bytes
10:29:56.149202 IP 127.0.0.1 > 127.0.0.1: ICMP host 127.0.0.1 unreachable, length 65
10:29:56.349107 IP 127.0.0.1 > 127.0.0.1: ICMP host 127.0.0.1 unreachable, length 65
10:29:56.549117 IP 127.0.0.1 > 127.0.0.1: ICMP host 127.0.0.1 unreachable, length 65
10:29:56.750125 IP 127.0.0.1 > 127.0.0.1: ICMP host 127.0.0.1 unreachable, length 65
10:29:56.951130 IP 127.0.0.1 > 127.0.0.1: ICMP host 127.0.0.1 unreachable, length 65
10:29:57.152107 IP 127.0.0.1 > 127.0.0.1: ICMP host 127.0.0.1 unreachable, length 65
10:29:57.353115 IP 127.0.0.1 > 127.0.0.1: ICMP host 127.0.0.1 unreachable, length 65

출력

중단된 클라이언트 또는 서버와 서비스의 상호 작용을 테스트하기 위해 모의 코드를 작성할 필요는 없으며 때로는 Linux에 있는 표준 유틸리티를 사용하는 것만으로도 충분합니다.

이 기사에서 설명하는 유틸리티에는 설명된 것보다 훨씬 더 많은 기능이 있으므로 이를 사용하기 위한 몇 가지 옵션을 직접 생각해 볼 수 있습니다. 개인적으로 나는 항상 내가 쓴 내용을 충분히 가지고 있습니다 (사실 더 적습니다). 회사에서 테스트할 때 이러한 유틸리티나 유사한 유틸리티를 사용하는 경우 정확한 방법을 적어주세요. 그렇지 않다면 제안된 방법을 사용하여 네트워크 문제에 직면하여 소프트웨어를 테스트하기로 결정하면 소프트웨어 품질이 더 좋아지기를 바랍니다.

출처 : habr.com