VPN-reléet slutter å godta SSH: grenser for fildeskriptorer

En WireGuard-håndtrykk fullføres fortsatt, peer viser fortsatt et nylig endepunkt, og likevel henger en ny SSH-økt gjennom reléet bak det uten banner. Den kombinasjonen peker bort fra tunnelen og mot prosessen som godtar socketen. Et relé som socat sitter i applikasjonens bane med sitt eget deskriptorbudsjett, sine egne barn og sine egne arvede grenser. Vandringen nedenfor starter hos klienten og stopper ved den første komponenten som ikke kan åpne en ny socket.

Følg ruten før du endrer et tall

Følg én mislykket forespørsel i stedet for å resonnere om tunnelen som helhet. Klienten skriver inn i tunnelen, VPN-demonen dekrypterer og ruter, og reléet godtar på den andre siden. Hvert trinn bruker deskriptorer, og det som vanligvis går tom, er det siste.

Start med en forespørsel du kan gjenskape, og mål tiden. Hvis TCP-håndtrykket fullføres, men ingen applikasjonsbanner kommer, tok reléet socketen og satte seg deretter fast i et barn eller på oppstrømsbenet. Hvis selve håndtrykket aldri fullføres, er årsaken ruting, brannmur eller lyttetilstand, ikke et deskriptortak. Noter hvilken av de to formene du så, fordi de peker på forskjellige prosesser.

Tell også hoppene som dupliserer arbeid. En forgrenende lytter overleverer hver godtatte socket til et barn som beholder sin egen kopi, så det reelle totalet er en egenskap ved hele treet, ikke bare forelderen.

Les grensen reléet arvet

Den eneste grensen som betyr noe, tilhører den kjørende prosessen, og den ble satt av det som startet prosessen. Å skrive ulimit -n i et skall beskriver skallet. Spør tjenestebehandleren hva den brukte, og bekreft deretter på PID-en.

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

Filen limits skriver ut den myke og den harde grensen slik prosessen ser dem. En lav myk verdi under en romslig hard verdi betyr at demonen har lov til å heve sin egen grense, og noen gjør det ved oppstart; like lave verdier betyr at unit-filen er kilden.

Drop-in-filer lastes i leksikalsk rekkefølge, og senere filer vinner, så systemctl cat vpn-relay.service er den autoritative visningen av hva som gjelder. Å redigere en fil som behandleren aldri leser, er den vanligste grunnen til at et hevet tall ikke har effekt.

Skilj jevn samtidighet fra beholdt tilstand

To prosesser kan treffe samme tak av ulike grunner, og botemidlene er forskjellige. Etterspørsel som følger nyttige samtidige økter, er et kapasitetsspørsmål. Vekst som fortsetter etter at arbeidet er over, er en lekkasje eller et sett med økter som ingen lukket.

Mål i tomgang, ved din normale topp og igjen noen minutter etter at lasten stopper. Å telle åpne oppføringer med ls /proc/PID/fd | wc -l mot den myke grensen forteller deg gapet, og et tall én eller to under taket er en hard stopp, ikke en treg vei.

Når tallet nekter å falle, se på socket-tilstander i stedet for totaler. Deskriptorer som sitter i CLOSE_WAIT betyr at peer lukket og din side aldri gjorde det, noe som er en feil i applikasjonens livssyklus som en større grense bare utsetter. Begrens også barnemodellen: et forgrenende relé uten tak på samtidige barn tømmer deskriptorer, prosessplasser og minne samtidig.

Kontroller den nye verdien på den levende prosessen

Etter å ha redigert unit-filen, last behandleren på nytt og start tjenesten på nytt, siden en omlasting alene aldri erstatter grenser som en kjørende prosess allerede har arvet. Verifiser på prosessen som faktisk betjener trafikken.

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

Linjen awk returnerer det nye paret; hvis den fortsatt viser det gamle, er drop-in-filen du redigerte ikke den som lastes. Tallet fra ss er lastkontrollen din, så åpne antallet økter du forventer, og se det stige. Et tall som fortsetter å stige etter at disse øktene lukkes, betyr at grensen aldri var hele problemet.

Én advarsel følger enhver stor økning. Applikasjoner som spør med select(), kan ikke overvåke deskriptorer over FD_SETSIZE, som er 1024 på typiske bygg, så et tak hevet forbi det kan gi feil som virker urelaterte. systemd-kjøringsreferansen bærer samme advarsel for tjenestene den starter.

Hold omstarten unna tunnelens tilgjengelighet

Omstart av reléet dropper de aktive øktene, og det er en egen hendelse fra VPN-en som faller. Ordne endringen slik at tunnelen blir oppe mens reléet sykler, og varsle alle hvis langvarige økt krysser den.

Tilbakerulling er den forrige unit-filen pluss nok en omstart, og den filen blir på plass til den nye verdien har overlevd en arbeidsdag. Lukk deretter loopen med forespørselen som opprinnelig feilet: én ny SSH-økt gjennom reléet, én overføring lang nok til å bety noe, og et deskriptortall som går tilbake til tomgangsnivået.