Bring Your Own IP auf einem VPS mit BGP: Leitfaden

Diese Seite ist der zentrale Knotenpunkt für den gesamten BYOIP-Weg. Sie verbindet jeden Schritt von der ASN-Beschaffung bis zur Überwachung Ihrer BGP-Ankündigungen in der Produktion. Jeder Abschnitt verweist auf einen dedizierten Vertiefungsartikel mit Konfigurationen, Befehlen und Überprüfungsschritten.

Wenn Sie bereits wissen, was BGP und BYOIP sind, springen Sie direkt zu Was brauchen Sie vor Ihrer ersten BGP-Session?.

Was bedeutet es, eigene IPs zu einem VPS mitzubringen?

Bring Your Own IP (BYOIP) bedeutet, IP-Adressraum, den Sie besitzen oder von einem Regional Internet Registry (RIR) leasen, über das Netzwerk eines Hosting-Anbieters per BGP anzukündigen. Anstatt die IP-Adressen des Anbieters zu verwenden, originiert Ihr VPS Routen für Ihre eigenen Präfixe. Traffic, der für diese IPs bestimmt ist, erreicht Ihren Server über die Upstream-Links und Internet-Exchanges des Anbieters.

Sie behalten die Kontrolle über die Adressen. Wenn Sie den Anbieter wechseln, ziehen Ihre IPs mit. Keine DNS-Änderungen, kein Reputations-Neuaufbau, keine kundenspürbare Ausfallzeit jenseits des Konvergenzfensters.

Warum eigene IPs mitbringen?

IP-Reputationskontinuität. E-Mail-Zustellbarkeit, DNS-Reputation und Firewall-Allowlists folgen der Adresse, nicht dem Server. Ein Anbieterwechsel mit vom Anbieter zugewiesenen IPs bedeutet, die Reputation von Null aufzubauen.

Anbieterportabilität. Ihre Präfixe sind an keinen einzelnen Host gebunden. Sie können zu einem anderen Anbieter wechseln oder Multi-Homing über zwei betreiben, ohne die Adressen zu ändern, mit denen sich Ihre Kunden verbinden.

Multi-Homing und Redundanz. Kündigen Sie dasselbe Präfix von mehreren Standorten an. BGP übernimmt das Failover automatisch. Ihr Dienst bleibt erreichbar, selbst wenn ein Standort ausfällt.

Compliance und Audit. Einige regulierte Umgebungen verlangen eine Dokumentation des IP-Adressbesitzes. Eine eigene Zuteilung über einen RIR liefert Ihnen diesen Nachweis.

Anycast. Kündigen Sie dasselbe Präfix von geografisch verteilten Knoten an. Benutzer werden zum nächsten geroutet. So funktionieren DNS-Root-Server und CDN-Edge-Knoten.

Wie passt BGP in das BYOIP-Konzept?

BGP (Border Gateway Protocol) ist das Protokoll, mit dem Router Erreichbarkeitsinformationen zwischen autonomen Systemen im Internet austauschen. Wenn Sie Ihre eigene IP zu einem VPS mitbringen, betreiben Sie einen BGP-Daemon auf Ihrem Server. Dieser Daemon baut eine Session mit dem Router Ihres Anbieters auf und kündigt Ihre Präfixe an. Der Anbieter propagiert diese Ankündigungen an seine Upstreams und Peers. Innerhalb von Minuten lernen Router im gesamten Internet, dass Ihr IP-Raum über das Netzwerk Ihres Anbieters erreichbar ist.

Es ist dasselbe Protokoll, das jeder ISP, Cloud-Anbieter und Content-Netzwerkbetreiber verwendet. Der Unterschied liegt im Umfang: Sie kündigen ein oder zwei Präfixe an statt Tausender.

Sie müssen nicht jedes BGP-Attribut verstehen, um loszulegen. Sie müssen wissen, wie man eine Session konfiguriert, ein Präfix ankündigt und filtert, was man akzeptiert. Die Vertiefungsartikel in diesem Cocoon behandeln jeden dieser Punkte im Detail.

Was brauchen Sie vor Ihrer ersten BGP-Session?

Sechs Bausteine in Abhängigkeitsreihenfolge:

