VPN-relay accepteert geen SSH meer: limieten voor bestandsdescriptors

Een WireGuard-handshake wordt nog steeds voltooid, de peer toont nog steeds een recent endpoint, en toch blijft een nieuwe SSH-sessie via de relay erachter hangen zonder banner. Die combinatie wijst weg van de tunnel en naar het proces dat de socket accepteert. Een relay zoals socat zit in het applicatiepad met zijn eigen descriptor-budget, zijn eigen kinderen en zijn eigen geërfde limieten. De tocht hieronder begint bij de client en stopt bij de eerste component die geen socket meer kan openen.

Volg het pad voordat u een getal wijzigt

Volg één mislukt verzoek in plaats van over de tunnel als geheel te redeneren. De client schrijft in de tunnel, de VPN-daemon ontsleutelt en routeert, en de relay accepteert aan de andere kant. Elke stap verbruikt descriptors, en degene die meestal opraakt is de laatste.

Begin met een verzoek dat u kunt reproduceren en meet de tijd. Als de TCP-handshake voltooit maar er geen applicatiebanner komt, heeft de relay de socket aangenomen en is daarna vastgelopen in een kind of op zijn upstream-been. Als de handshake zelf nooit voltooit, is de oorzaak routing, firewall of luisteraarstatus, niet een descriptorplafond. Noteer welke van de twee vormen u zag, want ze wijzen op verschillende processen.

Tel ook de sprongen die werk dupliceren. Een forkende luisteraar geeft elke geaccepteerde socket aan een kind dat zijn eigen kopie houdt, dus het werkelijke totaal is een eigenschap van de hele boom, niet alleen van de ouder.

Lees de limiet die de relay heeft geërfd

De enige limiet die ertoe doet, hoort bij het draaiende proces, en is vastgesteld door wat dat proces heeft gestart. ulimit -n in een shell typen beschrijft de shell. Vraag de servicemanager wat die heeft toegepast en bevestig het daarna op de PID.

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

Het bestand limits drukt de zachte en harde plafonds af zoals het proces ze ziet. Een lage zachte waarde onder een ruime harde waarde betekent dat de daemon zijn eigen plafond mag verhogen, en sommige doen dat bij het opstarten; gelijke lage waarden betekenen dat het unit-bestand de bron is.

Drop-ins worden in lexicografische volgorde geladen en latere bestanden winnen, dus systemctl cat vpn-relay.service is de gezaghebbende weergave van wat van toepassing is. Een bestand bewerken dat de manager nooit leest, is de meest voorkomende reden dat een verhoogd getal geen effect heeft.

Scheid stabiele gelijktijdigheid van vastgehouden toestand

Twee processen kunnen om ongerelateerde redenen hetzelfde plafond raken, en de remedies verschillen. Vraag die nuttige gelijktijdige sessies volgt is een capaciteitsvraagstuk. Groei die doorgaat nadat het werk stopt, is een lek of een set sessies die niemand heeft gesloten.

Meet in rust, op uw normale piek en nog eens een paar minuten nadat de belasting stopt. Open vermeldingen tellen met ls /proc/PID/fd | wc -l tegen de zachte limiet vertelt u de kloof, en een aantal een of twee onder het plafond is een harde stop, geen traag pad.

Wanneer het aantal weigert te dalen, kijk dan naar socketstatussen in plaats van totalen. Descriptors die in CLOSE_WAIT zitten, betekenen dat de peer sloot en uw kant nooit, wat een defect in de levenscyclus van de applicatie is dat een grotere limiet alleen uitstelt. Begrens ook het kindmodel: een forkende relay zonder limiet op gelijktijdige kinderen put descriptors, procesplekken en geheugen samen uit.

Controleer de nieuwe waarde op het levende proces

Na het bewerken van de unit laadt u de manager opnieuw en herstart u de service, want een herlaadbeurt alleen vervangt nooit limieten die een draaiend proces al heeft geërfd. Controleer op het proces dat daadwerkelijk verkeer bedient.

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

De regel awk geeft het nieuwe paar terug; als er nog steeds het oude staat, is de drop-in die u hebt bewerkt niet degene die wordt geladen. Het aantal van ss is uw belastingscontrole, dus open het aantal sessies dat u verwacht en kijk hoe het stijgt. Een aantal dat blijft stijgen nadat die sessies sluiten, betekent dat de limiet nooit het hele probleem was.

Eén voorbehoud hoort bij elke grote verhoging. Applicaties die met select() pollen, kunnen geen descriptors boven FD_SETSIZE volgen, wat 1024 is op typische builds, dus een plafond dat daarboven is verhoogd kan fouten veroorzaken die ongerelateerd lijken. De systemd-uitvoeringsreferentie draagt dezelfde waarschuwing voor de services die zij start.

Houd de herstart weg van tunnelbeschikbaarheid

Het herstarten van de relay laat zijn actieve sessies vallen, en dat is een aparte gebeurtenis van de VPN die uitvalt. Orden de wijziging zo dat de tunnel blijft staan terwijl de relay cyclet, en waarschuw iedereen wiens langdurige sessie die doorkruist.

Terugdraaien is het vorige unit-bestand plus nog een herstart, en dat bestand blijft op zijn plaats tot de nieuwe waarde een werkdag heeft overleefd. Sluit dan de lus met het verzoek dat oorspronkelijk mislukte: één nieuwe SSH-sessie via de relay, één overdracht lang genoeg om ertoe te doen, en een descriptor-aantal dat terugkeert naar zijn rustniveau.