Erster Schritt: Bereiten Sie Ihr Tor Relay darauf vor, eine große Anzahl von Verbindungen zu verarbeiten.

Erster Schritt: Bereiten Sie Ihr Tor Relay darauf vor, eine große Anzahl von Verbindungen zu verarbeiten.

Es gibt einige Optimierungen, die Sie vornehmen können, damit Ihr Tor Relay die Ressourcen effizienter nutzt. Diese und viele andere Methoden werden bei Webservern eingesetzt, die mit sehr hohen Lasten zu kämpfen haben.

Neben den Grundeinstellungen zur CPU-, Speicher- und Swapfile-Optimierung habe ich hier die Optimierten Netzwerk-Stack-Einstellungen aufgelistet.

Wie immer beachten Sie bitte: Einige dieser Optionen könnten bereits in Ihrer sysctl.conf enthalten sein. Bitte editieren Sie diese, ohne sie zu duplizieren.

Hier die Einstellungen:

net.ipv4.tcp_fin_timeout = 20
net.ipv4.tcp_keepalive_time = 1200
net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_tw_reuse = 1
net.ipv4.ip_local_port_range = 10000 65000
net.ipv4.tcp_max_syn_backlog = 8192
net.ipv4.tcp_max_tw_buckets = 5000

Der Standardwert für die net.ipv4.tcp_fin_timeout-Einstellung auf einem Debian Linux-System beträgt in der Regel 60 Sekunden. Dieser Wert gibt an, wie lange das System nach dem Schließen einer TCP-Verbindung im FIN-WAIT-2-Zustand verbleibt, bevor die Verbindung endgültig geschlossen wird.

Die Einstellung net.ipv4.tcp_fin_timeout auf einem Debian-System legt die Zeit (in Sekunden) fest, wie lange das System nach dem Senden eines FIN-Pakets im FIN-WAIT-2-Zustand verbleibt, bevor die Verbindung endgültig geschlossen wird. Der FIN-WAIT-2-Zustand tritt ein, wenn eine TCP-Verbindung von einer Seite geschlossen wird und die andere Seite noch nicht auf die FIN-Nachricht reagiert hat.
Auswirkungen der Einstellung net.ipv4.tcp_fin_timeout = 20:

Schnellere Freigabe von Ressourcen:
Die Reduzierung des tcp_fin_timeout-Wertes auf 20 Sekunden bedeutet, dass die Systemressourcen, die von der TCP-Verbindung verwendet werden (z.B. Speicher für Verbindungsstatusinformationen), schneller freigegeben werden, nachdem die Verbindung geschlossen wurde.

Reduzierte Anzahl an offenen Verbindungen:
Dadurch wird die Anzahl der Verbindungen, die sich im FIN-WAIT-2-Zustand befinden, verringert. Dies kann insbesondere auf Systemen mit vielen kurzen TCP-Verbindungen hilfreich sein, um die Anzahl der offenen Verbindungen zu begrenzen.

Mögliche Verbindungsprobleme:
Wenn eine Gegenstelle länger als 20 Sekunden benötigt, um auf das FIN-Paket zu reagieren, könnte die Verbindung unerwartet geschlossen werden. Dies kann zu Problemen führen, wenn Anwendungen auf der Gegenstelle diese zusätzliche Zeit benötigen, um sauber zu schließen.

Sicherheitsaspekte:
Ein kürzerer tcp_fin_timeout-Wert kann die Wahrscheinlichkeit von Denial-of-Service-Angriffen (DoS) verringern, bei denen eine große Anzahl von halbgeschlossenen Verbindungen absichtlich offen gehalten wird, um die Ressourcen des Servers zu erschöpfen.

Der Standardwert für die Einstellung net.ipv4.tcp_keepalive_time auf einem Debian Linux-System beträgt in der Regel 7200 Sekunden, was 2 Stunden entspricht. Dieser Wert gibt an, wie lange ein System in einer inaktiven TCP-Verbindung wartet, bevor es das erste Keepalive-Paket sendet, um zu überprüfen, ob die Verbindung noch aktiv ist.

