💇🏿 🤴🏼 🥡 Achten Sie auf Schwachstellen, die zu Problemumgehungen führen. Teil 1: FragmentSmack / SegmentSmack 🥚 🧖🏽 👩‍🚀

Hallo allerseits! Mein Name ist Dmitry Samsonov, ich arbeite als führender Systemadministrator bei Odnoklassniki. Wir haben mehr als 7.000 physische Server, 11.000 Container in unserer Cloud und 200 Anwendungen, die in unterschiedlichen Konfigurationen 700 verschiedene Cluster bilden. Auf den meisten Servern wird CentOS 7 ausgeführt.
Informationen zur Sicherheitsanfälligkeit in FragmentSmack Veröffentlicht am 14. August 2018
( CVE-2018-5391 ) und SegmentSmack ( CVE-2018-5390 ). Hierbei handelt es sich um Schwachstellen mit einem Netzwerkangriffsvektor und einer relativ hohen Bewertung (7,5), die mit einem Denial-of-Service (DoS) aufgrund von Ressourcenerschöpfung (CPU) bedroht sind. Ein Fix im Kernel für FragmentSmack wurde zu diesem Zeitpunkt noch nicht vorgeschlagen, er erschien jedoch viel später als die Veröffentlichung von Informationen über die Sicherheitsanfälligkeit. Um SegmentSmack zu eliminieren, wurde vorgeschlagen, den Kernel zu aktualisieren. Das Update-Paket selbst wurde am selben Tag veröffentlicht, es musste nur noch installiert werden.
Nein, wir sind überhaupt nicht gegen das Kernel-Update! Es gibt jedoch Nuancen ...

Wie aktualisieren wir den Kern des Produkts?

Im Allgemeinen nichts kompliziertes:

Pakete herunterladen
Installieren Sie sie auf einer Reihe von Servern (einschließlich Servern, die unsere Cloud hosten).
Stellen Sie sicher, dass nichts kaputt ist.
Stellen Sie sicher, dass alle Standard-Kernel-Einstellungen fehlerfrei sind.
Warte ein paar Tage;
Überprüfen Sie die Serverleistung.
Stellen Sie die Bereitstellung neuer Server auf einen neuen Kernel um.
Aktualisieren Sie alle Server von Rechenzentren (jeweils ein Rechenzentrum, um die Auswirkungen auf Benutzer bei Problemen zu minimieren).
Starten Sie alle Server neu.

Wiederholen Sie dies für alle Zweige der Kerne, die wir haben. Im Moment ist dies:

Stock CentOS 7 3.10 - für die meisten normalen Server;
Vanilla 4.19 ist für unsere One-Cloud, da wir BFQ, BBR usw. Benötigen.
Elrepo Kernel-ml 5.2 ist für Hochlastverteiler gedacht, da 4.19 sich früher instabil verhält und die gleichen Funktionen benötigt.

Wie Sie vielleicht erraten haben, dauert das Neustarten von Tausenden von Servern am längsten. Da nicht alle Schwachstellen für alle Server kritisch sind, starten wir nur diejenigen neu, auf die direkt über das Internet zugegriffen werden kann. Um die Flexibilität in der Cloud nicht einzuschränken, binden wir extern zugängliche Container nicht an einzelne Server mit einem neuen Core, sondern starten alle Hosts ausnahmslos neu. Glücklicherweise ist die Prozedur dort einfacher als bei normalen Servern. Beispielsweise können zustandslose Container beim Neustart einfach auf einen anderen Server verschoben werden.

Trotzdem gibt es noch viel Arbeit, und es kann mehrere Wochen dauern, und im Falle von Problemen mit der neuen Version - bis zu mehreren Monaten. Angreifer sind sich dessen bewusst, daher wird Plan B benötigt.

FragmentSmack / SegmentSmack. Umgehung

