El relé VPN deja de aceptar SSH: límites de descriptores de archivo

Un handshake de WireGuard todavía se completa, el peer todavía muestra un endpoint reciente y, sin embargo, una sesión SSH nueva a través del relé de detrás se cuelga sin ningún banner. Esa combinación apunta lejos del túnel y hacia el proceso que acepta el socket. Un relé como socat se sitúa en la ruta de la aplicación con su propio presupuesto de descriptores, sus propios hijos y sus propios límites heredados. El recorrido de abajo empieza en el cliente y se detiene en el primer componente que no puede abrir otro socket.

Siga la ruta antes de cambiar un número

Siga una petición fallida en lugar de razonar sobre el túnel en conjunto. El cliente escribe en el túnel, el demonio VPN descifra y enruta, y el relé acepta en el otro extremo. Cada paso consume descriptores, y el que suele agotarse es el último.

Empiece con una petición que pueda reproducir y mida su tiempo. Si el handshake TCP se completa pero no llega ningún banner de la aplicación, el relé tomó el socket y luego se atascó en un hijo o en su pata ascendente. Si el handshake en sí nunca se completa, la causa es el enrutamiento, el cortafuegos o el estado del oyente, no un techo de descriptores. Anote cuál de las dos formas observó, porque apuntan a procesos distintos.

Cuente también los saltos que duplican trabajo. Un oyente que bifurca entrega cada socket aceptado a un hijo que guarda su propia copia, así que el total real es una propiedad de todo el árbol, no solo del padre.

Lea el límite que heredó el relé

El único límite que importa pertenece al proceso en ejecución, y lo fijó lo que lanzó ese proceso. Escribir ulimit -n en un shell describe el shell. Pregunte al gestor de servicios qué aplicó y luego confírmelo en el PID.

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

El archivo limits imprime los techos blando y duro tal como los ve el proceso. Un valor blando bajo bajo un valor duro generoso significa que el demonio puede subir su propio techo, y algunos lo hacen al arrancar; valores blandos iguales y bajos significan que el archivo de unidad es la fuente.

Los drop-in se cargan en orden lexicográfico y los archivos posteriores ganan, así que systemctl cat vpn-relay.service es la vista autorizada de lo que se aplica. Editar un archivo que el gestor nunca lee es la razón más común de que un número subido no tenga efecto.

Separe la concurrencia estable del estado retenido

Dos procesos pueden chocar con el mismo techo por motivos no relacionados, y los remedios difieren. La demanda que sigue sesiones concurrentes útiles es una cuestión de capacidad. El crecimiento que continúa después de que termina el trabajo es una fuga o un conjunto de sesiones que nadie cerró.

Mida en reposo, en su pico normal y de nuevo unos minutos después de que pare la carga. Contar las entradas abiertas con ls /proc/PID/fd | wc -l frente al límite blando le dice el margen, y un recuento uno o dos por debajo del techo es una parada dura, no una ruta lenta.

Cuando el recuento se resiste a bajar, mire los estados de los sockets en lugar de los totales. Los descriptores parados en CLOSE_WAIT significan que el peer cerró y su lado nunca lo hizo, lo cual es un defecto del ciclo de vida de la aplicación que un límite mayor solo pospone. Limite también el modelo de hijos: un relé que bifurca sin tope de hijos concurrentes agota descriptores, ranuras de proceso y memoria a la vez.

Compruebe el valor nuevo en el proceso vivo

Después de editar la unidad, recargue el gestor y reinicie el servicio, ya que una recarga sola nunca sustituye los límites que un proceso en ejecución ya heredó. Verifíquelo en el proceso que realmente sirve 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

La línea awk devuelve el par nuevo; si sigue mostrando el antiguo, el drop-in que editó no es el que se carga. El recuento de ss es su comprobación de carga, así que abra el número de sesiones que espera y mírelo subir. Un recuento que sigue subiendo después de cerrar esas sesiones significa que el límite nunca fue todo el problema.

Una advertencia acompaña a cualquier aumento grande. Las aplicaciones que sondean con select() no pueden vigilar descriptores por encima de FD_SETSIZE, que es 1024 en las compilaciones típicas, así que un techo subido más allá puede producir fallos que parecen no relacionados. La referencia de ejecución de systemd lleva la misma advertencia para los servicios que inicia.

Mantenga el reinicio lejos de la disponibilidad del túnel

Reiniciar el relé deja caer sus sesiones activas, y eso es un evento separado de la caída de la VPN. Ordene el cambio de modo que el túnel siga arriba mientras el relé hace su ciclo, y avise a cualquiera cuya sesión larga lo cruce.

La reversión es el archivo de unidad anterior más otro reinicio, y ese archivo se queda en su sitio hasta que el valor nuevo haya sobrevivido un día de trabajo. Luego cierre el bucle con la petición que falló originalmente: una sesión SSH nueva a través del relé, una transferencia lo bastante larga para importar y un recuento de descriptores que vuelve a su nivel de reposo.