Die Einstellung net.ipv4.tcp_keepalive_time = 1200 auf einem Debian-System legt fest, dass das System nach 1200 Sekunden (20 Minuten) Inaktivität ein Keepalive-Paket sendet, um zu überprüfen, ob die TCP-Verbindung noch aktiv ist. Hier sind die Auswirkungen dieser Änderung im Detail:
Auswirkungen der Einstellung net.ipv4.tcp_keepalive_time = 1200:

Schnellere Erkennung inaktiver Verbindungen:
Mit einem Keepalive-Intervall von 20 Minuten anstelle des Standardwertes von 2 Stunden (7200 Sekunden) wird das System schneller inaktive Verbindungen erkennen. Dies kann nützlich sein, um Verbindungen zu beenden, die nicht mehr aktiv genutzt werden.

Bessere Ressourcenverwaltung:
Das schnellere Senden von Keepalive-Paketen hilft dabei, Ressourcen zu sparen, indem inaktive Verbindungen früher erkannt und geschlossen werden. Dies ist besonders vorteilhaft in Umgebungen mit vielen Verbindungen, wo es wichtig ist, nicht benötigte Verbindungen schnell zu identifizieren und zu entfernen.

Schnellere Reaktion auf Netzwerkprobleme:
Falls eine Verbindung aufgrund eines Netzwerkproblems unterbrochen wurde, kann das schnellere Keepalive-Intervall helfen, diese Unterbrechung früher zu erkennen und entsprechende Maßnahmen zu ergreifen, wie z.B. einen neuen Verbindungsversuch zu starten oder die Verbindung zu melden.

Erhöhter Netzwerk-Traffic:
Ein Nachteil der Reduzierung des tcp_keepalive_time-Wertes ist der erhöhte Netzwerk-Traffic aufgrund der häufigeren Keepalive-Pakete. In Umgebungen mit vielen Verbindungen kann dies zu einer geringfügigen Erhöhung der Netzwerklast führen.

Der Standardwert für die Einstellung net.ipv4.tcp_syncookies auf einem Debian Linux-System ist normalerweise 1. Diese Einstellung aktiviert oder deaktiviert TCP-Syncookies, die eine Sicherheitsmaßnahme gegen SYN-Flood-Angriffe darstellen.

Bedeutung von net.ipv4.tcp_syncookies:

Wert 1:
TCP-Syncookies sind aktiviert. Dies bedeutet, dass das System bei einer SYN-Flood-Attacke (einer Art Denial-of-Service-Angriff, bei dem eine große Anzahl von SYN-Anfragen gesendet wird, um die Ressourcen des Systems zu erschöpfen) Syncookies verwendet, um legitime Verbindungen zu akzeptieren, ohne Speicher für halb geöffnete Verbindungen zu verbrauchen.

Wert 0:
TCP-Syncookies sind deaktiviert. Dies ist nicht empfohlen, da das System anfälliger für SYN-Flood-Angriffe wird.

Die Einstellung net.ipv4.tcp_syncookies = 1 auf einem Debian-System aktiviert die Verwendung von TCP-Syncookies. Dies ist eine Sicherheitsmaßnahme, die dazu beiträgt, das System gegen SYN-Flood-Angriffe zu schützen. Hier ist eine detaillierte

Erklärung der Auswirkungen dieser Einstellung:
Auswirkungen von net.ipv4.tcp_syncookies = 1:

Schutz vor SYN-Flood-Angriffen:
Ein SYN-Flood-Angriff ist eine Form von Denial-of-Service-Angriff, bei dem ein Angreifer eine große Anzahl von SYN-Paketen (Verbindungsanforderungen) an einen Server sendet, ohne die Handshake-Prozedur abzuschließen. Dies kann dazu führen, dass die Verbindungswarteschlange des Servers überläuft und legitime Verbindungen abgelehnt werden.

Mit aktiviertem tcp_syncookies kann das System auch bei voller Verbindungswarteschlange weiterhin neue Verbindungen akzeptieren, indem es sogenannte Syncookies verwendet.