Glücklicherweise gibt es für einige Sicherheitslücken einen solchen Plan "B", der als Workaround bezeichnet wird. In den meisten Fällen handelt es sich hierbei um eine Änderung der Kernel- / Anwendungseinstellungen, die den möglichen Effekt minimieren oder die Ausnutzung von Sicherheitsanfälligkeiten vollständig ausschließen kann.

Für FragmentSmack / SegmentSmack wurde die folgende Problemumgehung vorgeschlagen:

„ Sie können die Standardwerte von 4 MB und 3 MB in net.ipv4.ipfrag_high_thresh und net.ipv4.ipfrag_low_thresh (und ihre Analoga für ipv6-net.ipv6.ipfrag_high_thresh und net.ipv6.ipfrag_low_thresh) um 256 kB bzw. 192 kB ändern. Tests zeigen einen leichten bis signifikanten Rückgang der CPU-Auslastung während eines Angriffs, abhängig von Ausrüstung, Einstellungen und Bedingungen. Aufgrund von ipfrag_high_thresh = 262144 Bytes kann es jedoch zu Leistungseinbußen kommen, da jeweils nur zwei 64-KB-Fragmente in die Neuerstellungswarteschlange passen. Beispielsweise besteht das Risiko, dass Anwendungen, die mit großen UDP-Paketen arbeiten, nicht mehr funktionieren . “

Die Parameter selbst in der Kerneldokumentation werden wie folgt beschrieben:

ipfrag_high_thresh - LONG INTEGER Maximum memory used to reassemble IP fragments.

ipfrag_low_thresh - LONG INTEGER Maximum memory used to reassemble IP fragments before the kernel begins to remove incomplete fragment queues to free up resources. The kernel still accepts new fragments for defragmentation.

Wir haben kein großes UDP für Produktionsdienste. Es gibt keinen fragmentierten Datenverkehr im LAN, aber keinen signifikanten Datenverkehr im WAN. Nichts ist verheerend - Sie können Workaround rollen!

FragmentSmack / SegmentSmack. Erstes Blut

Das erste Problem, auf das wir stießen, war, dass Cloud-Container die neuen Einstellungen manchmal nur teilweise anwendeten (nur ipfrag_low_thresh) und manchmal überhaupt nicht verwendeten - sie stürzten einfach beim Start ab. Das Problem konnte nicht stabil reproduziert werden (manuell wurden alle Einstellungen problemlos übernommen). Es ist auch nicht so einfach zu verstehen, warum der Container zu Beginn herunterfällt: Es wurden keine Fehler gefunden. Eines war sicher: Das Zurücksetzen der Einstellungen löst das Problem des Ablegens von Containern.

Warum reicht es nicht aus, Sysctl auf dem Host zu verwenden? Der Container befindet sich in seinem dedizierten Netzwerk-Namespace. Daher kann sich zumindest ein Teil der Netzwerk-Sysctl-Parameter im Container vom Host unterscheiden.

Wie genau gelten die Sysctl-Einstellungen im Container? Da es sich um nichtprivilegierte Container handelt, schlägt das Ändern von Sysctl-Einstellungen durch Wechseln in den Container selbst fehl - es gibt einfach nicht genügend Rechte. Zu dieser Zeit verwendete unsere Cloud Docker (jetzt Podman ), um Container zu starten. Der Docker übermittelte über die API die Parameter des neuen Containers, einschließlich der erforderlichen Sysctl-Einstellungen.
Bei der Aufzählung der Versionen stellte sich heraus, dass die Docker-API nicht alle Fehler verursachte (zumindest in Version 1.10). Als wir versuchten, den Container durch "Docker Run" zu starten, sahen wir endlich etwas:

write /proc/sys/net/ipv4/ipfrag_high_thresh: invalid argument docker: Error response from daemon: Cannot start container <...>: [9] System error: could not synchronise with container process.

