El relé VPN deixa d’acceptar SSH: límits de descriptors de fitxer

Un handshake de WireGuard encara es completa, el peer encara mostra un punt final recent i, tanmateix, una sessió SSH nova a través del relé del darrere es penja sense cap banner. Aquesta combinació apunta lluny del túnel i cap al procés que accepta el sòcol. Un relé com socat se situa al camí de l’aplicació amb el seu propi pressupost de descriptors, els seus propis fills i els seus propis límits heretats. El recorregut de sota comença al client i s’atura al primer component que no pot obrir un altre sòcol.

Seguiu el camí abans de canviar un número

Seguiu una petició fallida en lloc de raonar sobre el túnel sencer. El client escriu al túnel, el dimoni VPN desxifra i encamina, i el relé accepta a l’altra banda. Cada pas consumeix descriptors, i el que normalment s’esgota és l’últim.

Comenceu amb una petició que pugueu reproduir i mesureu-ne el temps. Si el handshake TCP es completa però no arriba cap banner de l’aplicació, el relé va prendre el sòcol i després es va encallar en un fill o a la seva cama ascendent. Si el handshake mateix no es completa mai, la causa és l’encaminament, el tallafoc o l’estat de l’oient, no un sostre de descriptors. Anoteu quina de les dues formes heu observat, perquè apunten a processos diferents.

Compteu també els salts que dupliquen feina. Un oient que bifurca lliura cada sòcol acceptat a un fill que en guarda la seva pròpia còpia, així que el total real és una propietat de tot l’arbre, no només del pare.

Llegiu el límit que el relé ha heretat

L’únic límit que importa pertany al procés en execució, i el va fixar allò que va llançar aquell procés. Escriure ulimit -n en un shell descriu el shell. Pregunteu al gestor de serveis què ha aplicat i després confirmeu-ho al PID.

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

El fitxer limits imprimeix els sostres tou i dur tal com els veu el procés. Un valor tou baix sota un valor dur generós vol dir que el dimoni pot apujar el seu propi sostre, i alguns ho fan a l’inici; valors tous iguals i baixos volen dir que el fitxer d’unitat n’és la font.

Els drop-in es carreguen en ordre lexicogràfic i els fitxers posteriors guanyen, així que systemctl cat vpn-relay.service és la vista autoritzada del que s’aplica. Editar un fitxer que el gestor no llegeix mai és la raó més comuna perquè un número apujat no tingui efecte.

Separeu la concurrència estable de l’estat retingut

Dos processos poden topar amb el mateix sostre per motius no relacionats, i els remeis difereixen. La demanda que segueix sessions concurrents útils és una qüestió de capacitat. El creixement que continua després que la feina acabi és una fuita o un conjunt de sessions que ningú no ha tancat.

Mesureu en repòs, al vostre pic normal i de nou uns minuts després que la càrrega pari. Comptar les entrades obertes amb ls /proc/PID/fd | wc -l contra el límit tou us diu el marge, i un compte un o dos per sota del sostre és una aturada dura, no un camí lent.

Quan el compte es resisteix a baixar, mireu els estats dels sòcols en lloc dels totals. Els descriptors parats a CLOSE_WAIT volen dir que el peer ha tancat i el vostre costat no ho ha fet mai, cosa que és un defecte del cicle de vida de l’aplicació que un límit més gran només ajorna. Limiteu també el model de fills: un relé que bifurca sense topall de fills concurrents esgota descriptors, llocs de procés i memòria alhora.

Comproveu el valor nou al procés viu

Després d’editar la unitat, recarregueu el gestor i reinicieu el servei, ja que una recàrrega sola no substitueix mai els límits que un procés en execució ja ha heretat. Verifiqueu-ho al procés que realment serveix trànsit.

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ínia awk retorna la parella nova; si encara mostra l’antiga, el drop-in que heu editat no és el que es carrega. El compte de ss és la vostra comprovació de càrrega, així que obriu el nombre de sessions que espereu i mireu com puja. Un compte que continua pujant després que aquestes sessions es tanquin vol dir que el límit no era mai tot el problema.

Un advertiment acompanya qualsevol augment gran. Les aplicacions que sondegen amb select() no poden vigilar descriptors per sobre de FD_SETSIZE, que és 1024 en les compilacions típiques, així que un sostre apujat més enllà pot produir fallades que semblen no relacionades. La referència d’execució de systemd porta el mateix avís per als serveis que inicia.

Manteniu el reinici lluny de la disponibilitat del túnel

Reiniciar el relé deixa caure les seves sessions actives, i això és un esdeveniment separat de la caiguda de la VPN. Ordeneu el canvi de manera que el túnel es mantingui aixecat mentre el relé fa el cicle, i aviseu qualsevol la sessió llarga del qual el travessi.

La reversió és el fitxer d’unitat anterior més un altre reinici, i aquest fitxer es queda al lloc fins que el valor nou hagi sobreviscut un dia de feina. Després tanqueu el bucle amb la petició que va fallar originalment: una sessió SSH nova a través del relé, una transferència prou llarga per importar i un compte de descriptors que torna al seu nivell de repòs.