Zum Inhalt springen
DDoS-Schutz · Peeryx · 15 Tbps+
Alle Ratgeber

GRE, Reverse Proxy oder BGP: Welcher Weg passt zum geschützten Dienst?

GRE, Reverse Proxy und BGP erfüllen unterschiedliche Aufgaben. Die Wahl hängt davon ab, welche Dienste erreichbar sein sollen, wer das Netzwerk betreibt und wie Hin- und Rückweg verlaufen. Keine dieser Techniken ist für sich genommen ein vollständiger DDoS-Schutz oder eine Zusage niedriger Latenz.

← Alle RatgeberCubixServ

Vorbereitung

Erstelle einen Plan mit öffentlichem Endpunkt, Ursprung, Protokollen und Rückweg. Halte Berechtigungen für die betroffenen Adressen und Netze sowie die Vereinbarungen mit dem Betreiber bereit. Änderungen an Routing und Filtern benötigen Sicherungen, ein Wartungsfenster und einen kontrollierten Rückweg.

Zuerst die Aufgabe festlegen

Soll eine HTTP-Anwendung vorgeschaltet erreicht werden, ein TCP- oder UDP-Dienst weitergeleitet werden oder ein gesamtes autorisiertes IP-Präfix über ein anderes Netz angekündigt werden? Diese Fragen sind verschieden und führen nicht automatisch zu derselben Lösung.

Notiere auch, ob die ursprüngliche Clientadresse erhalten bleiben muss und welches Verhalten die Anwendung erwartet. Ein Produktname erklärt weder den Rückweg noch die erlaubten Dienste. Lass die konkrete Topologie bestätigen, bevor du Konfigurationen aus allgemeinen Beispielen übernimmst.

GRE als Tunnel verstehen

GRE kapselt Pakete zwischen Endpunkten. Bei IPv4 wird das IP-Protokoll 47 verwendet; dies ist kein TCP-Port 47. Der Tunnel schafft einen Transportweg und kann für die Übergabe gefilterten Verkehrs eingesetzt werden, wenn beide Seiten dafür eingerichtet sind.

GRE liefert allein keine Verschlüsselung oder Authentifizierung. Endpunkte, zulässige Quellen und der Rückweg müssen abgesichert werden. Prüfe außerdem die zusätzliche Paketgröße: Durch Kapselung kann die nutzbare MTU kleiner werden, was bestimmte Verbindungen beeinflusst.

HTTP und Stream-Proxys unterscheiden

Ein HTTP-Reverse-Proxy arbeitet mit HTTP-Anfragen und kann dazu passende Regeln anwenden. Für andere TCP- oder UDP-Dienste ist eine geeignete Transportweiterleitung nötig. NGINX trennt beispielsweise HTTP-Konfiguration und das Stream-Modul für TCP beziehungsweise UDP.

Prüfe Sitzungslängen, Timeouts und das Verhalten bei UDP. Eine funktionierende Webseite beweist nicht, dass der Spielverkehr korrekt weitergeleitet wird. Auch die Weitergabe der Clientadresse hängt davon ab, welche Verfahren der Ursprung tatsächlich unterstützt.

BGP setzt Berechtigungen und Betrieb voraus

BGP dient dem Austausch von Routinginformationen. Eine Ankündigung eines Präfixes benötigt dafür autorisierte Ressourcen, Betreibervereinbarungen und passende Routingrichtlinien. Eine beliebige VPS-Adresse ist kein automatisch frei ankündigbares Netz.

BGP filtert nicht von selbst schädliche Anfragen. Geschützter Transit kombiniert Routing mit der vorgesehenen Filterung und Übergabe. Kläre, wer Ankündigungen, Rückwege und Störungen betreut und welche Präfixgrößen sowie weiteren Bedingungen der Anbieter zulässt.

MTU und Rückweg praktisch prüfen

Teste nicht nur kleine Pakete oder einen einzelnen Port. Übertrage typische Nutzdaten und prüfe den wirklichen Dienst. Probleme durch Kapselung oder eine fehlerhafte Pfad-MTU können erst bei größeren Übertragungen sichtbar werden, obwohl ein einfacher Verfügbarkeitstest funktioniert.

Asymmetrische Wege können bei zustandsbehafteten Komponenten eine Rolle spielen. Zeichne deshalb beide Richtungen auf und vergleiche sie mit der vorgesehenen Konfiguration. Ändere keine globalen MTU- oder Routingwerte, ohne die Auswirkungen auf andere Dienste zu prüfen.

Die Lösung anhand des Betriebs auswählen

Ein einzelner Webdienst hat andere Anforderungen als mehrere Spielprotokolle oder ein eigenes Netz. Berücksichtige Zuständigkeit, Überwachung, Wiederherstellung und die Arbeit bei einem Ausfall. Die technisch weitreichendste Methode ist nicht automatisch die beste für ein kleines Projekt.

Prüfe vor der Umstellung dieselben Anwendungen im geplanten Aufbau. Dokumentiere erfolgreiche Verbindungen, Verzögerung, Paketverlust und Einschränkungen. Ein Angebot muss seine tatsächlichen Leistungen und Voraussetzungen erklären; dedizierte Kapazität oder universeller L7-Schutz folgen aus keiner dieser Methoden allein.

Was zu deiner Situation passt

SituationNächste Prüfung
Ein HTTP-DienstPrüfe einen HTTP-Reverse-Proxy mit passenden Ursprungsregeln und einer gesonderten Absicherung der Verwaltung.
Mehrere TCP/UDP-DiensteVergleiche Tunnel oder passende Transportweiterleitung einschließlich MTU, Clientadressen und Rückweg.
Ein eigenes autorisiertes IP-NetzKläre BGP-, Transit- und Präfixbedingungen mit dem Betreiber. Eine einzelne zugewiesene VPS-IP reicht dafür nicht aus.

Offizielle Quellen

Diese Dokumente erläutern die jeweiligen Protokolle und Programme. Prüfe zusätzlich die Bedingungen und die tatsächliche Konfiguration deines Dienstes.

  1. RFC Editor / IETF/rfc/rfc2784
  2. RFC Editor / IETF/rfc/rfc4271
  3. NGINX/en/docs/stream/ngx_stream_proxy_module.html
  4. Cfx.re/docs/server-manual/proxy-setup/