Die RPKI-Validierung ist nun ein wichtiger Bestandteil der modernen BGP-Routingsicherheit. Sie hilft Netzwerkadministratoren dabei zu bestimmen, ob eine Autonome Systemnummer berechtigt ist, einen bestimmten IPv4- oder IPv6-Präfix zu ursprünglich zu machen. Wenn ein Router eine Routenanmeldung erhält, kann er die Anmeldung mit der veröffentlichten RPKI-Berechtigung für diesen Adressbereich vergleichen.
Das Ergebnis wird normalerweise als Gültig, Ungültig oder Nicht gefunden angezeigt. Diese drei Bezeichnungen sind einfach, werden aber häufig missverstanden. Ein gültiges Ergebnis bedeutet nicht, dass jedes Teil der Route perfekt ist. Ein ungültiges Ergebnis bedeutet nicht immer, dass jemand das Netzwerk angreift. Ein Nicht gefunden-Ergebnis bedeutet nicht automatisch, dass die Annonce unsicher ist.
Die Labels beschreiben nur die Beziehung zwischen einer BGP-Ankündigung und den verfügbaren Route Origin Authorization-Daten. Um das Ergebnis korrekt zu verstehen, müssen Sie drei Details vergleichen: den angekündigten IP-Präfix, die Ursprungs-ASN und die maximal zulässige Präfixlänge gemäß der Autorisierung.
Dieser Artikel erklärt jeden RPKI-Status in praktischen Begriffen, zeigt, warum legitime Routen ungültig werden können, und bietet einen Fehlerbehebungsprozess für Netzwerkbetreiber, die ihren eigenen ASN, IPv4-Ressourcen, IPv6-Zuweisungen oder Upstream-Routing verwalten. Wenn Sie neu in dem Thema sind, beginnen Sie mit unserem Leitfaden zu Was ist RPKI? und dann lesen Was ist ein ROA in RPKI? für eine detaillierte Erklärung des Autorisierungsprotokolls selbst.
Was ist RPKI-Validierung?
RPKI steht für Resource Public Key Infrastructure. Sie verbindet Internet-Nummer-Ressourcen mit kryptografisch signierten Autorisierungsdatensätzen. Der Inhaber oder autorisierte Administrator eines IP-Prefixes kann eine ROA veröffentlichen, die besagt, dass eine bestimmte ASN berechtigt ist, diesen Prefix im BGP zu ursprüngen.
Ein Validator sammelt diese signierten Protokolle, prüft deren Authentizität und erstellt ein validiertes Datensatz für Netzwerkbetreiber. Wenn ein BGP-Routenempfang erfolgt, vergleicht das Routing-System des Betreibers die Route mit diesem Datensatz. Der Vergleich stellt drei grundlegende Fragen: Ist der angekündigte Präfix durch eine Autorisierung abgedeckt? Ist der Ursprungs-ASN der in dieser Autorisierung aufgeführte? Ist die Länge des angekündigten Präfixes innerhalb der erlaubten maximalen Länge?
Die Antwort auf diese Fragen erzeugt den RPKI-Status. Der Status gilt für die Route-Origin-Befugnis, nicht für jedes Attribut des BGP-Pfads. RPKI beweist nicht, dass alle Zwischennetze korrekt sind, dass der Verkehr den besten Pfad folgt oder dass die Adressressource rechtlich zum Verkauf verfügbar ist. Es handelt sich um ein fokussiertes Sicherheitssignal, das das Vertrauen in die Herkunft einer Route verbessert.
Was bedeutet RPKI-Valid?
Eine Route ist RPKI-Valide wenn die BGP-Meldung von mindestens einem anwendbaren ROA abgedeckt ist, stimmt die Ursprungs-ASN mit der autorisierten ASN überein und ist die angekündigte Präfixlänge durch den ROA's maximalen Länge erlaubt. In praktischer Hinsicht ist der Weg mit der vom Ressourcenhalter veröffentlichten Routing-Ermächtigung konsistent.
Zum Beispiel, nehmen Sie an, dass ein Unternehmen kontrolliert 203.0.113.0/24 und veröffentlicht eine ROA, die ermächtigt AS64500 hervorbringen, dass /24. Wenn das Unternehmen bekanntgibt 203.0.113.0/24 von AS64500, die Ankündigung sollte "Valide" zurückgeben. Das gilt auch für ein IPv6-Beispiel wie 2001:db8:1200::/48 wenn der richtige ASN und die erlaubte Präfixlänge verwendet werden.
Ein gültiges Ergebnis ist ein positives Signal, sollte aber nicht als vollständige Garantie interpretiert werden. Der Weg kann immer noch einen falschen Pfad haben, eine schlechte Geschäftswertung, eine veraltete Registry-Beschreibung oder ein betriebliches Problem außerhalb der Ursprungsautorität haben. Netzwerkbetreiber kombinieren RPKI normalerweise mit BGP-Monitoring, Präfix-Filterung, Registry-Prüfungen und Notfallreaktionsverfahren.
Ein gültiger Status kann sich auch ändern, wenn das Netzwerk wechselt. Wenn ein Unternehmen einen Präfix zu einem anderen ASN verschiebt, eine spezifischere Route anbietet oder seinen Adressplan ändert, kann die vorhandene ROA möglicherweise nicht mehr mit der neuen Anmeldung übereinstimmen. RPKI spiegelt die aktuellen Berechtigungsdaten wider und muss daher als Teil der normalen Netzwerkbetriebsvorgänge gepflegt werden.
Was bedeutet RPKI ungültig?
Eine Route ist RPKI ungültig wenn eine anwendbare Berechtigung besteht, aber die BGP-Ankündigung damit im Konflikt steht. Der Konflikt betrifft normalerweise eines von zwei Dingen: der Ursprungs-ASN ist nicht berechtigt, oder der angekündigte Präfix ist spezifischer als die maximal zulässige Länge gemäß dem ROA.
Zum Beispiel darf ein ROA AS64500 entstehen 198.51.100.0/24. Wenn AS64510 meldet dasselbe Präfix, stimmt die Ursprungs-ASN nicht überein und der Weg wird ungültig. Das Ergebnis kann auch auftreten, wenn AS64500 ist berechtigt für die /24 aber kündigt an 198.51.100.0/25 während die ROA keine Präfixe zulässt, die spezifisch sind.
Ungültig bedeutet nicht unbedingt, dass ein böswilliger Diebstahl stattfindet. Viele ungültige Routen werden durch gewöhnliche Betriebsfehler verursacht. Ein Ingenieur kann vergessen, eine ROA nach einer ASN-Migration zu aktualisieren, ein Anbieter kann ein Kundenpräfix mit dem falschen Ursprung ankündigen, oder das Netzwerk kann mehr-spezifische Präfixe verwenden, ohne die maximale Länge zu ändern.
Gleichzeitig sollte ein ungültiges Ergebnis nicht ignoriert werden. Es kann auf eine unautorisierte Ankündigung, einen Routenleak mit einer unerwarteten Quelle oder eine Konfigurationsfehler hinweisen, der dazu führen kann, dass der Präfix über Netzwerke mit strengen RPKI-Filtern nicht erreichbar ist. Die richtige Reaktion besteht darin, das Ergebnis schnell zu untersuchen und es mit dem geplanten Routing-Entwurf zu vergleichen.
Was bedeutet "RPKI nicht gefunden"?
Eine Route ist RPKI nicht gefunden wenn der Validator keinen passenden ROA für den angekündigten Präfix finden kann. Es gibt keine veröffentlichte Autorisierung, die die Ursprungs-ASN für diesen Weg bestätigen oder widerlegen kann.
Nicht gefunden wird manchmal als „unbekannt“ bezeichnet, weil das Validierungssystem nicht genug Berechtigungsinformationen hat, um zu einem Ergebnis zu gelangen. Es bedeutet nicht, dass die Route ungültig ist, und es beweist auch nicht, dass der Ursprung nicht berechtigt ist. Viele legitime Präfixe im Internet haben immer noch keinen ROA, entweder weil der Ressourceninhaber noch keinen erstellt hat oder weil die Berechtigung noch nicht für den Validator sichtbar geworden ist.
Die Abwesenheit einer ROA verringert die Menge an Informationen, die Netzwerken zur Verfügung stehen, um den Weg zu validieren. Wenn ein nicht autorisierter ASN den gleichen Präfix annonciert, kann ein Netzwerk, das beide Annoncen sieht, Schwierigkeiten haben, den legimitimen Weg von dem falschen mit RPKI allein zu unterscheiden.
Ressourcenträger sollten normalerweise genaue ROAs für Präfixe veröffentlichen, die öffentlich angekündigt werden, insbesondere wenn diese Präfixe wichtige Dienste unterstützen. Jedoch sollten Betreiber darauf verzichten, eine hastig oder zu weitreichend formulierte Autorisierung zu erstellen, nur um "Not Found" in "Valid" zu ändern. Eine schlecht konfigurierte ROA kann eine legitime Route in "Invalid" umwandeln, was einen unmittelbareren betrieblichen Einfluss haben kann.
Der Unterschied zwischen ungültig und nicht gefunden
Die wichtigste Unterscheidung ist, dass Ungültig ist ein Konflikt, während Nicht gefunden ist das Fehlen von Autorisierungsdaten. Ungültig bedeutet, dass der Validator eine relevante ROA gefunden hat, aber die Route damit nicht übereinstimmt. Nicht gefunden bedeutet, dass keine anwendbare ROA gefunden wurde.
Betrachten Sie zwei Beispiele. Im ersten Fall veröffentlicht ein Unternehmen eine ROA, die ermächtigt AS64500 für 192.0.2.0/24, aber AS64510 meldet den Präfix. Die Route ist ungültig, weil der Ursprung mit der Autorisierung konfliktiert. Im zweiten Fall hat das Unternehmen keine ROA veröffentlicht, und AS64500 meldet das Präfix. Die Route wurde nicht gefunden, weil keine Berechtigung zum Auswerten vorhanden ist.
Diese Unterschiede sind wichtig bei der Erstellung von Routing-Regeln. Viele Netzwerke behandeln ungültige Routen besonders, da eine vorhandene Autorisierung darauf hinweist, dass der Ressourceninhaber einen spezifischen Erwartungen ausgedrückt hat. Nicht gefunden-Routen können überwacht werden, eine geringere Präferenz erhalten oder entsprechend der lokalen Richtlinie akzeptiert werden. Jedes Netzwerk entscheidet selbst, wie das Ergebnis angewandt wird.
Netzbetreiber sollten auch daran denken, dass Validierungsergebnisse vorübergehend variieren können, während Repositorien und Validator aktualisiert werden. Wenn ein ROA erst kürzlich erstellt oder geändert wurde, können verschiedene Tools unterschiedliche Zustände anzeigen, bis das Update durch das Validierungssystem propagiert hat.
Warum kann eine rechtmäßige Route ungültig werden?
Der häufigste Grund ist eine Änderung des ASNs. Ein Unternehmen kann ursprünglich einen Präfix von einem ASN, der von einem Upstream- oder fördernden Organisations bereitgestellt wird, ankündigen und später den Präfix auf seinen eigenen ASN verschieben. Wenn die ROA den alten Ursprung weiterhin autorisiert, wird die neue Ankündigung ungültig.
Ein zweiter Grund ist eine falsche maximale Präfixlänge. Eine Organisation kann eine /20, ein ROA mit einer maximalen Länge von /20, und später zwei /21 Route für Traffic Engineering. Diese weiter spezifischen Ankündigungen können nicht durch die ursprüngliche Berechtigung abgedeckt sein. Die BGP-Konfiguration kann beabsichtigt sein, aber das RPKI-Richtlinienmodell ist für das neue Design zu restriktiv.
IPv4-Übertragungen können ähnliche Probleme verursachen. Während einer Übertragung können der administrative Inhaber und die Routing-Quelle zu unterschiedlichen Zeiten geändert werden. Wenn die Autorisierung des vorherigen Inhabers aktiv bleibt, während der neue Inhaber den Präfix von einem anderen ASN meldet, kann der Übergang einen ungültigen Zustand erzeugen.
Stumme Datensätze, falsche Netzwerkgrenzen und Missverständnisse über die Rolle des Verkehrsanbieters sind andere häufige Ursachen. Ein Anbieter kann eine Route eines Kunden tragen, ohne der ursprüngliche ASN zu sein. Die ROA muss normalerweise den ASN autorisieren, der als Routenursprung angezeigt wird, nicht einfach den Träger, der den Datenverkehr transportiert.
Wie man ein RPKI-Invalid-Ergebnis behebt
Beginnen Sie damit, das genaue Präfix und die Ursprungs-ASN anzuzeigen, die in der BGP-Bekanntgabe angezeigt werden. Verlassen Sie sich nicht auf eine verkürzte Anzeige oder ein vorheriges Konfigurationsdokument. Bestätigen Sie das Adressfamilie, Präfixlänge und Ursprung, wie von mindestens einem zuverlässigen Routing-Monitor beobachtet.
Als nächstes die aktiven ROAs für diesen Präfix überprüfen. Die autorisierte ASN und die maximale Präfixlänge prüfen. Wenn die Ursprungs-ASN nicht übereinstimmt, ermitteln, ob der Routen oder die Autorisierung falsch ist. Wenn die ASN korrekt ist, prüfen, ob das angekündigte Präfix spezifischer ist als die erlaubte maximale Länge.
Überprüfen Sie die jüngsten Änderungen. Suchen Sie nach einer ASN-Migration, Änderung des Upstream-Anbieters, IPv4-Übertragung, IPv6-Bereitstellung, Rechenzentrumsumzug, Änderung der Routenaggregation oder BGP-Richtlinienaktualisierung. Die meisten berechtigten Invalid-Ergebnisse können mit einer kürzlich vorgenommenen Änderung zusammenhängen, die nicht in der RPKI-Verwaltung widergespiegelt wurde.
Wenn die ROA falsch ist, aktualisieren Sie sie über den zuständigen Regionalen Internet-Register, den fördernden LIR oder das RPKI-Verwaltungssystem. Wenn die BGP-Ankündigung falsch ist, korrigieren Sie stattdessen die Routenpolitik. Lösen Sie keinen Routing-Fehler durch das Veröffentlichen einer unnotwendig breiten ROA, da dies Ankündigungen autorisieren könnte, die niemals beabsichtigt waren.
Nach der Korrektur wird Zeit für die Aktualisierung des Repositorys und des Validators benötigt. Prüfen Sie das Ergebnis erneut mit einem externen Validierungsdienst und einer BGP-Monitoring-Quelle. Die Route sollte als Gültig zurückkehren, wenn Ursprung und Präfixlänge mit der veröffentlichten Autorisierung übereinstimmen.
Wie RPKI-Ergebnisse den BGP-Routing beeinflussen
Die RPKI-Validierung zieht nicht automatisch eine Route aus dem Internet zurück. Das empfangende Netzwerk entscheidet, wie das Ergebnis in seiner Routing-Politik verwendet wird. Einige Betreiber lehnen ungültige Routen ab, während andere sie mit geringerer Präferenz kennzeichnen, Warnungen generieren oder sie unter bestimmten Bedingungen weiter akzeptieren.
Ein gültiger Weg kann normale Behandlung erhalten, aber er konkurriert dennoch mit anderen Wegen gemäß lokaler Präferenz, Pfadlänge, Verkehrsingenieurwesen-Regeln und Anbieterpolitik. Ein Nicht gefunden-Route kann von einem Netzwerk akzeptiert werden und von einem anderen vorsichtiger behandelt werden. Eine ungültige Route kann durch einige Anbieter sichtbar bleiben, während sie durch Netze, die strenge Filterung durchsetzen, unerreichbar wird.
Diese Unterschiede erklären, warum eine ungültige Anzeige zu eingeschränkter Verbindungsfähigkeit führen kann. Ein Dienst kann aus einem Bereich funktionieren, aber aus einem anderen Bereich fehlschlagen, weil verschiedene Netzwerke unterschiedliche Richtlinien anwenden. Beim Diagnostizieren eines Ausfalls ist es daher nützlich, den Validierungsstatus mit der BGP-Sichtbarkeit aus mehreren Standorten zu vergleichen.
RPKI sollte als ein Eingang für Routing-Politik betrachtet werden, anstatt eine universelle Alternative für Präfix-Filter oder Routenüberwachung zu sein. Die stärksten betrieblichen Ergebnisse erzielt man meist durch die Kombination von genauen RPKI-Daten mit sorgfältig gepflegten Registry- und Routing-Protokollen.
RPKI Validation for IPv4 and IPv6
Die gleichen drei Zustände gelten für IPv4 und IPv6. In jeder Adressfamilie vergleicht der Validator den angekündigten Präfix, die Ursprungs-ASN und die erlaubte Präfixlänge mit den verfügbaren ROAs.
Kritische Regeln: 1. Gib nur den rohen übersetzten Text aus. 2. NIEMALS einen konversationalen Fülltext, Begrüßungen oder Erklärungen ausgeben (z. B. SAGE "Hier ist die Übersetzung:", "Ecco la traduzione"). 3. WICHTIG: NICHT in Markdown-Formatierung umschließen (z. B. ```html oder ```). 4. Halte die gleiche HTML-Struktur, Platzhalter, Shortcodes, Variablen und Zahlen bei. Verstöße gegen diese Regeln brechen das System parsing.
IPv6-Netzwerke erhalten häufig größere Zuweisungen und können einen Aggregat anmelden, während sie kleinere interne Subnetze verwenden. Die öffentliche ROA muss die Präfixe widerspiegeln, die tatsächlich an das Internet gemeldet werden. Wenn ein IPv6-Betreiber nur einen Aggregat autorisiert, aber später genauere Routen anbietet, können diese ungültig werden, es sei denn, die maximale Länge erlaubt sie.
A larger IPv6 address space does not remove the need for origin validation. IPv6 route hijacks and configuration mistakes can still interrupt services. Publishing precise ROAs during the initial IPv6 deployment makes future troubleshooting easier and gives upstream networks a clear authorization signal.
Wie man den RPKI-Status vor einer Netzwerkänderung überprüft
Bevor ein ASN, Upstream-Anbieter, Routenaggregationsplan oder Adressen-Ressourcenhalter geändert wird, wird der aktuelle RPKI-Zustand protokolliert. Bestätigen Sie, welcher ASN den Präfix derzeit ursprünglich hat und ob die Anmeldung gültig, ungültig oder nicht gefunden ist.
Nach der Erstellung des neuen Routenplans vergleichen Sie die erwarteten Ursprünge und Präfixlängen mit den geplanten ROAs. Wenn sich der Ursprung ändern wird, veröffentlichen oder aktualisieren Sie die Berechtigung vor dem Ankündigen der neuen Route, sobald der operative Zeitplan es ermöglicht. Während einer kontrollierten Migration können temporäre Berechtigungen für beide Ursprünge angemessen sein, jedoch sollte die Vereinbarung dokumentiert werden und die alte Berechtigung entfernt werden, sobald der Übergang abgeschlossen ist.
Eine technische Vorkontrolle kann auch verwandte Unzulänglichkeiten aufdecken. Die IP-Ressourcen-Bereitschaftsprüfung kann die öffentliche Registrierungsinformation, Ursprungs-ASN-Daten, Routenobjekte, RPKI-Status und BGP-Sichtbarkeit für einen öffentlichen IPv4- oder IPv6-Präfix überprüfen. Es handelt sich um eine technische Prüfung und nicht um Beweis der Eigentumsrechte oder Übertragungsfähigkeit, daher bleiben vertragliche und registrierungsbezogene Überprüfungen erforderlich.
Häufig gestellte Fragen zum RPKI-Status
Ist RPKI nicht gefunden, das gleiche wie ungültig?
Nr. Nicht gefunden bedeutet, dass kein passender ROA gefunden wurde. Ungültig bedeutet, dass ein relevanter ROA existiert, aber die BGP-Ankündigung konfliktiert damit. Ungültig erfordert normalerweise eine dringendere Untersuchung, da es sich um einen direkten Widerspruch mit der veröffentlichten Berechtigung handelt.
Kann eine gültige Route dennoch ein Problem haben?
Ja. Gültig bestätigt nur, dass der Ursprungs-ASN und Präfixlänge mit einem anwendbaren ROA übereinstimmen. Es überprüft nicht jeden Teil des BGP-Pfads, Anwendungsicherheit, IP-Reputation, rechtliche Eigentumsverhältnisse oder Dienstverfügbarkeit.
Warum ist meine Route nach dem Wechsel des Anbieters ungültig?
Das Ändern des Trägers allein erfordert möglicherweise keinen neuen ROA, wenn die Ausgangs-ASN gleich bleibt. Wenn jedoch die Änderung des Anbieters auch die Ausgangs-ASN verändert oder wenn der neue Anbieter ein anderes Präfixlängen-Format annonciert, muss der ROA möglicherweise aktualisiert werden.
Wie lange dauert es, bis eine ROA-Änderung sichtbar wird?
Die Änderung muss vom zuständigen RPKI-System veröffentlicht und von Validatoren abgerufen werden. Es ist üblich, dass eine kurze Verzögerung auftritt. Bei einem Produktionswechsel sollten mehrere Validierungsquellen überprüft und Zeit für die Aktualisierungsintervalle eingeplant werden.
Sollte ich jede Nicht Gefundene Route ablehnen?
Das hängt von Ihrer Netzwerkrichtlinie und Risikomodell ab. „Nicht gefunden“ beweist nicht, dass eine Route falsch ist. Viele legitime Routen haben keinen ROA. Einige Netzwerke akzeptieren „Nicht gefunden“-Routen, während sie Überwachung oder geringere Präferenz anwenden; andere verwenden strengere Richtlinien für ausgewählte Umgebungen.
Kann RPKI sowohl IPv4 als auch IPv6 schützen?
Ja. RPKI unterstützt die Ursprungsautorisierung für beide Adressfamilien. Die praktische Konfiguration muss den Präfixen und Präfixlängen entsprechen, die jed Netzwerk tatsächlich annonciert.
CRITICAL RULES: 1. Output ONLY the raw translated text. 2. NEVER output conversational filler, greetings, or explanations (e.g., DO NOT say 'Here is the translation:', 'Ecco la traduzione'). 3. DO NOT wrap the output in markdown formatting (e.g., ```html or ```). 4. Keep the exact same HTML structure, placeholders, shortcodes, variables, and numbers. Violation of these rules will break the system parsing.
Diese Ergebnisse sind besonders wichtig während ASN-Migrationen, Anbieteränderungen, IPv4-Übertragungen, IPv6-Bereitstellungen und Netzwerkneugestaltungen. Ein legitimer Routenweg kann ungültig werden, wenn sich die BGP-Quelle ändert, aber die ROA nicht aktualisiert wird, oder wenn das Netzwerk Präfixe anbietet, die spezifischer sind als die erlaubte maximale Länge.
Für zuverlässige Betriebsabläufe überprüfen Sie den angekündigten Präfix, die Ursprungs-ASN und die maximale Präfixlänge gemeinsam. Halten Sie RPKI-Einträge mit dem tatsächlichen Routing-Entwurf synchron, überwachen Sie Änderungen nach der Veröffentlichung und untersuchen Sie ungültige Ergebnisse zeitnah. Nutzen Sie RPKI neben Registry-Einträgen, BGP-Überwachung, IRR-Daten und dokumentierter Änderungsverwaltung, anstatt es als vollständigen Ersatz für diese Systeme zu betrachten.
Wenn Sie die Serie fortsetzen möchten, ist der nächste nützliche Artikel How to Fix an RPKI Invalid Route, der detaillierter erläutert, wie man bei der Migration plant, überlappende Berechtigungen, Anbieterwechsel und praktische Validierungschecks durchführt.