Linux: rastreando a origem do netstat -s “tentativas de conexão com falha”

Question

Eu tenho vários servidores, onde a métrica de tentativas de conexão com falha retornada pelo netstat -s (de / proc / net / snmp) cresce aproximadamente um por segundo, e gostaria de diagnosticar a origem deles.

Usando esta regra do ipTables (em um servidor diferente):

-A OUTPUT -p tcp --dport 23 -j REJECT

Estou bloqueando o telnet de saída para que eu possa executar este loop:

while true ; do
telnet www.google.co.uk
netstat -s | grep "failed connection"
done

Trying 209.85.203.94...
telnet: Unable to connect to remote host: Connection refused
52 failed connection attempts
Trying 209.85.203.94... telnet: Unable to connect to remote host: Connection refused
53 failed connection attempts
Trying 209.85.203.94... telnet: Unable to connect to remote host: Connection refused
54 failed connection attempts

Provando assim que o contador é incrementado por tentativas falhas de conexão a soquetes remotos. (Embora isso não prove que essa é a única causa de incrementos, é claro).

A questão é, como posso encontrar a combinação específica de endereço remoto e porta (ou plural de ambos), que está falhando, para que eu possa olhar para a próxima etapa; problemas de roteamento / firewall?
Como um aparte, se eu executar isso:

watch -n1 'ss | grep "\<23\>"'

Eu estava esperando ver soquetes no estado SYN-SENT, mas não o faça. Isso é porque eu usei REJECT, em vez de DROP? Obrigado

    

Answer 1

Vamos tentar responder a pergunta de outra maneira (difícil). Leia a fonte do kernel para ver, o que há apenas um lugar, onde esta métrica aumenta - tcp_done . Como podemos ver no código, o incremento acontece apenas para conexões nos estados SYN_SEND ou SYN_RECV. Então nós checamos, de onde o tcp_done pode ser chamado. E podemos encontrar vários lugares:

1. tcp_reset - chamado no abort of connection (pacote de resposta com a primeira bandeira recebida). Sim, isso pode acontecer nos estados SYN_SENT e SYN_RECV (e em outros estados, teoricamente).
2. tcp_rcv_state_process - chamado nos estados TCP_FIN_WAIT1 e TCP_LAST_ACK, então a métrica não é incrementada - não é o nosso caso.
3. tcp_v4_error - chamado no caso de SYN_SENT ou SYN_RECV. A função tcp_v4_error chamada pelo manipulador ICMP.
4. tcp_time_wait - chamado de mover o soquete para dentro do tempo wait ou fin-wait-2 states - não é o nosso caso também.
5. tcp_write_error - chamado de vários lugares nos tempos limite e retransmitir contagem excedida. Pode ser nosso suspeito também.

Agora, abra qualquer diagrama TCP FSM para verificar, em quais casos nossa conexão pode estar em SYN_SENT ou SYN_RECV.

No caso do cliente, pode ser apenas o estado SYN_SENT, onde os pacotes syn estão transmitindo e a conexão cancelada devido ao recebimento de rejeição (tcp-rst ou erro icmp) ou a resposta não é recebida.

No caso do servidor, pode ser apenas SYN_RECV (syn já foi recebido e syn + ack já foi enviado) e conexão cancelada devido a recebimento de rejeição (syn + ack rejeitado em algum lugar) ou o tempo limite de espera de resposta é excedido (uma confirmação não é recebido).

Agora você sabe as razões da atualização dessa métrica e pode verificar as possíveis origens dela no seu sistema. No kernel moderno, existem ferramentas poderosas para solucionar problemas no nível do kernel. Comece de este breve tutorial de Brendan Gregg. / p>     

Answer 2

Uma vez que uma fonte significativa de conexões descartadas parece ser uma tentativa de se conectar a servidores não responsivos. Lembre-se de que acreditamos que "tentativas de conexão com falha" se referem a conexões de saída .

Rodando

ss | awk '$1 ~ /SYN-SENT/ {print $NF}'

10.160.32.211:8312
10.160.33.61:8312
10.160.32.146:8312
10.160.33.216:8312
10.160.34.186:8312
10.160.35.18:8312
10.160.32.157:8312
10.160.33.159:8312
10.160.34.246:8312

mostra muitas conexões nesse estado. Curiosamente, aponta para todos eles tentando se conectar à mesma porta. Se eu tentar endereços IP aleatórios dessa lista e tentar conectar-me à porta 8312 com telnet - por exemplo:

$ telnet 10.160.34.246 8312
telnet: connect to address 10.160.32.48: Connection timed out

