O relé VPN deixa de aceptar SSH: límites de descritores de ficheiro

Un handshake de WireGuard aínda se completa, o peer aínda mostra un endpoint recente e, con todo, unha sesión SSH nova a través do relé de detrás queda colgada sen ningún banner. Esa combinación apunta lonxe do túnel e cara ao proceso que acepta o socket. Un relé como socat sitúase na ruta da aplicación co seu propio orzamento de descritores, os seus propios fillos e os seus propios límites herdados. O percorrido de abaixo comeza no cliente e detense no primeiro compoñente que non pode abrir outro socket.

Siga a ruta antes de cambiar un número

Siga unha petición fallida en lugar de razoar sobre o túnel no seu conxunto. O cliente escribe no túnel, o daemon VPN descifra e encamiña, e o relé acepta no outro extremo. Cada paso consome descritores, e o que adoita esgotarse é o último.

Comece cunha petición que poida reproducir e mida o seu tempo. Se o handshake TCP se completa pero non chega ningún banner da aplicación, o relé tomou o socket e logo quedou atascado nun fillo ou na súa pata ascendente. Se o handshake en si nunca se completa, a causa é o encamiñamento, a devasa ou o estado do oínte, non un teito de descritores. Anote cal das dúas formas observou, porque apuntan a procesos distintos.

Conte tamén os saltos que duplican traballo. Un oínte que se bifurca entrega cada socket aceptado a un fillo que garda a súa propia copia, así que o total real é unha propiedade de toda a árbore, non só do pai.

Lea o límite que herdou o relé

O único límite que importa pertence ao proceso en execución, e fixouno o que lanzou ese proceso. Escribir ulimit -n nun shell describe o shell. Pregunte ao xestor de servizos que aplicou e despois confírmeo 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 teitos brando e duro tal como os ve o proceso. Un valor brando baixo baixo un valor duro xeneroso significa que o daemon pode subir o seu propio teito, e algúns fano no arranque; valores brandos iguais e baixos significan que o ficheiro de unidade é a fonte.

Os drop-in cárganse en orde lexicográfica e os ficheiros posteriores gañan, así que systemctl cat vpn-relay.service é a vista autorizada do que se aplica. Editar un ficheiro que o xestor nunca le é a razón máis común de que un número subido non teña efecto.

Separe a concorrencia estable do estado retido

Dous procesos poden bater co mesmo teito por motivos non relacionados, e os remedios difiren. A demanda que segue sesións concorrentes útiles é unha cuestión de capacidade. O crecemento que continúa despois de que remate o traballo é unha fuga ou un conxunto de sesións que ninguén pechou.

Mida en repouso, no seu pico normal e de novo uns minutos despois de que pare a carga. Contar as entradas abertas con ls /proc/PID/fd | wc -l fronte ao límite brando dille a marxe, e un reconto un ou dous por baixo do teito é unha parada dura, non unha ruta lenta.

Cando o reconto se resiste a baixar, mire os estados dos sockets en lugar dos totais. Os descritores parados en CLOSE_WAIT significan que o peer pechou e o seu lado nunca o fixo, o cal é un defecto do ciclo de vida da aplicación que un límite maior só pospón. Limite tamén o modelo de fillos: un relé que se bifurca sen tope de fillos concorrentes esgota descritores, rañuras de proceso e memoria á vez.

Comprobe o valor novo no proceso vivo

Despois de editar a unidade, recargue o xestor e reinicie o servizo, xa que unha recarga soa nunca substitúe os límites que un proceso en execución xa herdou. Verifique no proceso que realmente serve tráfico.

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 liña awk devolve o par novo; se aínda mostra o antigo, o drop-in que editou non é o que se carga. O reconto de ss é a súa comprobación de carga, así que abra o número de sesións que espera e míreo subir. Un reconto que segue subindo despois de pechar esas sesións significa que o límite nunca foi todo o problema.

Unha advertencia acompaña calquera aumento grande. As aplicacións que sondan con select() non poden vixiar descritores por riba de FD_SETSIZE, que é 1024 nas compilacións típicas, así que un teito subido máis alá pode producir fallos que parecen non relacionados. A referencia de execución de systemd leva a mesma advertencia para os servizos que inicia.

Manteña o reinicio lonxe da dispoñibilidade do túnel

Reiniciar o relé deixa caer as súas sesións activas, e iso é un evento separado da caída da VPN. Ordene o cambio de xeito que o túnel siga arriba mentres o relé fai o ciclo, e avise a calquera cuxa sesión longa o cruce.

A reversión é o ficheiro de unidade anterior máis outro reinicio, e ese ficheiro queda no seu sitio ata que o valor novo sobreviva un día de traballo. Logo peche o bucle coa petición que fallou orixinalmente: unha sesión SSH nova a través do relé, unha transferencia o bastante longa para importar e un reconto de descritores que volve ao seu nivel de repouso.