Funktionsweise von Syncookies:
Wenn die Verbindungswarteschlange für halb geöffnete Verbindungen voll ist, sendet der Server ein spezielles SYN-ACK-Paket mit einem verschlüsselten Cookie im Initial Sequence Number (ISN) zurück. Dieses Cookie enthält Informationen über die Verbindung, ohne dass der Server Speicher für die halb geöffnete Verbindung reservieren muss.
Wenn der Client mit einem ACK-Paket antwortet, kann der Server das Cookie überprüfen und die Verbindung herstellen, sofern das Cookie gültig ist.

Effizienz und Ressourcennutzung:
Die Verwendung von Syncookies erfordert keine zusätzlichen Ressourcen auf dem Server, um halb geöffnete Verbindungen zu verfolgen, wodurch das System auch unter Lastbedingungen (wie bei einem SYN-Flood-Angriff) stabil bleibt.

Kompatibilität:
Syncookies sind eine effektive Methode zur Abwehr von SYN-Flood-Angriffen, aber sie sind nur eine Notfallmaßnahme. Sie stellen sicher, dass das System weiterhin Verbindungen akzeptieren kann, ohne dass die Verbindungswarteschlange überläuft.
In einigen seltenen Fällen können Probleme mit bestimmten TCP-Optionen auftreten, die nicht in den Cookie integriert werden können. Dies sollte jedoch in den meisten modernen Netzwerken kein bedeutendes Problem darstellen.

Zusammenfassung:

Die Einstellung net.ipv4.tcp_syncookies = 1 sorgt dafür, dass das System:

 Gegen SYN-Flood-Angriffe geschützt ist, indem es auch bei voller Verbindungswarteschlange weiterhin neue Verbindungen akzeptieren kann.
 Effizient Ressourcen nutzt, indem es keine Speicherplätze für halb geöffnete Verbindungen reserviert.
 Ein spezielles Cookie-Verfahren anwendet, um die Gültigkeit von eingehenden Verbindungen zu überprüfen.

Der Standardwert für die Einstellung net.ipv4.tcp_tw_reuse auf einem Debian Linux-System ist in der Regel 0. Diese Einstellung gibt an, ob das System die Wiederverwendung von TCP-Verbindungen im TIME_WAIT-Zustand erlaubt.
Bedeutung von net.ipv4.tcp_tw_reuse:

Wert 0:
Die Wiederverwendung von TCP-Verbindungen im TIME_WAIT-Zustand ist deaktiviert. Das bedeutet, dass das System auf das normale Timeout für diese Verbindungen wartet, bevor die Ressourcen freigegeben werden. Dies ist der sichere und standardmäßige Modus, um mögliche Probleme durch die Wiederverwendung von Verbindungen zu vermeiden.

Wert 1:
Die Wiederverwendung von TCP-Verbindungen im TIME_WAIT-Zustand ist aktiviert. Dies kann in bestimmten Hochlast-Szenarien nützlich sein, um die Anzahl der Verbindungen im TIME_WAIT-Zustand zu reduzieren und Ressourcen schneller freizugeben. Allerdings kann dies auch zu Problemen führen, wenn Verbindungen vorzeitig wiederverwendet werden.

Die Einstellung net.ipv4.tcp_tw_reuse = 1 auf einem Debian-System erlaubt die Wiederverwendung von TCP-Verbindungen im TIME_WAIT-Zustand. Diese Konfiguration kann die Ressourcennutzung und Leistung in Netzwerken mit vielen kurzlebigen Verbindungen verbessern. Hier sind die spezifischen Auswirkungen und Überlegungen im Detail:
Auswirkungen von net.ipv4.tcp_tw_reuse = 1:

Schnellere Wiederverwendung von Verbindungen:
Verbindungen im TIME_WAIT-Zustand können wiederverwendet werden, anstatt darauf zu warten, dass das TIME_WAIT-Timeout abläuft. Dies reduziert die Anzahl der Verbindungen im TIME_WAIT-Zustand und beschleunigt die Freigabe von Systemressourcen.