Eine Autonomous System Number (ASN). Ihre Identität im BGP-Internet. Sie erhalten eine von einem RIR (RIPE NCC in Europa, ARIN in Nordamerika, APNIC im asiatisch-pazifischen Raum) über einen sponsoring LIR. Die Bearbeitung dauert beim RIPE NCC 2-5 Werktage.
Eine IP-Zuteilung. Mindestens ein /24 für IPv4 oder ein /48 für IPv6. Kleinere Präfixe werden von den meisten Netzwerken gefiltert und propagieren nicht. Sie können IPv4-Raum von einem RIR halten (zunehmend knapp und teuer) oder von einem Broker leasen. IPv6-Zuteilungen sind bei allen RIRs problemlos verfügbar.
IRR-Route-Objekte. Einträge im Internet Routing Registry, die dokumentieren, welche ASN berechtigt ist, Ihr Präfix zu originieren. Viele Transit-Anbieter bauen ihre BGP-Filter aus IRR-Daten auf. Ohne passendes Route-Objekt wird Ihre Ankündigung möglicherweise stillschweigend verworfen. Erstellen Sie diese in der RIPE-Datenbank (oder dem Äquivalent Ihres RIR) vor Ihrer ersten Session.
RPKI ROAs (Route Origin Authorizations). Kryptografische Objekte, die Ihr Präfix an Ihre ASN binden. Über 51 % der IPv4-Routen und 57 % der IPv6-Routen haben inzwischen gültige ROAs. Netzwerke, die Route Origin Validation (ROV) durchführen, werden Ankündigungen ablehnen, die RPKI-Prüfungen nicht bestehen. Erstellen Sie ROAs im Portal Ihres RIR.
Ein Routing-Daemon. Software auf Ihrem VPS, die BGP spricht. Die drei Hauptoptionen sind BIRD2, FRRouting (FRR) und VyOS. Siehe den Vergleich unten.
Ein Anbieter mit BGP-Session-Support. Nicht jeder VPS-Anbieter bietet dies an. Sie brauchen einen Anbieter, der eine BGP-Session zwischen seinem Router und Ihrem VPS konfiguriert, Ihre Präfix-Ankündigungen akzeptiert und sie upstream propagiert.

Checkliste vor dem Start

Bevor Sie eine BGP-Session bei Ihrem Anbieter anfordern, stellen Sie sicher, dass Sie Folgendes haben:

Posten	Bezugsquelle	Zeitschätzung
ASN	RIR über sponsoring LIR	2-5 Werktage
IPv4 /24 oder größer	RIR-Zuteilung oder Lease	Tage bis Wochen
IPv6 /48 oder größer	RIR-Zuteilung	1-2 Werktage
IRR route/route6-Objekte	RIPE-Datenbank oder Äquivalent	Minuten (nach ASN)
RPKI ROAs für jedes Präfix	RIR-Mitgliedsportal	Minuten
LOA (Letter of Authorization)	Sie unterzeichnen, Anbieter kann sie anfordern	Minuten
Anbieter mit BGP-Support	oder ähnlich	Variiert

Ihr Anbieter benötigt in der Regel Ihre ASN, die Präfixe, die Sie ankündigen möchten, und möglicherweise eine LOA, die bestätigt, dass Sie zur Ankündigung berechtigt sind.

Wie hängen ASN, IP-Zuteilung und RPKI zusammen?

Diese drei bilden die Vertrauenskette, die es dem Internet ermöglicht, die Legitimität Ihrer Ankündigungen zu überprüfen.

Ihre ASN identifiziert Ihr Netzwerk. Jede BGP-Ankündigung trägt die originierende ASN in ihrem AS-Path. Upstream-Netzwerke nutzen dies, um Routing-Policies aufzubauen.

Ihre IP-Zuteilung ist der Adressraum, den Sie verwenden dürfen. Die Datenbank des RIR registriert Sie (oder Ihren sponsoring LIR) als Inhaber.

IRR-Objekte sind die Routing-Policy-Schicht. Ein route-Objekt in der RIPE-Datenbank sagt: „AS64500 ist berechtigt, 192.0.2.0/24 zu originieren." Transit-Anbieter fragen IRR-Daten ab, um Präfix-Filter aufzubauen. Wenn Ihr Route-Objekt fehlt oder falsch ist, können die automatisierten Filter Ihres Transit-Anbieters Ihre Ankündigung ablehnen.