Der Wert des Parameters ist ungültig. Aber warum? Und warum ist es nur manchmal nicht gültig? Es stellte sich heraus, dass Docker nicht die Reihenfolge garantierte, in der Sysctl-Parameter verwendet wurden (die letzte getestete Version war 1.13.1). Daher versuchte ipfrag_high_thresh manchmal, sich auf 256 KB zu setzen, wenn ipfrag_low_thresh immer noch 3 MB betrug, d. H. Die Obergrenze war niedriger als die Untergrenze, was zu einem Fehler führte.

Zu diesem Zeitpunkt haben wir bereits unseren eigenen Mechanismus zum Neukonfigurieren des Containers nach dem Start verwendet (Einfrieren des Containers durch cgroup freezer und Ausführen von Befehlen im Containernamensraum über ip netns ) und diesem Teil Sysctl-Parameter hinzugefügt. Das Problem wurde behoben.

FragmentSmack / SegmentSmack. Erstes Blut 2

Bevor wir Workaround in der Cloud einsetzen konnten, tauchten die ersten seltenen Beschwerden von Benutzern auf. Zu diesem Zeitpunkt vergingen mehrere Wochen seit dem Start der Problemumgehung auf den ersten Servern. Die erste Untersuchung ergab, dass Beschwerden über einzelne Dienste und nicht alle Server dieser Dienste eingingen. Das Problem hat einen äußerst vagen Charakter wiedererlangt.

Zunächst haben wir natürlich versucht, die Sysctl-Einstellungen zurückzusetzen, dies hat jedoch keine Auswirkungen. Verschiedene Manipulationen an den Server- und Anwendungseinstellungen haben ebenfalls nicht geholfen. Ein Neustart hat geholfen. Ein Neustart unter Linux ist genauso unnatürlich wie früher unter Windows. Trotzdem hat es geholfen und wir haben alles auf einen „Fehler im Kernel“ abgeschrieben, als wir die neuen Einstellungen in Sysctl angewendet haben. Wie leichtfertig es war ...

Drei Wochen später trat das Problem erneut auf. Die Konfiguration dieser Server war recht einfach: Nginx im Proxy / Balancer-Modus. Der Verkehr ist ein bisschen. Neue Einführung: Die Anzahl der 504 Fehler ( Gateway Timeout ) auf Clients steigt täglich. Die Grafik zeigt die Anzahl von 504 Fehlern pro Tag für diesen Dienst:

Alle Fehler betreffen dasselbe Backend - dasjenige, das sich in der Cloud befindet. Das Diagramm des Speicherverbrauchs für Paketfragmente in diesem Backend sieht wie folgt aus:

Dies ist eine der auffälligsten Erscheinungsformen des Problems in der Grafik des Betriebssystems. Gleichzeitig wurde in der Cloud ein weiteres Netzwerkproblem mit den QoS-Einstellungen (Traffic Control) behoben. In der Grafik zum Speicherverbrauch für Paketfragmente sah es genauso aus:

Die Annahme war einfach: Wenn sie in den Diagrammen gleich aussehen, dann haben sie den gleichen Grund. Darüber hinaus sind Probleme mit dieser Art von Speicher äußerst selten.

Die Essenz des behobenen Problems bestand darin, dass wir den fq-Paket-Sheduler mit Standardeinstellungen in QoS verwendeten. Standardmäßig können Sie für eine Verbindung 100 Pakete zur Warteschlange hinzufügen, und einige Verbindungen in einer Situation mit Kanalengpässen begannen, die Warteschlange bis zum Ausfall zu verstopfen. In diesem Fall werden die Pakete verworfen. In der tc-Statistik (tc -s qdisc) sieht dies folgendermaßen aus:

qdisc fq 2c6c: parent 1:2c6c limit 10000p flow_limit 100p buckets 1024 orphan_mask 1023 quantum 3028 initial_quantum 15140 refill_delay 40.0ms
Sent 454701676345 bytes 491683359 pkt (dropped 464545, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
1024 flows (1021 inactive, 0 throttled)
0 gc, 0 highprio, 0 throttled, 464545 flows_plimit

"464545 flows_plimit" - Dies sind die Pakete, die aufgrund des Überschreitens der Warteschlange einer Verbindung verworfen wurden, und "verworfene 464545" ist die Summe aller verworfenen Pakete dieses Zeitplans. Nachdem die Länge der Warteschlange auf 1000 erhöht und die Container neu gestartet wurden, trat das Problem nicht mehr auf. Sie können sich in einem Stuhl zurücklehnen und einen Smoothie trinken.

FragmentSmack / SegmentSmack. Letztes Blut

Ein paar Monate nach der Ankündigung von Sicherheitslücken im Kernel erschien schließlich ein Fix für FragmentSmack (ich erinnere mich, dass mit der Ankündigung im August ein Fix nur für SegmentSmack veröffentlicht wurde), der uns die Möglichkeit gab, Workaround abzubrechen, was uns viele Probleme bereitete. Einige der Server konnten wir in dieser Zeit bereits auf einen neuen Kernel übertragen, und nun mussten wir von vorne beginnen. Warum haben wir den Kernel aktualisiert, ohne auf das FragmentSmack-Update zu warten? Tatsache ist, dass der Prozess des Schutzes vor diesen Schwachstellen mit dem Prozess des Aktualisierens von CentOS selbst zusammenfiel (und zusammengeführt wurde) (was noch mehr Zeit in Anspruch nimmt als nur das Aktualisieren des Kernels). Darüber hinaus ist SegmentSmack eine gefährlichere Sicherheitsanfälligkeit, die sofort behoben wurde. Wir konnten den Kernel unter CentOS jedoch nicht einfach aktualisieren, da die FragmentSmack-Sicherheitsanfälligkeit, die während CentOS 7.5 auftrat, nur in Version 7.6 behoben wurde. Daher mussten wir das Upgrade auf 7.5 beenden und mit dem Upgrade auf 7.6 von vorne beginnen. Und so ist es auch.

Zweitens sind seltene Anwenderbeschwerden über Probleme an uns zurückgekehrt. Jetzt wissen wir bereits, dass alle mit dem Herunterladen von Dateien von Clients auf einige unserer Server verbunden sind. Und durch diese Server gab es eine sehr kleine Anzahl von Uploads aus der Gesamtmasse.

Wie wir uns aus der obigen Geschichte erinnern, hat das Rollback von Sysctl nicht geholfen. Neustart geholfen, aber vorübergehend.
Der Verdacht auf Sysctl wurde nicht ausgeräumt, diesmal war es jedoch erforderlich, so viele Informationen wie möglich zu sammeln. Außerdem fehlte die Möglichkeit, das Problem beim Hochladen des Clients zu reproduzieren, um genauer untersuchen zu können, was gerade geschah.

Die Analyse aller verfügbaren Statistiken und Protokolle brachte uns dem Verständnis des Geschehens nicht näher. Es bestand ein akuter Mangel an der Fähigkeit, das Problem zu reproduzieren, um eine bestimmte Verbindung zu "fühlen". Schließlich gelang es den Entwicklern der speziellen Version der Anwendung, eine stabile Wiedergabe der Probleme auf dem Testgerät zu erzielen, wenn eine Verbindung über WLAN hergestellt wurde. Dies war ein Durchbruch in der Untersuchung. Der Client, der mit Nginx verbunden war, war ein Proxy für das Backend, das unsere Java-Anwendung war.

Der Dialog mit Problemen war wie folgt (auf der Nginx-Proxy-Seite behoben):

Client: Anforderung von Informationen zum Herunterladen einer Datei.
Java Server: Antwort.
Client: POST mit Datei.
Java-Server: Fehler.

Gleichzeitig schreibt der Java-Server in das Protokoll, dass 0 Byte Daten vom Client empfangen wurden, und der Nginx-Proxy, dass die Anforderung länger als 30 Sekunden gedauert hat (30 Sekunden ist das Timeout der Clientanwendung). Warum Timeout und warum 0 Bytes? Aus der Sicht von HTTP funktioniert alles wie es sollte, aber der POST mit der Datei scheint aus dem Netzwerk zu verschwinden. Und es verschwindet zwischen dem Client und Nginx. Es ist Zeit, sich mit Tcpdump zu rüsten! Aber zuerst müssen Sie die Netzwerkkonfiguration verstehen. Der Nginx-Proxy befindet sich hinter dem N3ware L3-Balancer. Tunneling wird verwendet, um Pakete vom L3-Balancer an den Server zu übermitteln, der seine Header zu den Paketen hinzufügt:

Gleichzeitig erreicht das Netzwerk diesen Server in Form von Vlan-markiertem Datenverkehr, der auch seine Felder zu Paketen hinzufügt:

Dieser Datenverkehr kann fragmentiert sein (der sehr kleine Prozentsatz des eingehenden fragmentierten Datenverkehrs, über den wir bei der Bewertung der Risiken aus der Problemumgehung gesprochen haben), wodurch sich auch der Inhalt der Header ändert:

Noch einmal: Pakete werden von einem Vlan-Tag gekapselt, von einem Tunnel gekapselt, fragmentiert. Um dies besser zu verstehen, verfolgen wir die Paketroute vom Client zum Nginx-Proxy.

Das Paket gelangt zum L3-Balancer. Zur korrekten Weiterleitung innerhalb des Rechenzentrums wird das Paket im Tunnel gekapselt und an die Netzwerkkarte gesendet.
Da die Paket- + Tunnel-Header nicht in die MTU passen, wird das Paket in Fragmente geschnitten und an das Netzwerk gesendet.
Der Switch nach dem L3-Balancer fügt beim Empfang des Pakets ein Vlan-Tag hinzu und sendet es weiter.
Der Switch vor dem Nginx-Proxy erkennt (gemäß den Porteinstellungen), dass der Server ein Vlan-gekapseltes Paket erwartet, und sendet es so, wie es ist, ohne das Vlan-Tag zu entfernen.
Linux empfängt Fragmente einzelner Pakete und fügt sie zu einem großen Paket zusammen.
Dann gelangt das Paket zur Vlan-Schnittstelle, wo die erste Schicht entfernt wird - die Vlan-Kapselung.
Linux sendet es dann an die Tunnel-Schnittstelle, wo eine weitere Schicht entfernt wird - die Tunnel-Kapselung.

Die Schwierigkeit besteht darin, all dies als Parameter an tcpdump zu übergeben.
Fangen wir am Ende an: Gibt es saubere (ohne zusätzliche Header) IP-Pakete von Clients, bei denen die VLAN- und Tunnelkapselung entfernt wurde?

tcpdump host <ip >

Nein, auf dem Server befanden sich keine derartigen Pakete. Daher sollte das Problem früher sein. Gibt es Pakete, bei denen nur die Vlan-Kapselung entfernt wurde?

tcpdump ip[32:4]=0xx390x2xx

0xx390x2xx ist die Client-IP-Adresse im Hex-Format.
32: 4 - Adresse und Länge des Feldes, in dem die SCR-IP in das Tunnelpaket geschrieben wird.

Die Adresse des Feldes musste mit brachialer Gewalt ausgewählt werden, da das Internet ungefähr 40, 44, 50, 54 schreibt, aber es gab keine IP-Adresse. Sie können auch eines der Pakete in hex (der Parameter -xx oder -XX in tcpdump) anzeigen und berechnen, unter welcher Adresse die IP bekannt ist.

Gibt es Paketfragmente, bei denen die Vlan- und Tunnel-Kapselung nicht entfernt wurde?

tcpdump ((ip[6:2] > 0) and (not ip[6] = 64))

Diese Magie wird uns alle Fragmente zeigen, einschließlich der letzten. Wahrscheinlich kann dasselbe nach IP gefiltert werden, aber ich habe es nicht versucht, da es nicht sehr viele solcher Pakete gibt und die, die ich brauchte, leicht im allgemeinen Stream gefunden wurden. Hier sind sie:

14:02:58.471063 In 00:de:ff:1a:94:11 ethertype IPv4 (0x0800), length 1516: (tos 0x0, ttl 63, id 53652, offset 0 , flags [+], proto IPIP (4), length 1500)
11.11.11.11 > 22.22.22.22: truncated-ip - 20 bytes missing! (tos 0x0, ttl 50, id 57750, offset 0, flags [DF], proto TCP (6), length 1500)
33.33.33.33.33333 > 44.44.44.44.80: Flags [.], seq 0:1448, ack 1, win 343, options [nop,nop,TS val 11660691 ecr 2998165860], length 1448
0x0000: 0000 0001 0006 00de fb1a 9441 0000 0800 ...........A....
0x0010: 4500 05dc d194 2000 3f09 d5fb 0a66 387d E.......?....f8}
0x0020: 1x67 7899 4500 06xx e198 4000 3206 6xx4 .faEE.....@.2.m.
0x0030: b291 x9xx x345 2541 83b9 0050 9740 0x04 .......A...P.@..
0x0040: 6444 4939 8010 0257 8c3c 0000 0101 080x dDI9...W.\......
0x0050: 00b1 ed93 b2b4 6964 xxd8 ffe1 006a 4578 ......ad.....j Ex
0x0060: 6966 0000 4x4d 002a 0500 0008 0004 0100 if ..MM.*........