Verbesserte Ressourcennutzung:
In Systemen mit einer hohen Anzahl von Verbindungen, die schnell geöffnet und geschlossen werden (z.B. Webserver mit vielen Clients), kann die Aktivierung dieser Einstellung die Leistung verbessern, da weniger Speicher und andere Ressourcen für Verbindungen im TIME_WAIT-Zustand benötigt werden.

Mögliche Sicherheitsrisiken:
Die Wiederverwendung von Verbindungen im TIME_WAIT-Zustand kann zu Sicherheitsproblemen führen, insbesondere wenn eine neue Verbindung eine alte Verbindung überlagert und es zu Datenkonflikten kommt. Dies kann potenziell zu Problemen mit Datenintegrität und Sicherheitslücken führen.

Netzwerkstabilität:
In Netzwerken mit ordnungsgemäß konfigurierten Clients und Servern sollte die Wiederverwendung von TIME_WAIT-Verbindungen stabil sein. In weniger kontrollierten Umgebungen kann dies jedoch zu unerwartetem Verhalten führen.

Der Standardwert für net.ipv4.ip_local_port_range auf einem Debian Linux System liegt im Bereich von 32768 bis 60999.Der Standardwert für net.ipv4.ip_local_port_range auf einem Debian Linux System liegt im Bereich von 32768 bis 60999.

Die Einstellung net.ipv4.ip_local_port_range = 10000 65000 auf einem Debian Linux System bewirkt, dass der Bereich der dynamischen bzw. temporären Ports, die vom System für ausgehende Verbindungen verwendet werden, geändert wird. Konkret bedeutet dies Folgendes:

Dynamischer Portbereich: Wenn eine Anwendung eine ausgehende Verbindung initiiert und keinen spezifischen Quellport angibt, wählt das System automatisch einen freien Port aus diesem definierten Bereich. Durch die Änderung auf 10000 65000 wird der verfügbare Pool der Ports vergrößert.

Erhöhung der verfügbaren Ports: Der Standardbereich von 32768-60999 bietet etwa 28231 Ports. Durch die Erweiterung auf 10000-65000 stehen nun 55001 Ports zur Verfügung. Dies kann besonders nützlich sein, wenn auf dem System viele ausgehende Verbindungen benötigt werden, beispielsweise bei Servern mit hohem Netzwerkverkehr oder bei bestimmten Anwendungen, die viele temporäre Verbindungen aufbauen.

Verminderung von Portkollisionen: Ein größerer Bereich verringert das Risiko von Portkollisionen, bei denen zwei ausgehende Verbindungen denselben Quellport verwenden möchten. Dies ist besonders relevant in hochfrequentierten Netzwerkumgebungen.

Der Standardwert für net.ipv4.tcp_max_syn_backlog auf einem Debian Linux System variiert je nach Version des Kernels und der spezifischen Systemkonfiguration. Allerdings ist ein üblicher Standardwert für viele Systeme 128.

Dieser Parameter definiert die maximale Anzahl von halb-offenen Verbindungen (Verbindungen im SYN_RECV Zustand) die das System in der Warteschlange halten kann. Das ist wichtig für den Verbindungsaufbau über das TCP-Protokoll, insbesondere unter hoher Last.

Die Einstellung net.ipv4.tcp_max_syn_backlog = 8192 auf einem Debian Linux System hat folgende detaillierte Auswirkungen:

Erhöhung der Warteschlange für eingehende Verbindungen: Der Wert 8192 gibt die maximale Anzahl von halb-offenen TCP-Verbindungen an, die das System in der Warteschlange halten kann. Halb-offene Verbindungen befinden sich im SYN_RECV-Zustand, das heißt, der Server hat das SYN-Paket vom Client erhalten und das SYN-ACK-Paket zurückgesendet, aber noch kein ACK-Paket vom Client empfangen.

Verbesserte Handhabung von hohen Verbindungsraten: Ein höherer Wert für tcp_max_syn_backlog bedeutet, dass das System mehr eingehende Verbindungen gleichzeitig verarbeiten kann, bevor es beginnt, neue Verbindungen abzulehnen. Dies ist besonders nützlich in Umgebungen mit hohem Netzwerkverkehr, wie Webservern, die viele gleichzeitige Verbindungsanfragen erhalten.