RPKI ROAs sind die kryptografische Schicht. Ein ROA ist ein signiertes Objekt, das im RPKI-Repository Ihres RIR gespeichert ist. Es sagt dasselbe wie das IRR-Route-Objekt, ist aber kryptografisch verifizierbar. Netzwerke, die ROV-Validatoren betreiben (Routinator, rpki-client, Fort, RIPE NCC RPKI Validator), rufen ROAs ab und speisen die Validierungsergebnisse in ihre Router ein. Eine Ankündigung ohne gültigen ROA wird zunehmend wahrscheinlich verworfen.

Die Abhängigkeitskette sieht so aus:

ASN (from RIR)
  └── IP allocation (from RIR)
        ├── IRR route objects (RIPE Database)
        ├── RPKI ROAs (RIR portal)
        └── BGP session (provider router <-> your daemon)
              └── Prefix announcement (your daemon originates routes)

Bringen Sie die oberen Schichten in Ordnung, bevor Sie die BGP-Konfiguration anfassen. Eine Ankündigung ohne passende IRR- und RPKI-Einträge wird entweder gefiltert oder als potenzieller Hijack gemeldet.

Welchen Routing-Daemon sollten Sie verwenden: BIRD2, FRR oder VyOS?

Drei Optionen dominieren BGP auf Linux-VPS-Umgebungen. Alle drei unterstützen Dual-Stack (IPv4 + IPv6), RPKI-Validierung und die für BYOIP benötigten Features. Die Wahl hängt vom bevorzugten Konfigurationsstil und den betrieblichen Anforderungen ab.

Feature	BIRD2	FRRouting (FRR)	VyOS
Konfigurationsstil	Eigene deklarative Sprache	Cisco-IOS-ähnliches CLI (vtysh)	JunOS-ähnliches CLI (set/commit)
Filtersprache	Leistungsstark, Turing-vollständig	Route-Maps + Prefix-Lists	Route-Maps (FRR unter der Haube)
Dual-Stack	Einzelne Konfigurationsdatei, Multi-Table	Separate Address-Family-Blöcke	Separate Address-Family-Blöcke
RPKI-Support	Eingebautes `rpki`-Protokoll	Eingebautes rpki-Modul	Über FRR-Integration
Speicherverbrauch	Geringer (2x effizienter als FRR in Benchmarks)	Höher, besonders mit vollen Tabellen	Höher (Overhead eines vollständigen OS)
Lernkurve	Steiler, wenn man von Cisco kommt	Niedrig für Cisco/IOS-Nutzer	Niedrig für JunOS-Nutzer
Am besten für	IXP-Route-Server, policy-lastige Setups	Vertrauter Cisco-Workflow	Vollständige Router-OS-Erfahrung

BIRD2 hat die ausdrucksstärkste Filtersprache. Sie können komplexe Import/Export-Policies in einer einzigen Konfigurationsdatei schreiben. Es verarbeitet IPv4 und IPv6 in einer Daemon-Instanz. Der Speicherbedarf beträgt ungefähr die Hälfte von FRR bei vergleichbarer Last. Der Kompromiss: Seine Konfigurationssyntax hat kein Äquivalent in der Herstellerwelt. Sie lernen BIRDs Sprache, oder Sie verwenden BIRD nicht.

FRRouting (FRR) verwendet ein Cisco-IOS-ähnliches CLI über vtysh. Wenn Sie mit Cisco, Arista oder dem alten Quagga gearbeitet haben, fühlt sich FRR sofort vertraut an. Route-Maps und Prefix-Lists funktionieren wie erwartet. Es ist die am weitesten verbreitete Open-Source-Routing-Suite.

VyOS ist ein vollständiges Netzwerk-Betriebssystem, das FRR als Routing-Engine nutzt. Sie konfigurieren alles über einen JunOS-artigen set / commit-Workflow. Es bietet eine komplette Router-Erfahrung: Firewall, NAT, VPN, DHCP und Routing in einem Paket. Auf Virtua Cloud können Sie VyOS mit einem Klick deployen. Der Kompromiss: Es ist ein vollständiges OS, kein einzelner Daemon. Sie geben die Flexibilität eines universellen Linux-Servers auf.