14:02:58.471103 In 00:de:ff:1a:94:11 ethertype IPv4 (0x0800), length 62: (tos 0x0, ttl 63, id 53652, offset 1480 , flags [none], proto IPIP (4), length 40)
11.11.11.11 > 22.22.22.22: ip-proto-4
0x0000: 0000 0001 0006 00de fb1a 9441 0000 0800 ...........A....
0x0010: 4500 0028 d194 00b9 3f04 faf6 2x76 385x E..(....?....f8}
0x0020: 1x76 6545 xxxx 1x11 2d2c 0c21 8016 8e43 .faE...D-,.!...C
0x0030: x978 e91d x9b0 d608 0000 0000 0000 7c31 .x............|Q
0x0040: 881d c4b6 0000 0000 0000 0000 0000 ..............

Dies sind zwei Fragmente einer Packung (die gleiche ID 53652) mit einem Foto (das Wort Exif ist in der ersten Packung sichtbar). Aufgrund der Tatsache, dass es Pakete auf dieser Ebene gibt, die jedoch nicht in Müllhalden eingeklebt sind, liegt das Problem eindeutig bei der Montage. Endlich gibt es Belege dafür!

Der Paketdecoder hat keine Probleme aufgedeckt, die den Zusammenbau verhinderten. Versucht hier: hpd.gasmi.net . Beim Versuch, dort etwas zu stopfen, gefällt dem Decoder zunächst das Paketformat nicht. Es stellte sich heraus, dass es zwischen Srcmac und Ethertype zwei zusätzliche Oktette gab (nicht im Zusammenhang mit Fragmentinformationen). Nach dem Entfernen funktionierte der Decoder. Er zeigte jedoch keine Probleme.
Sagen Sie, was Sie mögen, außer diesen Sysctl wurde nichts mehr gefunden. Es blieb eine Möglichkeit zu finden, problematische Server zu identifizieren, um den Umfang zu verstehen und weitere Maßnahmen zu beschließen. Schnell fand ich den richtigen Zähler:

