VPN-Relay nimmt kein SSH mehr an: Grenzen für Dateideskriptoren

Ein WireGuard-Handshake wird weiterhin abgeschlossen, der Peer zeigt weiterhin einen aktuellen Endpunkt, und doch hängt eine neue SSH-Sitzung über das Relay dahinter ohne Banner. Diese Kombination weist weg vom Tunnel und hin zu dem Prozess, der den Socket annimmt. Ein Relay wie socat sitzt im Anwendungspfad mit eigenem Deskriptor-Budget, eigenen Kindern und eigenen geerbten Grenzen. Der Rundgang unten beginnt beim Client und endet bei der ersten Komponente, die keinen weiteren Socket öffnen kann.

Verfolgen Sie den Pfad, bevor Sie eine Zahl ändern

Verfolgen Sie eine fehlgeschlagene Anfrage, statt über den Tunnel als Ganzes zu räsonieren. Der Client schreibt in den Tunnel, der VPN-Daemon entschlüsselt und routet, und das Relay nimmt auf der anderen Seite an. Jeder Schritt verbraucht Deskriptoren, und derjenige, der üblicherweise ausgeht, ist der letzte.

Beginnen Sie mit einer Anfrage, die Sie reproduzieren können, und messen Sie deren Zeit. Wenn der TCP-Handshake abgeschlossen wird, aber kein Anwendungsbanner ankommt, hat das Relay den Socket angenommen und ist dann in einem Kind oder auf seinem Upstream-Bein hängen geblieben. Wenn der Handshake selbst nie abgeschlossen wird, ist die Ursache Routing, Firewall oder Listener-Zustand und nicht eine Deskriptor-Obergrenze. Notieren Sie, welche der beiden Formen Sie beobachtet haben, denn sie deuten auf unterschiedliche Prozesse.

Zählen Sie auch die Sprünge, die Arbeit duplizieren. Ein forking Listener übergibt jeden angenommenen Socket an ein Kind, das seine eigene Kopie behält, sodass die reale Summe eine Eigenschaft des gesamten Baums ist, nicht nur des Elternprozesses.

Lesen Sie die Grenze, die das Relay geerbt hat

Die einzige Grenze, die zählt, gehört dem laufenden Prozess, und sie wurde von dem festgelegt, was diesen Prozess gestartet hat. ulimit -n in einer Shell zu tippen beschreibt die Shell. Fragen Sie den Dienstmanager, was er angewendet hat, und bestätigen Sie es dann am PID.

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

Die Datei limits druckt die weiche und die harte Obergrenze so, wie der Prozess sie sieht. Ein niedriger weicher Wert unter einer großzügigen harten Grenze bedeutet, dass der Daemon seine eigene Obergrenze anheben darf, und manche tun das beim Start; gleiche niedrige Werte bedeuten, dass die Unit-Datei die Quelle ist.

Drop-ins werden in lexikalischer Reihenfolge geladen, und spätere Dateien gewinnen, daher ist systemctl cat vpn-relay.service die maßgebliche Sicht auf das, was gilt. Eine Datei zu bearbeiten, die der Manager nie liest, ist der häufigste Grund, warum eine erhöhte Zahl keine Wirkung hat.

Trennen Sie stetige Parallelität vom gehaltenen Zustand

Zwei Prozesse können aus unabhängigen Gründen dieselbe Obergrenze erreichen, und die Abhilfen unterscheiden sich. Nachfrage, die nützlichen parallelen Sitzungen folgt, ist eine Kapazitätsfrage. Wachstum, das nach dem Ende der Arbeit anhält, ist ein Leck oder eine Menge von Sitzungen, die niemand geschlossen hat.

Messen Sie im Leerlauf, bei Ihrer normalen Spitze und noch einmal einige Minuten nach dem Ende der Last. Das Zählen offener Einträge mit ls /proc/PID/fd | wc -l gegen das weiche Limit zeigt Ihnen die Lücke, und ein Wert ein oder zwei unter der Obergrenze ist ein harter Stopp und kein langsamer Pfad.

Wenn die Zahl nicht sinken will, schauen Sie auf Socket-Zustände statt auf Summen. Deskriptoren in CLOSE_WAIT bedeuten, dass der Peer geschlossen hat und Ihre Seite nie, was ein Defekt im Anwendungslebenszyklus ist, den eine größere Grenze nur aufschiebt. Begrenzen Sie auch das Kindmodell: Ein forking Relay ohne Obergrenze für parallele Kinder erschöpft Deskriptoren, Prozessslots und Speicher gemeinsam.

Prüfen Sie den neuen Wert am laufenden Prozess

Nach dem Bearbeiten der Unit laden Sie den Manager neu und starten den Dienst neu, denn ein Neuladen allein ersetzt nie Grenzen, die ein laufender Prozess bereits geerbt hat. Prüfen Sie an dem Prozess, der tatsächlich Verkehr 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

Die Zeile awk liefert das neue Paar; zeigt sie noch das alte, ist das Drop-in, das Sie bearbeitet haben, nicht das geladene. Der ss-Zähler ist Ihre Lastprüfung, also öffnen Sie die erwartete Zahl von Sitzungen und beobachten Sie, wie er steigt. Eine Zahl, die nach dem Schließen dieser Sitzungen weiter steigt, bedeutet, dass die Grenze nie das ganze Problem war.

Eine Einschränkung gehört zu jeder großen Erhöhung. Anwendungen, die mit select() abfragen, können keine Deskriptoren über FD_SETSIZE beobachten, das bei typischen Builds 1024 ist, sodass eine darüber hinaus angehobene Obergrenze Fehler erzeugen kann, die unzusammenhängend wirken. Die systemd-Ausführungsreferenz trägt dieselbe Warnung für Dienste, die sie startet.

Halten Sie den Neustart von der Tunnelverfügbarkeit fern

Ein Neustart des Relays verwirft seine aktiven Sitzungen, und das ist ein separates Ereignis vom Ausfall des VPN. Ordnen Sie die Änderung so, dass der Tunnel oben bleibt, während das Relay durchläuft, und warnen Sie jeden, dessen langlebige Sitzung sie kreuzt.

Der Rückweg ist die vorherige Unit-Datei plus ein weiterer Neustart, und diese Datei bleibt an Ort und Stelle, bis der neue Wert einen Arbeitstag überlebt hat. Dann schließen Sie den Kreis mit der ursprünglich fehlgeschlagenen Anfrage: eine neue SSH-Sitzung durch das Relay, eine Übertragung, die lange genug ist, um zu zählen, und ein Deskriptorzähler, der auf sein Leerlaufniveau zurückkehrt.