Welchen wählen? Wenn Sie maximale Kontrolle und Effizienz wollen, wählen Sie BIRD2. Wenn Sie Cisco-Vertrautheit auf einem Linux-Server wollen, wählen Sie FRR. Wenn Sie eine dedizierte Router-Appliance wollen, wählen Sie VyOS.

Wie sichern Sie ein BGP-Deployment ab?

Sicherheit bei BGP ist nicht optional. Eine falsch konfigurierte BGP-Session kann Routen leaken, gekaperte Präfixe akzeptieren oder Ihr Netzwerk für Traffic-Injection öffnen. Jedes BGP-Deployment sollte diese Schichten von Tag eins an beinhalten.

RPKI und Route Origin Validation

Konfigurieren Sie Ihren Daemon so, dass er empfangene Routen gegen RPKI-Daten validiert. Betreiben Sie einen lokalen RPKI-Cache (Routinator oder rpki-client) oder verbinden Sie sich mit einem gehosteten Validator. Lehnen Sie Routen mit RPKI-Status „invalid" ab. Dies verhindert, dass Ihr Router gekaperte Präfixe akzeptiert.

Stand 2025 haben über 51 % der IPv4-Routen und 57 % der IPv6-Routen gültige ROAs. Alle großen Transit-Anbieter führen ROV durch. Wenn Ihre eigenen Präfixe keine ROAs haben, werden einige Netzwerke Ihre Ankündigungen verwerfen.

Routenfilterung

Verwenden Sie niemals export all oder import all in der Produktion. Das ist das BGP-Äquivalent zu chmod 777.

Auf der Export-Seite kündigen Sie nur Präfixe an, die Sie originieren dürfen. Verwenden Sie eine Prefix-List, die explizit Ihren Zuteilungen entspricht. Auf der Import-Seite akzeptieren Sie bei Single-Homing (ein Upstream) typischerweise nur eine Default-Route. Bei Multi-Homing filtern Sie Imports nach Prefix-List und AS-Path, um Route-Leaks zu verhindern.

Lehnen Sie Bogon-Präfixe (RFC-1918-Raum, Dokumentationsranges, nicht zugeteilte Blöcke) beim Import ab. Lehnen Sie Präfixe ab, die länger als /24 für IPv4 oder /48 für IPv6 sind. Setzen Sie Max-Prefix-Limits, um sich davor zu schützen, dass ein Peer versehentlich eine volle Routing-Tabelle in Ihre Session kippt.

GTSM (Generalized TTL Security Mechanism)

GTSM (RFC 5082) stellt sicher, dass BGP-Pakete mit einem TTL von 255 ankommen, was bedeutet, dass sie von einem direkt verbundenen Nachbarn stammen. Dies blockiert entfernte Angreifer am Einschleusen von BGP-Paketen. Die meisten Anbieter unterstützen es. Aktivieren Sie es auf Ihrer Seite, wenn Ihr Anbieter den Support bestätigt.

Firewall-Regeln

Erlauben Sie TCP-Port 179 nur von der BGP-Router-IP Ihres Anbieters. Verwerfen Sie alles andere, das für Port 179 bestimmt ist. Das ist eine einzelne nftables- oder iptables-Regel, aber sie verhindert unautorisierte BGP-Verbindungsversuche.

Häufige Fallstricke

rp_filter bricht den Traffic. Linux Reverse Path Filtering (rp_filter=1, Standard auf vielen Distributionen) verwirft Pakete, die auf einem Interface ankommen, wenn die Routing-Tabelle des Kernels sagt, dass die Quell-IP auf einem anderen Interface ankommen sollte. Mit BGP-angekündigten Präfixen auf Dummy-Interfaces bricht dies legitimen Traffic. Setzen Sie rp_filter=0 oder rp_filter=2 (Loose Mode) auf den betroffenen Interfaces. Testen Sie nach jedem Kernel-Upgrade.

Verwechslung von BIRD-1.x- und BIRD-2.x-Konfiguration. BIRD 2 verwendet eine völlig andere Konfigurationssyntax als BIRD 1.x. Viele Online-Tutorials (einschließlich Top-Suchergebnisse von Vultr und anderen) zeigen noch BIRD-1.x-Syntax. Wenn Sie Konfigurationen aus einem alten Tutorial in BIRD 2 einfügen, verweigert der Daemon den Start. Prüfen Sie immer, welche Version Sie ausführen, mit birdc show status.

