Olá a todos, meu nome é Sasha, lidero testes de back-end na FunCorp. Nós, como muitos outros, implementamos uma arquitetura orientada a serviços. Por um lado, isso simplifica o trabalho, porque... É mais fácil testar cada serviço separadamente, mas por outro lado, há necessidade de testar a interação dos serviços entre si, o que muitas vezes ocorre na rede.

Neste artigo falarei sobre dois utilitários que podem ser utilizados para verificar cenários básicos que descrevem o funcionamento de uma aplicação na presença de problemas de rede.

Simulando problemas de rede

Normalmente, o software é testado em servidores de teste com uma boa conexão com a Internet. Em ambientes de produção adversos, as coisas podem não ser tão tranquilas, então às vezes você precisa testar programas em condições de conexão ruins. No Linux, o utilitário ajudará na tarefa de simular tais condições tc.

tc(abr. do Controle de Tráfego) permite configurar a transmissão de pacotes de rede no sistema. Este utilitário tem ótimos recursos, você pode ler mais sobre eles aqui. Aqui considerarei apenas alguns deles: estamos interessados ​​na programação de tráfego, para a qual usamos qdisc, e como precisamos emular uma rede instável, usaremos qdisc sem classe netem.

Vamos lançar um servidor de eco no servidor (usei nmap-ncat):

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

Para exibir detalhadamente todos os carimbos de data e hora em cada etapa da interação entre o cliente e o servidor, escrevi um script Python simples que envia uma solicitação Test para o nosso servidor de eco.

Código fonte do cliente

#!/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

Vamos iniciá-lo e observar o tráfego na interface lo e porta 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

Despejo de tráfego

