Exaustão do limite de soquete TCP da máquina Linux (~ 70k)?

Question

Eu sou o fundador da torservers.net, uma organização sem fins lucrativos que executa os nós de saída do Tor. Temos várias máquinas em conectividade Gbit e vários IPs, e parece que estamos atingindo um limite de soquetes TCP abertos em todas essas máquinas. Estamos pairando em torno de ~ 70k do total de conexões TCP no total (~ 10-15k por IP), e Tor está registrando "Soquete de rede de ligação de erro: Endereço já em uso" como um louco. Existe alguma solução para isso? O BSD sofre do mesmo problema?

Nós corremos para os processos do Tor, cada um deles ouvindo um IP diferente. Exemplo:

# NETSTAT='netstat -nta'
# echo "$NETSTAT" | wc -l
67741
# echo "$NETSTAT" | grep ip1 | wc -l
19886
# echo "$NETSTAT" | grep ip2 | wc -l
15014
# echo "$NETSTAT" | grep ip3 | wc -l
18686
# echo "$NETSTAT" | grep ip4 | wc -l
14109

Eu apliquei os ajustes que pude encontrar na internet:

# cat /etc/sysctl.conf
net.ipv4.ip_forward = 0
net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_synack_retries = 2
net.ipv4.tcp_syn_retries = 2
net.ipv4.conf.default.forwarding = 0
net.ipv4.conf.default.proxy_arp = 0
net.ipv4.conf.default.send_redirects = 1
net.ipv4.conf.all.rp_filter = 0
net.ipv4.conf.all.send_redirects = 0
kernel.sysrq = 1
net.ipv4.icmp_echo_ignore_broadcasts = 1
net.ipv4.conf.all.accept_redirects = 0
net.ipv4.icmp_ignore_bogus_error_responses = 1
net.core.rmem_max = 33554432
net.core.wmem_max = 33554432
net.ipv4.tcp_rmem = 4096 87380 33554432
net.ipv4.tcp_wmem = 4096 65536 33554432
net.core.netdev_max_backlog = 262144
net.ipv4.tcp_no_metrics_save = 1
net.ipv4.tcp_moderate_rcvbuf = 1
net.ipv4.tcp_orphan_retries = 2
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_tw_recycle = 0
net.ipv4.tcp_max_orphans = 262144
net.ipv4.tcp_max_syn_backlog = 262144
net.ipv4.tcp_fin_timeout = 4
vm.min_free_kbytes = 65536
net.ipv4.netfilter.ip_conntrack_max = 196608
net.netfilter.nf_conntrack_tcp_timeout_established = 7200
net.netfilter.nf_conntrack_checksum = 0
net.netfilter.nf_conntrack_max = 196608
net.netfilter.nf_conntrack_tcp_timeout_syn_sent = 15
net.nf_conntrack_max = 196608
net.ipv4.tcp_keepalive_time = 60
net.ipv4.tcp_keepalive_intvl = 10
net.ipv4.tcp_keepalive_probes = 3
net.ipv4.ip_local_port_range = 1025 65535
net.core.somaxconn = 262144
net.ipv4.tcp_max_tw_buckets = 2000000
net.ipv4.tcp_timestamps = 0

# sysctl fs.file-max
fs.file-max = 806854

# ulimit -n
500000

# cat /etc/security/limits.conf
*       soft    nofile 500000
*       hard    nofile 500000

    

Answer 1

Se houver processos vinculados a INADDR_ANY , alguns sistemas tentarão selecionar portas apenas no intervalo de 49152 a 65535. Isso pode ser responsável pelo seu limite de ~ 15k, já que o intervalo é exatamente de 16384 portas.

Wikipedia: Porta efêmera

Você pode expandir esse intervalo encontrando as instruções para seu sistema operacional aqui:

O intervalo de portas efêmeras

    

Answer 2

Esta é uma limitação do protocolo TCP. A porta é um int curto não assinado (0-65535). A solução é usar endereços IP diferentes.

Se o software não puder ser alterado, você poderá usar a virtualização. Crie VMs com ponte (não NAT) e que usem IPs públicos para que não sejam NAT depois.

Verifique com o netstat se os ouvintes usam o IP em uma interface e não em todos os endereços (0.0.0.0):

sudo netstat -tulnp|grep '0\.0\.0\.0'