Reduzierung des Risikos von SYN-Flood-Angriffen: Bei einem SYN-Flood-Angriff sendet ein Angreifer viele SYN-Pakete, ohne die Verbindung abzuschließen, um die Ressource der Warteschlange zu erschöpfen. Ein höherer Wert für tcp_max_syn_backlog kann helfen, solche Angriffe abzumildern, indem das System eine größere Anzahl von halb-offenen Verbindungen verarbeiten kann. Allerdings ist es auch wichtig, andere Sicherheitsmechanismen wie SYN-Cookies zu verwenden.

Erhöhung des Ressourcenverbrauchs: Das Halten einer größeren Anzahl von halb-offenen Verbindungen erfordert mehr Speicher und andere Systemressourcen. Daher sollte der Wert sorgfältig gewählt werden, um sicherzustellen, dass das System genügend Ressourcen hat, um die erhöhte Warteschlange zu handhaben, ohne die Leistung zu beeinträchtigen.

Der Standardwert für net.ipv4.tcp_max_tw_buckets auf einem Debian Linux System beträgt normalerweise 180000.

Dieser Parameter bestimmt die maximale Anzahl von TCP-Zeitwarte (TIME-WAIT) Zuständen, die das System gleichzeitig halten kann. Der TIME-WAIT Zustand tritt auf, wenn eine TCP-Verbindung geschlossen wurde und das System sicherstellt, dass alle Pakete der alten Verbindung abgelaufen sind, bevor die gleiche Quell- und Zieladresse sowie Portnummern wiederverwendet werden können.

Die Einstellung net.ipv4.tcp_max_tw_buckets = 5000 auf einem Debian Linux System hat folgende detaillierte Auswirkungen:

Begrenzung der TIME-WAIT Zustände: Diese Einstellung legt fest, dass maximal 5000 TCP-Verbindungen gleichzeitig im TIME-WAIT Zustand sein dürfen. Der TIME-WAIT Zustand tritt auf, nachdem eine TCP-Verbindung geschlossen wurde, um sicherzustellen, dass alle verbleibenden Pakete der alten Verbindung aus dem Netzwerk verschwunden sind, bevor die gleiche Kombination aus Quell- und Zieladresse sowie Portnummern wiederverwendet werden kann.

Ressourcenmanagement: Da jede TCP-Verbindung im TIME-WAIT Zustand Speicherressourcen (insbesondere Kernel-Speicher) verbraucht, begrenzt diese Einstellung die Anzahl der TIME-WAIT Einträge, um den Speicherverbrauch zu kontrollieren. Bei Erreichen des Limits von 5000 TIME-WAIT Verbindungen wird das System beginnen, ältere Einträge zu entfernen.

Erhöhtes Risiko von Port-Wiederverwendung: Durch die Begrenzung auf 5000 TIME-WAIT Zustände kann es häufiger vorkommen, dass Ports früher wiederverwendet werden, was das Risiko von "Port-Wiederverwendungs"-Problemen erhöht. Dies kann zu potenziellen Konflikten führen, wenn alte Verbindungsdatenpakete noch im Netzwerk unterwegs sind und fälschlicherweise als Teil einer neuen Verbindung interpretiert werden.

Performance in Hochlastumgebungen: In Umgebungen mit hohem Netzwerkverkehr, wie stark frequentierten Webservern, kann eine zu niedrige Einstellung von tcp_max_tw_buckets zu Performance-Problemen führen, da das System häufig TIME-WAIT Einträge bereinigen muss, um Platz für neue Verbindungen zu schaffen. Dies kann die Effizienz der Verbindungsverarbeitung beeinträchtigen.

Warnmeldungen im Systemprotokoll: Wenn das System die maximale Anzahl von TIME-WAIT Zuständen erreicht und beginnt, ältere Einträge zu entfernen, können Warnmeldungen im Systemprotokoll (/var/log/syslog oder /var/log/messages) auftreten. Diese Meldungen dienen als Indikator dafür, dass das System an seine Grenze für TIME-WAIT Zustände stößt.