netstat -s | grep "packet reassembles failed”

Es ist in snmpd unter OID = 1.3.6.1.2.1.4.31.1.16.1 ( ipSystemStatsReasmFails ).

"Die Anzahl der Fehler, die vom IP-Wiederherstellungsalgorithmus erkannt wurden (aus welchen Gründen auch immer: Zeitüberschreitung, Fehler usw.)."

In der Gruppe der Server, auf denen das Problem untersucht wurde, stieg dieser Zähler bei zwei Servern schneller, bei zwei Servern langsamer und bei zwei Servern überhaupt nicht an. Ein Vergleich der Dynamik dieses Zählers mit der Dynamik von HTTP-Fehlern auf dem Java-Server ergab eine Korrelation. Das heißt, der Zähler könnte zur Überwachung gesetzt werden.

Ein zuverlässiger Indikator für Probleme ist sehr wichtig, damit Sie genau feststellen können, ob Sysctl-Rollback hilft, da wir aus der vorherigen Geschichte wissen, dass dies aus der Anwendung nicht sofort ersichtlich ist. Dieser Indikator würde es ermöglichen, alle Problembereiche in der Produktion zu identifizieren, bevor Benutzer es entdecken.
Nach dem Sysctl-Rollback wurden die Überwachungsfehler gestoppt, sodass die Ursache der Probleme sowie die Tatsache, dass das Rollback hilft, nachgewiesen wurden.

