VPN relay přestává přijímat SSH: limity deskriptorů souborů

Rukování WireGuard se stále dokončí, peer stále ukazuje nedávný koncový bod, a přesto nová relace SSH přes relay za ním visí bez banneru. Tato kombinace ukazuje pryč od tunelu k procesu, který přijímá socket. Relay jako socat sedí v cestě aplikace s vlastním rozpočtem deskriptorů, vlastními potomky a vlastními zděděnými limity. Procházka níže začíná u klienta a končí u první komponenty, která nemůže otevřít další socket.

Projděte cestu, než změníte číslo

Sledujte jeden neúspěšný požadavek místo uvažování o tunelu jako celku. Klient zapisuje do tunelu, VPN démon dešifruje a směruje a relay přijímá na druhé straně. Každý krok spotřebovává deskriptory a ten, který obvykle dojde, je poslední.

Začněte požadavkem, který umíte zopakovat, a změřte jeho čas. Pokud se TCP rukování dokončí, ale banner aplikace nepřijde, relay vzal socket a pak se zasekl v potomkovi nebo na své upstream noze. Pokud se samotné rukování nikdy nedokončí, příčinou je směrování, firewall nebo stav posluchače, ne strop deskriptorů. Zapište, který ze dvou tvarů jste pozorovali, protože ukazují na různé procesy.

Počítejte i skoky, které práci duplikují. Rozvětvující posluchač předává každý přijatý socket potomkovi, který si drží vlastní kopii, takže skutečný součet je vlastností celého stromu, ne jen rodiče.

Přečtěte limit, který relay zdědil

Jediný limit, na kterém záleží, patří běžícímu procesu a určilo ho to, co tento proces spustilo. Zadání ulimit -n v shellu popisuje shell. Zeptejte se správce služeb, co použil, a pak to potvrďte na PID.

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

Soubor limits vypisuje měkký a tvrdý strop tak, jak je vidí proces. Nízká měkká hodnota pod velkorysým tvrdým stropem znamená, že démon smí zvednout vlastní strop, a některé to dělají při startu; stejné nízké hodnoty znamenají, že zdrojem je unit soubor.

Drop-in soubory se načítají v lexikálním pořadí a pozdější vyhrávají, takže systemctl cat vpn-relay.service je autoritativní pohled na to, co platí. Úprava souboru, který správce nikdy nečte, je nejčastějším důvodem, proč zvýšené číslo nemá účinek.

Oddělte ustálenou souběžnost od zadrženého stavu

Dva procesy mohou narazit na stejný strop z nesouvisejících důvodů a nápravy se liší. Poptávka, která sleduje užitečné souběžné relace, je otázka kapacity. Růst, který pokračuje po skončení práce, je únik nebo sada relací, které nikdo nezavřel.

Měřte v klidu, na svém obvyklém vrcholu a znovu několik minut po zastavení zátěže. Počítání otevřených položek pomocí ls /proc/PID/fd | wc -l proti měkkému limitu vám řekne mezeru a počet jeden nebo dva pod stropem je tvrdé zastavení, ne pomalá cesta.

Když počet odmítá klesnout, dívejte se na stavy socketů, ne na součty. Deskriptory sedící v CLOSE_WAIT znamenají, že peer zavřel a vaše strana nikdy ne, což je vada životního cyklu aplikace, kterou větší limit jen odkládá. Omezte i model potomků: rozvětvující relay bez stropu souběžných potomků vyčerpává deskriptory, procesní sloty a paměť dohromady.

Ověřte novou hodnotu na živém procesu

Po úpravě unit souboru znovu načtěte správce a restartujte službu, protože samotné znovunačtení nikdy nenahradí limity, které běžící proces už zdědil. Ověřte to na procesu, který skutečně obsluhuje provoz.

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

Řádek awk vrací novou dvojici; pokud stále ukazuje starou, drop-in, který jste upravili, není ten, který se načítá. Počet ss je vaše kontrola zátěže, takže otevřete očekávaný počet relací a sledujte, jak stoupá. Počet, který po zavření těchto relací dál roste, znamená, že limit nikdy nebyl celý problém.

Ke každému velkému zvýšení patří jedna výhrada. Aplikace, které dotazují pomocí select(), nemohou sledovat deskriptory nad FD_SETSIZE, což je u typických sestavení 1024, takže strop zvednutý nad to může způsobovat selhání, která vypadají nesouvisele. Referenční příručka spouštění systemd nese stejné varování pro služby, které spouští.

Držte restart daleko od dostupnosti tunelu

Restart relayu zahodí jeho aktivní relace a to je oddělená událost od pádu VPN. Naplánujte změnu tak, aby tunel zůstal nahoru, zatímco relay prochází cyklem, a varujte každého, jehož dlouhá relace to protne.

Vrácení je předchozí unit soubor plus další restart a tento soubor zůstává na místě, dokud nová hodnota nepřežije pracovní den. Pak uzavřete smyčku požadavkem, který původně selhal: jedna nová relace SSH přes relay, jeden přenos dost dlouhý, aby měl význam, a počet deskriptorů, který se vrátí na svou klidovou úroveň.