[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

Tudo é padrão: um handshake de três vias, PSH/ACK e ACK em resposta duas vezes - esta é a troca de solicitação e resposta entre o cliente e o servidor, e FIN/ACK e ACK duas vezes - completando a conexão.

Atraso de pacote

Agora vamos definir o atraso para 500 milissegundos:

tc qdisc add dev lo root netem delay 500ms

Iniciamos o cliente e vemos que o script agora é executado por 2 segundos:

[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

O que há no trânsito? Vamos olhar:

Despejo de tráfego

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

Você pode ver que o atraso esperado de meio segundo apareceu na interação entre o cliente e o servidor. O sistema se comporta de maneira muito mais interessante se o atraso for maior: o kernel começa a reenviar alguns pacotes TCP. Vamos mudar o atraso para 1 segundo e olhar o tráfego (não vou mostrar a saída do cliente, são esperados 4 segundos de duração total):

tc qdisc change dev lo root netem delay 1s

Despejo de tráfego

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

Pode-se observar que o cliente enviou um pacote SYN duas vezes e o servidor enviou um SYN/ACK duas vezes.

Além de um valor constante, o atraso pode ser definido como um desvio, uma função de distribuição e uma correlação (com o valor do pacote anterior). Isto se faz do seguinte modo:

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

Aqui definimos o atraso entre 100 e 900 milissegundos, os valores serão selecionados de acordo com uma distribuição normal e haverá uma correlação de 50% com o valor do atraso do pacote anterior.

Você deve ter notado que no primeiro comando que usei adicionare depois alterar. O significado desses comandos é óbvio, então acrescentarei apenas que há mais De, que pode ser usado para remover a configuração.

Perda de Pacote

Vamos agora tentar fazer a perda de pacotes. Como pode ser visto na documentação, isso pode ser feito de três maneiras: perdendo pacotes aleatoriamente com alguma probabilidade, usando uma cadeia de Markov de 2, 3 ou 4 estados para calcular a perda de pacotes, ou usando o modelo de Elliott-Gilbert. No artigo irei considerar o primeiro método (mais simples e óbvio), e você pode ler sobre outros aqui.

Vamos fazer a perda de 50% dos pacotes com correlação de 25%:

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

Infelizmente, tcpdump não será capaz de nos mostrar claramente a perda de pacotes, apenas assumiremos que realmente funciona. E o tempo de execução aumentado e instável do script nos ajudará a verificar isso. cliente.py (pode ser concluído instantaneamente, ou talvez em 20 segundos), bem como um número maior de pacotes retransmitidos:

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

Adicionando ruído aos pacotes

Além da perda de pacotes, você pode simular danos ao pacote: o ruído aparecerá em uma posição aleatória do pacote. Vamos causar danos aos pacotes com 50% de probabilidade e sem correlação:

tc qdisc change dev lo root netem corrupt 50%

Executamos o script do cliente (nada de interessante aí, mas demorou 2 segundos para ser concluído), olhamos o tráfego:

Despejo de tráfego

[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

Pode-se observar que alguns pacotes foram enviados repetidamente e há um pacote com metadados quebrados: opções [nop,unknown-65 0x0a3dcf62eb3d,[opção ruim]>. Mas o principal é que no final tudo funcionou bem - o TCP cumpriu sua tarefa.

Duplicação de pacotes

O que mais você pode fazer com netem? Por exemplo, simule a situação inversa de perda de pacotes – duplicação de pacotes. Este comando também leva 2 argumentos: probabilidade e correlação.

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

Alterando a ordem dos pacotes

Você pode misturar os sacos de duas maneiras.

No primeiro, alguns pacotes são enviados imediatamente, os demais com um atraso especificado. Exemplo da documentação:

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

Com probabilidade de 25% (e correlação de 50%) o pacote será enviado imediatamente, o restante será enviado com atraso de 10 milissegundos.

O segundo método é quando cada enésimo pacote é enviado instantaneamente com uma determinada probabilidade (e correlação) e o restante com um determinado atraso. Exemplo da documentação:

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

Cada quinto pacote tem 25% de chance de ser enviado sem demora.

Alterando a largura de banda

Geralmente em todos os lugares a que se referem TBF, mas com a ajuda netem Você também pode alterar a largura de banda da interface:

tc qdisc change dev lo root netem rate 56kbit

Esta equipe fará caminhadas ao redor localhost tão doloroso quanto navegar na Internet através de um modem dial-up. Além de definir a taxa de bits, você também pode emular o modelo de protocolo da camada de enlace: definir a sobrecarga do pacote, o tamanho da célula e a sobrecarga da célula. Por exemplo, isso pode ser simulado ATM e taxa de bits de 56 kbit/s:

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

Simulando tempo limite de conexão

Outro ponto importante no plano de teste ao aceitar software são os tempos limite. Isso é importante porque em sistemas distribuídos, quando um dos serviços é desabilitado, os demais devem retornar aos demais a tempo ou retornar um erro ao cliente, e em nenhum caso devem simplesmente travar, aguardando uma resposta ou conexão. a ser estabelecido.

Existem várias maneiras de fazer isso: por exemplo, use um mock que não responde ou conecte-se ao processo usando um depurador, coloque um ponto de interrupção no lugar certo e pare o processo (esta é provavelmente a maneira mais pervertida). Mas uma das mais óbvias é o firewall de portas ou hosts. Isso vai nos ajudar com isso iptables.

Para demonstração, usaremos firewall na porta 12345 e executaremos nosso script de cliente. Você pode proteger os pacotes de saída para esta porta no remetente ou os pacotes de entrada no destinatário. Nos meus exemplos, os pacotes recebidos serão protegidos por firewall (usamos chain INPUT e a opção --dport). Tais pacotes podem ser DROP, REJECT ou REJECT com o sinalizador TCP RST, ou com host ICMP inacessível (na verdade, o comportamento padrão é porta icmp inacessível, e também existe a oportunidade de enviar uma resposta icmp-net-inacessível, icmp-proto-inacessível, icmp-net-proibido и icmp-host-proibido).

GOTA

Se houver uma regra com DROP, os pacotes simplesmente “desaparecerão”.

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

Lançamos o cliente e vemos que ele congela na fase de conexão ao servidor. Vejamos o trânsito:
Despejo de tráfego

[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

Pode-se observar que o cliente envia pacotes SYN com um tempo limite crescente exponencialmente. Então encontramos um pequeno bug no cliente: você precisa usar o método settimeout ()para limitar o tempo durante o qual o cliente tentará se conectar ao servidor.

Removemos imediatamente a regra:

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

Você pode excluir todas as regras de uma vez:

iptables -F

Se você estiver usando o Docker e precisar proteger todo o tráfego que vai para o contêiner, poderá fazer isso da seguinte maneira:

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

REJEITAR

Agora vamos adicionar uma regra semelhante, mas com REJECT:

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

O cliente sai após um segundo com um erro [Errno 111] Conexão recusada. Vejamos o tráfego 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

Percebe-se que o cliente recebeu duas vezes porta inacessível e então terminou com um erro.

REJEITAR com tcp-reset

Vamos tentar adicionar a opção --reject-com tcp-reset:

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

Nesse caso, o cliente sai imediatamente com um erro, pois a primeira solicitação recebeu um pacote 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

REJEITAR com icmp-host-inacessível

Vamos tentar outra opção para usar REJECT:

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

O cliente sai após um segundo com um erro [Errno 113] Nenhuma rota para hospedar, vemos no tráfego ICMP Host ICMP 127.0.0.1 inacessível.

Você também pode tentar os outros parâmetros REJECT, e vou me concentrar neles :)

Simulando o tempo limite da solicitação

Outra situação é quando o cliente consegue se conectar ao servidor, mas não consegue enviar uma solicitação a ele. Como filtrar pacotes para que a filtragem não comece imediatamente? Se você observar o tráfego de qualquer comunicação entre o cliente e o servidor, notará que ao estabelecer uma conexão, apenas os flags SYN e ACK são utilizados, mas na troca de dados, o último pacote de solicitação conterá o flag PSH. Ele é instalado automaticamente para evitar buffer. Você pode usar essas informações para criar um filtro: ele permitirá todos os pacotes, exceto aqueles que contêm o sinalizador PSH. Assim, a conexão será estabelecida, mas o cliente não poderá enviar dados ao servidor.

GOTA

Para DROP o comando ficaria assim:

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

Inicie o cliente e observe o tráfego:

Despejo de tráfego

[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

Vemos que a conexão foi estabelecida e o cliente não consegue enviar dados ao servidor.

REJEITAR

Neste caso o comportamento será o mesmo: o cliente não poderá enviar a solicitação, mas receberá ICMP 127.0.0.1 porta tcp 12345 inacessível e aumentar exponencialmente o tempo entre os reenvios de solicitações. O comando fica assim:

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

REJEITAR com tcp-reset

O comando fica assim:

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

Já sabemos que ao usar --reject-com tcp-reset o cliente receberá um pacote RST em resposta, então o comportamento pode ser previsto: receber um pacote RST enquanto a conexão é estabelecida significa que o soquete é fechado inesperadamente do outro lado, o que significa que o cliente deve receber Redefinição de conexão por ponto. Vamos executar nosso script e ter certeza disso. E é assim que o tráfego ficará:

Despejo de tráfego

[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

REJEITAR com icmp-host-inacessível

Acho que já é óbvio para todos como será o comando :) O comportamento do cliente neste caso será um pouco diferente daquele com um simples REJECT: o cliente não aumentará o tempo limite entre as tentativas de reenviar o pacote.

[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

Jogar aviator online grátis: hack aviator funciona

Não é necessário escrever um mock para testar a interação de um serviço com um cliente ou servidor travado; às vezes é suficiente usar utilitários padrão encontrados no Linux.

Os utilitários discutidos no artigo têm ainda mais recursos do que os descritos, portanto, você pode criar algumas de suas próprias opções para usá-los. Pessoalmente, sempre tenho o suficiente do que escrevi (na verdade, menos ainda). Se você usa esses utilitários ou similares em testes em sua empresa, escreva exatamente como. Caso contrário, espero que seu software melhore se você decidir testá-lo em condições de problemas de rede usando os métodos sugeridos.

Fonte: habr.com