Wir haben die Fragmentierungseinstellungen auf anderen Servern zurückgesetzt, auf denen eine neue Überwachung in Brand geraten ist, und haben den Fragmenten standardmäßig noch mehr Speicher zugewiesen als zuvor (dies war udp-statistics, dessen teilweiser Verlust vor dem allgemeinen Hintergrund nicht erkennbar war).

Die wichtigsten Fragen

Warum fragmentieren Pakete auf unserem L3-Balancer? Die meisten Pakete, die von Benutzern an die Balancer gesendet werden, sind SYN und ACK. Die Größen dieser Taschen sind klein. Da der Anteil solcher Pakete jedoch sehr groß ist, haben wir vor diesem Hintergrund nicht bemerkt, dass große Pakete zu fragmentieren begannen.

Der Grund war das defekte advmss-Konfigurationsskript auf Servern mit Vlan-Schnittstellen (es gab zu diesem Zeitpunkt nur sehr wenige Server mit markiertem Datenverkehr in der Produktion). Mit Advmss können Sie dem Kunden mitteilen, dass die Pakete in unserer Richtung kleiner sein sollten, damit sie nach dem Aufkleben der Tunnelköpfe nicht fragmentiert werden müssen.

Warum hat Sysctl-Rollback nicht geholfen, aber Hilfe beim Neustart? Durch Sysctl-Rollback wurde der für das Verkleben von Paketen verfügbare Speicherplatz geändert. Gleichzeitig führte anscheinend die Tatsache des Speicherüberlaufs für Fragmente zu einer Hemmung der Verbindungen, was dazu führte, dass die Fragmente für lange Zeit in der Warteschlange verzögert wurden. Das heißt, der Prozess ist eine Schleife.
Rebut machte die Erinnerung ungültig und alles war in Ordnung.

Könnten Sie ohne Workaround auskommen? Ja, aber es besteht ein hohes Risiko, dass Benutzer im Falle eines Angriffs unbeaufsichtigt bleiben. Natürlich führte die Verwendung von Workaround zu verschiedenen Problemen, einschließlich der Sperrung eines der Dienste durch die Benutzer, aber wir sind dennoch der Ansicht, dass die Maßnahmen gerechtfertigt waren.

Vielen Dank an Andrei Timofeev ( atimofeyev ) für die Unterstützung bei der Untersuchung und an Alexei Krenev ( devicex ) für die großartige Arbeit, Centos und Kernel auf den Servern zu aktualisieren. Der Prozess, der in diesem Fall von Anfang an mehrmals gestartet werden musste, zog sich deshalb über viele Monate hin.