Problema
Eu executo um servidor de IRC para 20 a 50 usuários. Às vezes, temos problemas com mensagens que não chegam em tempo hábil ou de forma alguma. Depois de algumas capturas de pacotes, determinamos que as mensagens ficam no "Send-Q" do servidor. Quando uma mensagem não chegar, vou olhar para a saída "netstat -ct" e ver algo assim:
Proto Recv-Q Send-Q Local Address Foreign Address State
tcp 0 1756 ubuntu:ircd 10.8.1.7:63602 ESTABLISHED
Às vezes, se eu esperar por alguns minutos, o Send-Q vai para 0 e a mensagem será entregue, outras vezes o cliente expira. Minha pergunta é: por que não entrega as mensagens? O que faz com que eles fiquem sentados em Send-Q por tanto tempo?
sshd também exibe comportamento similar, minhas sessões ssh congelam às vezes elas voltam, às vezes elas param.
Antecedentes
Não tenho certeza se a infraestrutura aqui pode estar relacionada ao problema, então aqui está o que parece: esses clientes estão no Windows 7 se conectando ao OpenVPN. O servidor OpenVPN está no PFSense, o servidor IRC está em uma LAN local (NAT) conectada ao PFSense. Eu tenho uma regra de firewall para permitir que os clientes falem com o 6667 no servidor.
Investigando ...
Latência / perda - parece decente o suficiente. Não é o melhor link, mas eu acho que isso seria ótimo para o IRC e SSH. Aqui está um ping do meu cliente para o servidor, isto é, enquanto o meu IRC e SSH estão interrompendo intermitentemente:
Ping statistics for 10.8.5.2:
Packets: Sent = 4478, Received = 4460, Lost = 18 (0% loss)
Tempos de ida e volta aproximados em milissegundos:
Mínimo = 17,2 ms, Máximo = 273,4 ms, Média = 32,3 ms
Problemas com MSS / MTU - a MTU parece estar bem. OpenVPN mtu-test no meu cliente diz:
Thu Dec 03 12:41:21 2015 NOTE: Empirical MTU test completed [Tried,Actual] local->remote=[1589,1589] remote->local=[1589,1589]
... e aqui está o meu teste manual:
> ping -f -l 1472 10.8.5.2
Pinging 10.8.5.2 with 1472 bytes of data:
Reply from 10.8.5.2: bytes=1472 time=23ms TTL=63
> ping -f -l 1473 10.8.5.2
Pinging 10.8.5.2 with 1473 bytes of data:
Packet needs to be fragmented but DF set.
Largura de banda / taxa de transferência - fizemos alguns testes iperf para garantir que não houvesse um problema de taxa de transferência. Mais uma vez, parece decente o suficiente:
iperf -c 10.8.5.2
------------------------------------------------------------
Client connecting to 10.8.5.2, TCP port 5001
TCP window size: 63.0 KByte (default)
------------------------------------------------------------
[ 3] local 10.8.0.23 port 18587 connected with 10.8.5.2 port 5001
[ ID] Interval Transfer Bandwidth
[ 3] 0.0-10.0 sec 26.0 MBytes 21.8 Mbits/sec
Obrigado, qualquer ajuda sobre "Send-Q" ou idéias mais específicas sobre esse assunto seria muito apreciada. Deixe-me saber se posso fornecer mais informações aqui.
Atualizar
Descobri que eu realmente tive uma perda maciça de pacotes. Os pings de client- > VPN não mostraram isso, mas ficou muito aparente ao usar o fping do cliente VPN- & gt ;. Notei que eram apenas os clientes do Windows, e a reinstalação do mais novo cliente OpenVPN parece ter corrigido a perda. Pode ter sido relacionado ao adaptador OpenVPN TAP sendo instalado via imagem de disco. Instalá-lo manualmente por máquina parece resolver o problema.