Fehlende IRR-Objekte. Sie haben RPKI ROAs erstellt, aber das IRR-Route-Objekt vergessen. Der automatisierte Filterbauer Ihres Upstreams fragt IRR ab, findet kein passendes Objekt und verwirft Ihre Ankündigung stillschweigend. Ihr Präfix ist RPKI-valid, aber trotzdem nicht erreichbar. Erstellen Sie immer beides.

Was können Sie mit BGP jenseits einfacher Ankündigungen tun?

Sobald Ihr Präfix angekündigt und erreichbar ist, eröffnet BGP mehrere fortgeschrittene Anwendungsfälle.

Anycast

Kündigen Sie dasselbe Präfix von mehreren geografischen Standorten an. Jeder Standort betreibt einen identischen Dienst (DNS-Resolver, CDN-Edge, API-Endpoint). Benutzer werden durch die BGP-Pfadauswahl zum nächstgelegenen Standort geroutet. Fällt ein Standort aus, fällt seine BGP-Session, das Präfix wird von diesem Standort zurückgezogen, und der Traffic wechselt automatisch zu den verbleibenden Standorten.

Anycast ist das Funktionsprinzip des DNS-Root-Server-Systems. Sie können dasselbe Muster mit zwei oder drei VPS-Knoten in verschiedenen Rechenzentren betreiben.

Failover und Multi-Homing

Kündigen Sie Ihr Präfix von zwei Anbietern oder zwei Standorten beim selben Anbieter an. Verwenden Sie LOCAL_PREF und MED, um die Primär-/Backup-Präferenz festzulegen. Fällt der Primärstandort aus, wechselt der Traffic innerhalb des BGP-Konvergenzfensters zum Backup (typischerweise 30-90 Sekunden mit aktiviertem BFD).

Für geplante Wartung verwenden Sie die Graceful-Shutdown-Community (RFC 8326). Ihr Daemon signalisiert den Peers, das Präfix zu deprioritisieren, bevor Sie die Session herunterfahren. Der Traffic fließt verlustfrei zum Backup-Standort ab.

BGP Communities für Traffic Engineering

Communities sind Tags, die an BGP-Ankündigungen angehängt werden und beeinflussen, wie Upstream-Netzwerke Ihre Routen behandeln. Gängige Verwendungen:

Blackhole-Community: Signalisieren Sie Ihrem Upstream, den gesamten Traffic zu einem bestimmten Präfix während eines DDoS-Angriffs zu verwerfen.
Prepending-Kontrolle: Bitten Sie Ihren Upstream, Ihre AS zu prependen, um einen Pfad weniger bevorzugt zu machen und Traffic zu einem anderen Upstream zu lenken.
Selektive Ankündigung: Kündigen Sie an Peers an, aber nicht an Transit, oder umgekehrt. So kontrollieren Sie, wohin sich Ihr Präfix propagiert.
Geografische Begrenzung: Beschränken Sie die Ankündigung auf bestimmte Regionen oder IXPs.

Jeder Anbieter definiert eigene Community-Werte. Prüfen Sie die BGP-Community-Dokumentation Ihres Anbieters, bevor Sie sie verwenden.

Wie überwachen Sie BGP-Ankündigungen?

Sie müssen wissen, wann sich etwas an Ihren Präfixen ändert. Route-Hijacks, versehentliche Withdrawals, RPKI-Statusänderungen und Sichtbarkeitseinbrüche erfordern alle sofortige Aufmerksamkeit. Gehen Sie nicht davon aus, dass Ihre Ankündigungen stabil sind, weil sie gestern funktioniert haben.

BGPalerter ist ein selbst gehostetes Monitoring-Tool, das Ihre Präfixe und ASN überwacht. Es verbindet sich mit öffentlichen BGP-Datenquellen (RIPE RIS, RouteViews) und alarmiert Sie bei:

