O relay VPN deixa de aceitar SSH: limites de descritores de ficheiro

Um handshake WireGuard ainda se completa, o peer ainda mostra um endpoint recente e, no entanto, uma nova sessão SSH através do relay por trás fica pendurada sem qualquer banner. Essa combinação afasta do túnel e aponta para o processo que aceita o socket. Um relay como o socat fica no caminho da aplicação com o seu próprio orçamento de descritores, os seus próprios filhos e os seus próprios limites herdados. O percurso abaixo começa no cliente e para no primeiro componente que não consegue abrir outro socket.

Siga o caminho antes de mudar um número

Siga um pedido falhado em vez de raciocinar sobre o túnel como um todo. O cliente escreve no túnel, o daemon VPN desencripta e encaminha, e o relay aceita do outro lado. Cada passo consome descritores, e o que normalmente se esgota é o último.

Comece com um pedido que consiga reproduzir e meça o tempo. Se o handshake TCP se completa mas não chega qualquer banner da aplicação, o relay apanhou o socket e depois ficou preso num filho ou na sua perna ascendente. Se o próprio handshake nunca se completa, a causa é o encaminhamento, a firewall ou o estado do ouvinte, não um teto de descritores. Registe qual das duas formas observou, porque apontam para processos diferentes.

Conte também os saltos que duplicam trabalho. Um ouvinte que se bifurca entrega cada socket aceite a um filho que guarda a sua própria cópia, por isso o total real é uma propriedade de toda a árvore, não apenas do pai.

Leia o limite que o relay herdou

O único limite que importa pertence ao processo em execução, e foi definido por aquilo que lançou esse processo. Escrever ulimit -n numa shell descreve a shell. Pergunte ao gestor de serviços o que aplicou e depois confirme no PID.

systemctl show -p MainPID -p LimitNOFILE vpn-relay.service
cat /proc/$(systemctl show -p MainPID --value vpn-relay.service)/limits

O ficheiro limits imprime os tetos flexível e rígido tal como o processo os vê. Um valor flexível baixo sob um valor rígido generoso significa que o daemon pode subir o seu próprio teto, e alguns fazem isso no arranque; valores flexíveis iguais e baixos significam que o ficheiro de unidade é a fonte.

Os drop-in carregam-se por ordem lexicográfica e os ficheiros posteriores ganham, por isso systemctl cat vpn-relay.service é a vista autoritativa do que se aplica. Editar um ficheiro que o gestor nunca lê é a razão mais comum para um número aumentado não ter efeito.

Separe a concorrência estável do estado retido

Dois processos podem atingir o mesmo teto por razões não relacionadas, e os remédios diferem. A procura que acompanha sessões concorrentes úteis é uma questão de capacidade. O crescimento que continua depois de o trabalho terminar é uma fuga ou um conjunto de sessões que ninguém fechou.

Meça em repouso, no seu pico normal e novamente alguns minutos depois de a carga parar. Contar as entradas abertas com ls /proc/PID/fd | wc -l face ao limite flexível diz-lhe a folga, e uma contagem uma ou duas abaixo do teto é uma paragem dura, não um caminho lento.

Quando a contagem se recusa a descer, olhe para os estados dos sockets em vez dos totais. Descritores parados em CLOSE_WAIT significam que o peer fechou e o seu lado nunca o fez, o que é um defeito do ciclo de vida da aplicação que um limite maior apenas adia. Limite também o modelo de filhos: um relay que se bifurca sem limite de filhos concorrentes esgota descritores, lugares de processo e memória em conjunto.

Verifique o novo valor no processo vivo

Depois de editar a unidade, recarregue o gestor e reinicie o serviço, porque uma recarga sozinha nunca substitui limites que um processo em execução já herdou. Verifique no processo que realmente serve tráfego.

systemctl daemon-reload
systemctl restart vpn-relay.service
awk '/Max open files/ {print}' /proc/$(systemctl show -p MainPID --value vpn-relay.service)/limits
ss -tnp state established '( sport = :2222 )' | wc -l

A linha awk devolve o novo par; se ainda mostrar o antigo, o drop-in que editou não é o que está a ser carregado. A contagem de ss é a sua verificação de carga, por isso abra o número de sessões que espera e veja-a subir. Uma contagem que continua a subir depois de essas sessões fecharem significa que o limite nunca foi todo o problema.

Um aviso acompanha qualquer aumento grande. As aplicações que consultam com select() não conseguem vigiar descritores acima de FD_SETSIZE, que é 1024 nas compilações típicas, por isso um teto aumentado para além disso pode produzir falhas que parecem não relacionadas. A referência de execução do systemd traz o mesmo aviso para os serviços que inicia.

Mantenha o reinício longe da disponibilidade do túnel

Reiniciar o relay derruba as suas sessões ativas, e isso é um evento separado da queda da VPN. Ordene a mudança para que o túnel permaneça em cima enquanto o relay faz o ciclo, e avise quem tiver uma sessão longa que o atravesse.

A reversão é o ficheiro de unidade anterior mais outro reinício, e esse ficheiro fica no lugar até o novo valor sobreviver a um dia de trabalho. Depois feche o ciclo com o pedido que falhou originalmente: uma nova sessão SSH através do relay, uma transferência suficientemente longa para contar e uma contagem de descritores que regressa ao seu nível de repouso.