Il relay VPN smette di accettare SSH: limiti dei descrittori di file

Un handshake WireGuard si completa ancora, il peer mostra ancora un endpoint recente, eppure una nuova sessione SSH attraverso il relay dietro di esso resta appesa senza banner. Questa combinazione allontana dal tunnel e punta al processo che accetta il socket. Un relay come socat si trova nel percorso dell’applicazione con il proprio budget di descrittori, i propri figli e i propri limiti ereditati. Il percorso qui sotto inizia dal client e si ferma al primo componente che non può aprire un altro socket.

Seguite il percorso prima di cambiare un numero

Seguite una singola richiesta fallita invece di ragionare sul tunnel nel suo insieme. Il client scrive nel tunnel, il demone VPN decifra e instrada, e il relay accetta dall’altro lato. Ogni passo consuma descrittori, e quello che di solito si esaurisce è l’ultimo.

Iniziate da una richiesta che potete riprodurre e misuratene il tempo. Se l’handshake TCP si completa ma non arriva alcun banner dell’applicazione, il relay ha preso il socket e poi si è bloccato in un figlio o sulla sua gamba upstream. Se l’handshake stesso non si completa mai, la causa è l’instradamento, il firewall o lo stato dell’ascoltatore, non un tetto di descrittori. Annotate quale delle due forme avete osservato, perché puntano a processi diversi.

Contate anche i salti che duplicano il lavoro. Un ascoltatore che si sdoppia consegna ogni socket accettato a un figlio che ne conserva la propria copia, quindi il totale reale è una proprietà dell’intero albero, non solo del genitore.

Leggete il limite che il relay ha ereditato

L’unico limite che conta appartiene al processo in esecuzione, ed è stato fissato da ciò che ha avviato quel processo. Digitare ulimit -n in una shell descrive la shell. Chiedete al gestore dei servizi cosa ha applicato, poi confermate sul PID.

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

Il file limits stampa i tetti soft e hard come li vede il processo. Un valore soft basso sotto un valore hard generoso significa che al demone è consentito alzare il proprio tetto, e alcuni lo fanno all’avvio; valori soft uguali e bassi significano che il file unit è la fonte.

I drop-in vengono caricati in ordine lessicografico e i file successivi vincono, quindi systemctl cat vpn-relay.service è la vista autorevole di ciò che si applica. Modificare un file che il gestore non legge mai è la ragione più comune per cui un numero alzato non ha effetto.

Separate la concorrenza stabile dallo stato trattenuto

Due processi possono colpire lo stesso tetto per motivi non correlati, e i rimedi differiscono. La domanda che segue sessioni concorrenti utili è una questione di capacità. La crescita che continua dopo la fine del lavoro è una perdita o un insieme di sessioni che nessuno ha chiuso.

Misurate a riposo, al vostro picco normale e di nuovo qualche minuto dopo che il carico si ferma. Contare le voci aperte con ls /proc/PID/fd | wc -l rispetto al limite soft vi dice lo scarto, e un conteggio uno o due sotto il tetto è un arresto netto, non un percorso lento.

Quando il conteggio si rifiuta di scendere, guardate gli stati dei socket invece dei totali. I descrittori fermi in CLOSE_WAIT significano che il peer ha chiuso e il vostro lato non l’ha mai fatto, il che è un difetto del ciclo di vita dell’applicazione che un limite maggiore si limita a rinviare. Limitate anche il modello dei figli: un relay che si sdoppia senza tetto sui figli concorrenti esaurisce descrittori, slot di processo e memoria insieme.

Verificate il nuovo valore sul processo vivo

Dopo aver modificato l’unità, ricaricate il gestore e riavviate il servizio, poiché un ricaricamento da solo non sostituisce mai i limiti già ereditati da un processo in esecuzione. Verificate sul processo che serve davvero il traffico.

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 riga awk restituisce la nuova coppia; se mostra ancora quella vecchia, il drop-in che avete modificato non è quello caricato. Il conteggio di ss è il vostro controllo del carico, quindi aprite il numero di sessioni che vi aspettate e guardatelo salire. Un conteggio che continua a salire dopo la chiusura di quelle sessioni significa che il limite non è mai stato tutto il problema.

Un’avvertenza accompagna ogni forte aumento. Le applicazioni che interrogano con select() non possono sorvegliare descrittori oltre FD_SETSIZE, che vale 1024 nelle build tipiche, quindi un tetto alzato oltre quel valore può produrre errori che sembrano non correlati. La referenza di esecuzione di systemd porta lo stesso avviso per i servizi che avvia.

Tenete il riavvio lontano dalla disponibilità del tunnel

Riavviare il relay fa cadere le sue sessioni attive, e questo è un evento separato dalla caduta della VPN. Ordinate il cambiamento in modo che il tunnel resti su mentre il relay fa il suo ciclo, e avvisate chiunque abbia una sessione lunga che lo attraversa.

Il rollback è il file unit precedente più un altro riavvio, e quel file resta al suo posto finché il nuovo valore non ha superato una giornata lavorativa. Poi chiudete il cerchio con la richiesta che era fallita in origine: una nuova sessione SSH attraverso il relay, un trasferimento abbastanza lungo da contare e un conteggio di descrittori che torna al suo livello di riposo.