Präfix-Hijacks (eine andere ASN originiert Ihr Präfix)
Sub-Präfix-Hijacks (jemand kündigt ein spezifischeres Ihres Präfixes an)
Route-Leaks
RPKI-Invalid-Statusänderungen
Sichtbarkeitseinbrüchen (Ihr Präfix verschwindet von einer signifikanten Anzahl von Beobachtungspunkten)

Betreiben Sie es als systemd-Service auf einem separaten VPS, nicht auf dem, der BGP macht. Wenn Ihr BGP-Knoten ausfällt, wollen Sie trotzdem Alarme erhalten. Konfigurieren Sie Benachrichtigungen an Slack, E-Mail oder Ihren Monitoring-Stack.

Externe Validierungstools

Nutzen Sie diese, um zu überprüfen, ob Ihre Ankündigungen von außen korrekt aussehen:

bgp.tools -- Echtzeit-Ansicht Ihres Präfixes, AS-Path, RPKI-Status und IRR-Konsistenz
RIPE Stat -- Vom RIR betriebenes Looking Glass mit Routing-Historie und RPKI-Validierung
Hurricane Electric BGP Toolkit (bgp.he.net) -- AS-Informationen, Präfix-Reports, IRR- und RPKI-Status
Looking-Glass-Server -- Die meisten Transit-Anbieter und IXPs bieten Looking-Glass-Zugang, um zu prüfen, wie Ihr Präfix aus deren Perspektive erscheint

Prüfen Sie diese nach Ihrer ersten Ankündigung und danach regelmäßig. Eine Ankündigung, die aus Sicht Ihres Daemons korrekt aussieht, kann weiter upstream gefiltert oder gekapert sein.

Der vollständige Weg: Von Null zum überwachten BGP

Hier ist der komplette Pfad mit Links zum Artikel, der jeden Schritt abdeckt:

ASN besorgen von Ihrem RIR über einen sponsoring LIR.
IP-Raum beschaffen. Mindestens /24 IPv4, /48 IPv6. Von Ihrem RIR oder einem Broker.
IRR-Route-Objekte erstellen in der RIPE-Datenbank für jedes Präfix.
RPKI ROAs erstellen im Portal Ihres RIR für jedes Präfix.
Routing-Daemon wählen: BIRD2 , FRR oder VyOS .
BGP konfigurieren auf Ihrem VPS. Session aufbauen, Präfixe ankündigen, Filter anwenden.
Deployment absichern. RPKI-Validierung, Routenfilterung, GTSM, Firewall-Regeln.
Von außen überprüfen. bgp.tools, RIPE Stat und das Looking Glass Ihres Anbieters prüfen.
Monitoring einrichten. BGPalerter deployen, um Hijacks und Sichtbarkeitsprobleme zu erkennen.
Fortgeschrittene Anwendungsfälle erkunden. Communities , Anycast , Failover .

Brauchen Sie eine eigene ASN oder reicht eine private?

Wenn Sie Präfixe nur an einen Upstream ankündigen und nie Multi-Homing oder Peering an einem IXP planen, kann eine private ASN (64512-65534 für 16-Bit, 4200000000-4294967294 für 32-Bit) funktionieren. Ihr Anbieter entfernt sie aus dem AS-Path, bevor er Ihre Routen upstream propagiert.

Besorgen Sie sich eine eigene öffentliche ASN, wenn einer dieser Punkte zutrifft:

Sie planen, sich mit mehreren Upstreams zu verbinden (Multi-Homing)
Sie wollen an einem Internet Exchange peeren
Sie wollen, dass Ihre ASN in Traceroutes und BGP Looking Glasses sichtbar ist
Sie wollen BGP Communities verwenden, die Ihre ASN referenzieren
Sie betreiben einen Dienst, bei dem Netzwerkidentität zählt (CDN, DNS, E-Mail-Infrastruktur)

Der Kostenunterschied ist minimal. Eine öffentliche ASN über das RIPE NCC kostet die Gebühr des sponsoring LIR (typischerweise einige Hundert Euro pro Jahr). Für die meisten Anwendungsfälle ist eine öffentliche ASN die richtige Wahl.

Copyright 2026 Virtua.Cloud. Alle Rechte vorbehalten. Dieser Inhalt ist ein Originalwerk des Virtua.Cloud-Teams. Vervielfältigung, Wiederveröffentlichung oder Weiterverbreitung ohne schriftliche Genehmigung ist untersagt.