A VPN-relé leáll az SSH fogadásával: fájlleíró-korlátok

A WireGuard kézfogás továbbra is lezajlik, a peer továbbra is friss végpontot mutat, és mégis a mögötte lévő relén át indított új SSH-munkamenet banner nélkül akad el. Ez a kombináció elfelé mutat az alagúttól, a socketet fogadó folyamat felé. Egy socat-szerű relé saját leírókerettel, saját gyermekekkel és saját örökölt korlátokkal ül az alkalmazás útjában. Az alábbi séta az ügyfélnél kezdődik, és az első olyan komponensnél áll meg, amely nem tud újabb socketet nyitni.

Kövesse az útvonalat, mielőtt számot változtat

Kövessen egyetlen sikertelen kérést ahelyett, hogy az egész alagútról érvelne. Az ügyfél az alagútba ír, a VPN-démon visszafejti és irányítja a forgalmat, a relé pedig a túloldalon fogad. Minden lépés leírókat fogyaszt, és amelyik általában elfogy, az az utolsó.

Kezdje egy reprodukálható kéréssel, és mérje meg az idejét. Ha a TCP kézfogás lezajlik, de nem érkezik alkalmazás-banner, a relé átvette a socketet, majd elakadt egy gyermekben vagy a felfelé menő lábán. Ha maga a kézfogás soha nem fejeződik be, az ok az útválasztás, a tűzfal vagy a figyelő állapota, nem a leírók plafonja. Jegyezze fel, melyik formát látta, mert különböző folyamatokra mutatnak.

Számolja meg a munkát megkettőző ugrásokat is. Az elágazó figyelő minden elfogadott socketet olyan gyermeknek ad, amely saját másolatot tart, így a valódi összeg az egész fa tulajdonsága, nem csak a szülőé.

Olvassa le a korlátot, amelyet a relé örökölt

Az egyetlen számító korlát a futó folyamaté, és azt az határozta meg, ami a folyamatot elindította. Ha ulimit -n-t ír egy shellben, az a shellt írja le. Kérdezze meg a szolgáltatáskezelőt, mit alkalmazott, majd erősítse meg a PID-en.

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

A limits fájl a puha és a kemény plafont úgy nyomtatja, ahogy a folyamat látja. Alacsony puha érték bőkezű kemény érték alatt azt jelenti, hogy a démon emelheti a saját plafonját, és némelyik ezt indításkor teszi; egyenlő alacsony értékek esetén a unit-fájl a forrás.

A drop-in fájlok lexikális sorrendben töltődnek be, és a későbbi fájlok nyernek, így a systemctl cat vpn-relay.service a hiteles nézet arról, mi érvényes. Olyan fájl szerkesztése, amelyet a kezelő soha nem olvas, a leggyakoribb oka annak, hogy egy megemelt szám hatástalan.

Válassza külön az állandó párhuzamosságot a megtartott állapottól

Két folyamat ugyanazt a plafont érheti el egymástól független okokból, és a gyógymódok különböznek. A hasznos párhuzamos munkameneteket követő kereslet kapacitáskérdés. A munka vége után is folytatódó növekedés szivárgás vagy olyan munkamenetek halmaza, amelyeket senki nem zárt be.

Mérjen tétlen állapotban, a szokásos csúcsán, és újra néhány perccel a terhelés leállása után. A nyitott bejegyzések ls /proc/PID/fd | wc -l-tal való számolása a puha korláthoz képest megmondja a rést, és a plafon alatt egy-kettővel lévő szám kemény megállás, nem lassú út.

Amikor a szám nem akar csökkenni, nézze a socket-állapotokat, ne az összesítéseket. A CLOSE_WAIT-ben ülő leírók azt jelentik, hogy a peer lezárta, az Ön oldala pedig soha, ami az alkalmazás életciklusának hibája, amelyet a nagyobb korlát csak elhalaszt. A gyermekmodellt is korlátozza: az elágazó relé a párhuzamos gyermekek felső korlátja nélkül egyszerre meríti ki a leírókat, a folyamathelyeket és a memóriát.

Ellenőrizze az új értéket az élő folyamatban

A unit szerkesztése után töltse újra a kezelőt, és indítsa újra a szolgáltatást, mert az újratöltés önmagában soha nem cseréli le a futó folyamat által már örökölt korlátokat. A forgalmat ténylegesen kiszolgáló folyamaton ellenőrizze.

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 awk sor visszaadja az új párt; ha még mindig a régit mutatja, a szerkesztett drop-in nem az, amelyik betöltődik. A ss szám az Ön terhelés-ellenőrzése, ezért nyissa meg a várt munkamenetszámot, és figyelje, ahogy emelkedik. Az a szám, amely a munkamenetek bezárása után is emelkedik, azt jelenti, hogy a korlát soha nem volt a teljes probléma.

Minden nagy emeléshez tartozik egy fenntartás. A select()-cel kérdező alkalmazások nem tudnak a FD_SETSIZE feletti leírókat figyelni, ami a tipikus buildekben 1024, így az e fölé emelt plafon olyan hibákat okozhat, amelyek függetlennek tűnnek. A systemd végrehajtási referenciája ugyanezt a figyelmeztetést hordozza az általa indított szolgáltatásokra.

Tartsa az újraindítást távol az alagút elérhetőségétől

A relé újraindítása eldobja az aktív munkameneteit, és ez külön esemény a VPN leállásától. Úgy rendezze a változtatást, hogy az alagút fent maradjon, miközben a relé ciklusol, és figyelmeztessen mindenkit, akinek hosszú életű munkamenete átlépi.

A visszaállás az előző unit-fájl plusz még egy újraindítás, és az a fájl a helyén marad, amíg az új érték túlél egy munkanapot. Aztán zárja le a ciklust azzal a kéréssel, amely eredetileg elbukott: egy új SSH-munkamenet a relén át, egy elég hosszú átvitel, hogy számítson, és egy leírószám, amely visszatér tétlen szintjére.