servidor responde aos pacotes TCP SYN com atraso

7

Eu tenho a seguinte topologia de rede:

Quando a estação de trabalho conecta-se ao servidor HTTPS no servidor , geralmente o servidor envia o pacote SYN + ACK com atraso de ~ 60 segundos. A captura de pacotes do servidor pode ser vista abaixo:

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>

Para excluir qualquer problema relacionado ao ARP, instalei a entrada ARP estática para estação de trabalho no servidor :

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

Por último, mas não menos importante, posso pingar 10.10.10.160 a partir de 10.10.10.16 em todos os momentos. Por exemplo, eu tive while :; do ping -c 1 -I 10.10.10.16 10.10.10.160 &>/dev/null || date; sleep 2; done em execução no servidor o dia todo e nem um único ping falhou.

Finalmente, quando eu comparo o pacote TCP SYN enviado pelo cliente em 10:15:51.806784 (não recebe SYN + ACK do servidor ) com 10:16:24.062769 (recebe SYN + ACK do servidor ) no Wireshark, que não são checksums, são idênticos.

Além disso, o firewall do lado servidor é configurado de forma que a primeira regra da cadeia INPUT é registrar pacotes TCP SYN a partir de 10.10.10.160 ( iptables -I INPUT -s 10.10.10.160 -d 10.10.10.16 -p tcp --syn --dport 443 -j LOG ) e A segunda regra é aceitar todo o tráfego de 10.10.10.160. Por exemplo, as seguintes linhas são registradas no buffer de anel do kernel:

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

Como eu já disse, eles são aceitos na próxima regra. Isso deve excluir qualquer problema relacionado a tc / netfilter .

Outros clientes (por exemplo, 10.10.10.170) funcionam bem.

O que poderia causar tal comportamento?

    
por Martin 04.10.2017 / 15:31

1 resposta

4

Eu vejo um grande problema aqui: as respostas do seu servidor não passam pelo mesmo caminho que os pacotes que vão para ele.

Sua estação de trabalho está usando seu roteador 10.10.10.190 para alcançar o servidor através de seu endereço 10.10.10.16/32 (/ 32? seu desenho também diz / 28) em vez de usar seu endereço 10.10.10.148 que está no mesmo segmento da LAN como o WS.

No entanto, os pacotes TCP que vão do servidor para o WS não usam o roteador, pois o servidor pode atingir o WS diretamente.

Por que isso importa?

A conseqüência é que seu roteador não vê as respostas do seu servidor e tem uma idéia errada do estado da conexão (apesar do servidor ter respondido com um SYN + ACK, do ponto de vista do roteador o estado da conexão ainda é inicial SYN).

Como a maioria dos roteadores de hoje, ele provavelmente bloqueia qualquer pacote TCP subseqüente que vai do WS para o servidor até ver o SYN + ACK do servidor (isso não acontecerá).

Assim, seu problema real provavelmente não é que seu servidor espere 60 segundos antes de enviar o SYN + ACK, mas que seu roteador bloqueie o tráfego TCP de seu WS para o servidor após o SYN inicial.

Por que esse despejo de tráfego, então?

Se minha teoria estiver correta, o tráfego que você postou na sua pergunta está enganando porque não temos o despejo completo:

  • o servidor não responde aos pedidos de SYN porque já respondeu ao primeiro e estes são considerados como duplicados
  • o que você vê em 10: 16: 24.062769 e em 10: 16: 24.062860 é provavelmente o servidor enviando sua resposta SYN + ACK novamente após um certo atraso sem receber nada do WS

Como consertar isso?

Você tem várias opções:

  • Alcance o servidor diretamente através de seu endereço IP 10.10.10.148 (não é uma correção, na verdade)
  • Remova o endereço IP 10.10.10.148 do servidor (não é uma opção, eu acho)
  • Desabilite o rastreamento de conexão do firewall no roteador (não é uma opção, eu acho, e não é desejável de qualquer maneira)
  • Ponha o endereço MAC do roteador 00: 19: e2: 9e: df: f0 na tabela ARP do servidor para 10.10.10.160 (um hack feio IMHO e você acabará tendo outro problema semelhante ao alcançar o servidor diretamente através de seu 10.10 .10.148 endereço IP, uma vez que os pacotes SYN não usam o roteador, mas as respostas do servidor serão)
  • Use roteamento baseado em origem (roteamento de política) para informar ao servidor para usar o roteador quando o endereço de origem dos pacotes de saída for 10.10.10.16, qualquer que seja o endereço de destino

Claro, as opções que na verdade não são opções reais são dadas para que você possa experimentar e validar minha teoria. Roteamento baseado na origem é o que você deve fazer.

    
por 07.10.2017 / 13:08

Tags