O envio de um pacote SYN é o primeiro passo para estabelecer uma conexão. O outro lado deve responder com um pacote SYN-ACK - nesse caso, respondemos com um ACK e a conexão é estabelecida. Se, no entanto, houver um firewall entre os dois servidores, bloqueando a conexão, o SYN-ACK não será disponibilizado, portanto, o soquete permanecerá no estado SYN_SENT até que o tempo limite seja atingido.
Aqui está um diagrama roubado de lwn.net:

Estetempolimitenãoélongo(estoutentandodescobrirporquantotempoeatualizareiapropriadamente)-atéondepossodizeratéagora,édaordemdealgunssegundos(euteriapensado2xMSL,ondeMSLéaduraçãomáximadosegmento-masissoéumpalpite).

Agora,precisamosdiferenciarentretentativasdeconexãoemqueumSYNéenviadoenadaretorna,eumemqueumRSTéretornado.Umfirewallnocaminhonormalmenteébastanterude;eleiráremoveropacoteSYNoriginalsilenciosamente-elenãoenviaráumRST,queéamaneiranormaldeinformaraoclientequenãohánadaaqui.

Vocêpodeverumcomportamentosemelhanteaotentarseconectarawww.google.co.ukemumaportanaqualsuspeitaqueelesnãoestarãoouvindo,porexemplo:

$telnetwww.google.co.uk32654
Trying74.125.203.94...telnet:connecttoaddress74.125.203.94:Connectiontimedout

Enquantoexecutasimultaneamentealgoassim:

whiletrue;doss|awk'/SYN-SENT/&&$NF!~/^10./';sleep2;done
SYN-SENT0110.137.6.62:4608874.125.203.94:32654
SYN-SENT0110.137.6.62:4608874.125.203.94:32654
SYN-SENT0110.137.6.62:4608874.125.203.94:32654

Agora,estoudentrodeumaredecorporativae,quasedecerteza,oacessoaoGoogleemumaportanormal80/443éintermediadoporproxyequalqueroutraportatemfirewall,portanto,nãoesperamosverpacotesRST.Éporissoque,napergunta,euperguntosobreadiferençanasminhasregrasdoIPTablesentreREJECTeDROP.ODROPsimplesmentedescartaopacotenoIPTables,enquantooREJECTenviaumRST,euacredito.

Oqueeufareiemseguidaétcpdumpumaconexãocomumaportaquenãoescuta,eatualizaapropriadamente.

$tcpdump-nn-t-ieth0dst8.8.8.8
tcpdump:WARNING:eth0:noIPv4addressassigned
tcpdump:verboseoutputsuppressed,use-vor-vvforfullprotocoldecode
listeningoneth0,link-typeEN10MB(Ethernet),
capturesize65535bytes
IP10.137.6.62.40822>8.8.8.8.12345:Flags[S],seq505811469,win14600,options[mss1460,sackOK,TSval1513647100ecr0,nop,wscale9],length0
IP10.137.6.62.408228.8.8.8.12345:Flags[S],seq505811469,win14600,options[mss1460,sackOK,TSval1513648100ecr0,nop,wscale9],length0
IP10.137.6.62.40822>8.8.8.8.12345:Flags[S],seq505811469,win14600,options[mss1460,sackOK,TSval1513650100ecr0,nop,wscale9],length0
IP10.137.6.62.40822>8.8.8.8.12345:Flags[S],seq505811469,win14600,options[mss1460,sackOK,TSval1513654100ecr0,nop,wscale9],length0
IP10.137.6.62.40822>8.8.8.8.12345:Flags[S],seq505811469,win14600,options[mss1460,sackOK,TSval1513662100ecr0,nop,wscale9],length0
IP10.137.6.62.40822>8.8.8.8.12345:Flags[S],seq505811469,win14600,options[mss1460,sackOK,TSval1513678100ecr0,nop,wscale9],length0

TODO:Adicioneumtcpdumpdocasoondenãoháfirewall,entãovemospacotesRST.

UmaressalvaExistemmuitasfontesúteisdeinformaçõessobreadepuraçãodaconexãoTCPdoLinux.ARedHatéumadessasfontes.Emumadesuaspáginas,elessugeremousodaferramentadropwatch,paraestabelecerondeospacotesdarededokernelestãosendodescartados.Oqueessapáginanãoconseguedizeréque"descartar" pacotes de uma pilha de software é normal - uma vez que um pacote tenha sido resolvido, ele é descartado. A ferramenta dropwatch não faz distinção entre um pacote que é descartado porque é finalizado e um que é descartado devido a um estouro de buffer ou um tempo limite de orçamento de interrupção ou ...

Caveat Emptor.