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\u00e4fix zu urspr\u00fcnglich zu machen. Wenn ein Router eine Routenanmeldung erh\u00e4lt, kann er die Anmeldung mit der ver\u00f6ffentlichten RPKI-Berechtigung f\u00fcr diesen Adressbereich vergleichen.<\/p>\n\n\n\n
Das Ergebnis wird normalerweise als G\u00fcltig, Ung\u00fcltig oder Nicht gefunden angezeigt. Diese drei Bezeichnungen sind einfach, werden aber h\u00e4ufig missverstanden. Ein g\u00fcltiges Ergebnis bedeutet nicht, dass jedes Teil der Route perfekt ist. Ein ung\u00fcltiges Ergebnis bedeutet nicht immer, dass jemand das Netzwerk angreift. Ein Nicht gefunden-Ergebnis bedeutet nicht automatisch, dass die Annonce unsicher ist.<\/p>\n\n\n\n
Die Labels beschreiben nur die Beziehung zwischen einer BGP-Ank\u00fcndigung und den verf\u00fcgbaren Route Origin Authorization-Daten. Um das Ergebnis korrekt zu verstehen, m\u00fcssen Sie drei Details vergleichen: den angek\u00fcndigten IP-Pr\u00e4fix, die Ursprungs-ASN und die maximal zul\u00e4ssige Pr\u00e4fixl\u00e4nge gem\u00e4\u00df der Autorisierung.<\/p>\n\n\n\n
Dieser Artikel erkl\u00e4rt jeden RPKI-Status in praktischen Begriffen, zeigt, warum legitime Routen ung\u00fcltig werden k\u00f6nnen, und bietet einen Fehlerbehebungsprozess f\u00fcr 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?<\/a> und dann lesen Was ist ein ROA in RPKI?<\/a> f\u00fcr eine detaillierte Erkl\u00e4rung des Autorisierungsprotokolls selbst.<\/p>\n\n\n\n RPKI steht f\u00fcr Resource Public Key Infrastructure. Sie verbindet Internet-Nummer-Ressourcen mit kryptografisch signierten Autorisierungsdatens\u00e4tzen. Der Inhaber oder autorisierte Administrator eines IP-Prefixes kann eine ROA ver\u00f6ffentlichen, die besagt, dass eine bestimmte ASN berechtigt ist, diesen Prefix im BGP zu urspr\u00fcngen.<\/p>\n\n\n\n Ein Validator sammelt diese signierten Protokolle, pr\u00fcft deren Authentizit\u00e4t und erstellt ein validiertes Datensatz f\u00fcr 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\u00fcndigte Pr\u00e4fix durch eine Autorisierung abgedeckt? Ist der Ursprungs-ASN der in dieser Autorisierung aufgef\u00fchrte? Ist die L\u00e4nge des angek\u00fcndigten Pr\u00e4fixes innerhalb der erlaubten maximalen L\u00e4nge?<\/p>\n\n\n\n Die Antwort auf diese Fragen erzeugt den RPKI-Status. Der Status gilt f\u00fcr die Route-Origin-Befugnis, nicht f\u00fcr 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\u00fcgbar ist. Es handelt sich um ein fokussiertes Sicherheitssignal, das das Vertrauen in die Herkunft einer Route verbessert.<\/p>\n\n\n\n Eine Route ist RPKI-Valide<\/strong> wenn die BGP-Meldung von mindestens einem anwendbaren ROA abgedeckt ist, stimmt die Ursprungs-ASN mit der autorisierten ASN \u00fcberein und ist die angek\u00fcndigte Pr\u00e4fixl\u00e4nge durch den ROA's maximalen L\u00e4nge erlaubt. In praktischer Hinsicht ist der Weg mit der vom Ressourcenhalter ver\u00f6ffentlichten Routing-Erm\u00e4chtigung konsistent.<\/p>\n\n\n\n Zum Beispiel, nehmen Sie an, dass ein Unternehmen kontrolliert Ein g\u00fcltiges Ergebnis ist ein positives Signal, sollte aber nicht als vollst\u00e4ndige Garantie interpretiert werden. Der Weg kann immer noch einen falschen Pfad haben, eine schlechte Gesch\u00e4ftswertung, eine veraltete Registry-Beschreibung oder ein betriebliches Problem au\u00dferhalb der Ursprungsautorit\u00e4t haben. Netzwerkbetreiber kombinieren RPKI normalerweise mit BGP-Monitoring, Pr\u00e4fix-Filterung, Registry-Pr\u00fcfungen und Notfallreaktionsverfahren.<\/p>\n\n\n\n Ein g\u00fcltiger Status kann sich auch \u00e4ndern, wenn das Netzwerk wechselt. Wenn ein Unternehmen einen Pr\u00e4fix zu einem anderen ASN verschiebt, eine spezifischere Route anbietet oder seinen Adressplan \u00e4ndert, kann die vorhandene ROA m\u00f6glicherweise nicht mehr mit der neuen Anmeldung \u00fcbereinstimmen. RPKI spiegelt die aktuellen Berechtigungsdaten wider und muss daher als Teil der normalen Netzwerkbetriebsvorg\u00e4nge gepflegt werden.<\/p>\n\n\n\n Eine Route ist RPKI ung\u00fcltig<\/strong> wenn eine anwendbare Berechtigung besteht, aber die BGP-Ank\u00fcndigung damit im Konflikt steht. Der Konflikt betrifft normalerweise eines von zwei Dingen: der Ursprungs-ASN ist nicht berechtigt, oder der angek\u00fcndigte Pr\u00e4fix ist spezifischer als die maximal zul\u00e4ssige L\u00e4nge gem\u00e4\u00df dem ROA.<\/p>\n\n\n\n Zum Beispiel darf ein ROA Ung\u00fcltig bedeutet nicht unbedingt, dass ein b\u00f6swilliger Diebstahl stattfindet. Viele ung\u00fcltige Routen werden durch gew\u00f6hnliche Betriebsfehler verursacht. Ein Ingenieur kann vergessen, eine ROA nach einer ASN-Migration zu aktualisieren, ein Anbieter kann ein Kundenpr\u00e4fix mit dem falschen Ursprung ank\u00fcndigen, oder das Netzwerk kann mehr-spezifische Pr\u00e4fixe verwenden, ohne die maximale L\u00e4nge zu \u00e4ndern.<\/p>\n\n\n\n Gleichzeitig sollte ein ung\u00fcltiges Ergebnis nicht ignoriert werden. Es kann auf eine unautorisierte Ank\u00fcndigung, einen Routenleak mit einer unerwarteten Quelle oder eine Konfigurationsfehler hinweisen, der dazu f\u00fchren kann, dass der Pr\u00e4fix \u00fcber 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.<\/p>\n\n\n\n Eine Route ist RPKI nicht gefunden<\/strong> wenn der Validator keinen passenden ROA f\u00fcr den angek\u00fcndigten Pr\u00e4fix finden kann. Es gibt keine ver\u00f6ffentlichte Autorisierung, die die Ursprungs-ASN f\u00fcr diesen Weg best\u00e4tigen oder widerlegen kann.<\/p>\n\n\n\n Nicht gefunden wird manchmal als \u201eunbekannt\u201c bezeichnet, weil das Validierungssystem nicht genug Berechtigungsinformationen hat, um zu einem Ergebnis zu gelangen. Es bedeutet nicht, dass die Route ung\u00fcltig ist, und es beweist auch nicht, dass der Ursprung nicht berechtigt ist. Viele legitime Pr\u00e4fixe im Internet haben immer noch keinen ROA, entweder weil der Ressourceninhaber noch keinen erstellt hat oder weil die Berechtigung noch nicht f\u00fcr den Validator sichtbar geworden ist.<\/p>\n\n\n\n Die Abwesenheit einer ROA verringert die Menge an Informationen, die Netzwerken zur Verf\u00fcgung stehen, um den Weg zu validieren. Wenn ein nicht autorisierter ASN den gleichen Pr\u00e4fix annonciert, kann ein Netzwerk, das beide Annoncen sieht, Schwierigkeiten haben, den legimitimen Weg von dem falschen mit RPKI allein zu unterscheiden.<\/p>\n\n\n\n Ressourcentr\u00e4ger sollten normalerweise genaue ROAs f\u00fcr Pr\u00e4fixe ver\u00f6ffentlichen, die \u00f6ffentlich angek\u00fcndigt werden, insbesondere wenn diese Pr\u00e4fixe wichtige Dienste unterst\u00fctzen. Jedoch sollten Betreiber darauf verzichten, eine hastig oder zu weitreichend formulierte Autorisierung zu erstellen, nur um \"Not Found\" in \"Valid\" zu \u00e4ndern. Eine schlecht konfigurierte ROA kann eine legitime Route in \"Invalid\" umwandeln, was einen unmittelbareren betrieblichen Einfluss haben kann.<\/p>\n\n\n\n Die wichtigste Unterscheidung ist, dass Ung\u00fcltig ist ein Konflikt<\/strong>, w\u00e4hrend Nicht gefunden ist das Fehlen von Autorisierungsdaten<\/strong>. Ung\u00fcltig bedeutet, dass der Validator eine relevante ROA gefunden hat, aber die Route damit nicht \u00fcbereinstimmt. Nicht gefunden bedeutet, dass keine anwendbare ROA gefunden wurde.<\/p>\n\n\n\n Betrachten Sie zwei Beispiele. Im ersten Fall ver\u00f6ffentlicht ein Unternehmen eine ROA, die erm\u00e4chtigt Diese Unterschiede sind wichtig bei der Erstellung von Routing-Regeln. Viele Netzwerke behandeln ung\u00fcltige Routen besonders, da eine vorhandene Autorisierung darauf hinweist, dass der Ressourceninhaber einen spezifischen Erwartungen ausgedr\u00fcckt hat. Nicht gefunden-Routen k\u00f6nnen \u00fcberwacht werden, eine geringere Pr\u00e4ferenz erhalten oder entsprechend der lokalen Richtlinie akzeptiert werden. Jedes Netzwerk entscheidet selbst, wie das Ergebnis angewandt wird.<\/p>\n\n\n\n Netzbetreiber sollten auch daran denken, dass Validierungsergebnisse vor\u00fcbergehend variieren k\u00f6nnen, w\u00e4hrend Repositorien und Validator aktualisiert werden. Wenn ein ROA erst k\u00fcrzlich erstellt oder ge\u00e4ndert wurde, k\u00f6nnen verschiedene Tools unterschiedliche Zust\u00e4nde anzeigen, bis das Update durch das Validierungssystem propagiert hat.<\/p>\n\n\n\n Der h\u00e4ufigste Grund ist eine \u00c4nderung des ASNs. Ein Unternehmen kann urspr\u00fcnglich einen Pr\u00e4fix von einem ASN, der von einem Upstream- oder f\u00f6rdernden Organisations bereitgestellt wird, ank\u00fcndigen und sp\u00e4ter den Pr\u00e4fix auf seinen eigenen ASN verschieben. Wenn die ROA den alten Ursprung weiterhin autorisiert, wird die neue Ank\u00fcndigung ung\u00fcltig.<\/p>\n\n\n\n Ein zweiter Grund ist eine falsche maximale Pr\u00e4fixl\u00e4nge. Eine Organisation kann eine IPv4-\u00dcbertragungen k\u00f6nnen \u00e4hnliche Probleme verursachen. W\u00e4hrend einer \u00dcbertragung k\u00f6nnen der administrative Inhaber und die Routing-Quelle zu unterschiedlichen Zeiten ge\u00e4ndert werden. Wenn die Autorisierung des vorherigen Inhabers aktiv bleibt, w\u00e4hrend der neue Inhaber den Pr\u00e4fix von einem anderen ASN meldet, kann der \u00dcbergang einen ung\u00fcltigen Zustand erzeugen.<\/p>\n\n\n\n Stumme Datens\u00e4tze, falsche Netzwerkgrenzen und Missverst\u00e4ndnisse \u00fcber die Rolle des Verkehrsanbieters sind andere h\u00e4ufige Ursachen. Ein Anbieter kann eine Route eines Kunden tragen, ohne der urspr\u00fcngliche ASN zu sein. Die ROA muss normalerweise den ASN autorisieren, der als Routenursprung angezeigt wird, nicht einfach den Tr\u00e4ger, der den Datenverkehr transportiert.<\/p>\n\n\n\n Beginnen Sie damit, das genaue Pr\u00e4fix und die Ursprungs-ASN anzuzeigen, die in der BGP-Bekanntgabe angezeigt werden. Verlassen Sie sich nicht auf eine verk\u00fcrzte Anzeige oder ein vorheriges Konfigurationsdokument. Best\u00e4tigen Sie das Adressfamilie, Pr\u00e4fixl\u00e4nge und Ursprung, wie von mindestens einem zuverl\u00e4ssigen Routing-Monitor beobachtet.<\/p>\n\n\n\n Als n\u00e4chstes die aktiven ROAs f\u00fcr diesen Pr\u00e4fix \u00fcberpr\u00fcfen. Die autorisierte ASN und die maximale Pr\u00e4fixl\u00e4nge pr\u00fcfen. Wenn die Ursprungs-ASN nicht \u00fcbereinstimmt, ermitteln, ob der Routen oder die Autorisierung falsch ist. Wenn die ASN korrekt ist, pr\u00fcfen, ob das angek\u00fcndigte Pr\u00e4fix spezifischer ist als die erlaubte maximale L\u00e4nge.<\/p>\n\n\n\n \u00dcberpr\u00fcfen Sie die j\u00fcngsten \u00c4nderungen. Suchen Sie nach einer ASN-Migration, \u00c4nderung des Upstream-Anbieters, IPv4-\u00dcbertragung, IPv6-Bereitstellung, Rechenzentrumsumzug, \u00c4nderung der Routenaggregation oder BGP-Richtlinienaktualisierung. Die meisten berechtigten Invalid-Ergebnisse k\u00f6nnen mit einer k\u00fcrzlich vorgenommenen \u00c4nderung zusammenh\u00e4ngen, die nicht in der RPKI-Verwaltung widergespiegelt wurde.<\/p>\n\n\n\n Wenn die ROA falsch ist, aktualisieren Sie sie \u00fcber den zust\u00e4ndigen Regionalen Internet-Register, den f\u00f6rdernden LIR oder das RPKI-Verwaltungssystem. Wenn die BGP-Ank\u00fcndigung falsch ist, korrigieren Sie stattdessen die Routenpolitik. L\u00f6sen Sie keinen Routing-Fehler durch das Ver\u00f6ffentlichen einer unnotwendig breiten ROA, da dies Ank\u00fcndigungen autorisieren k\u00f6nnte, die niemals beabsichtigt waren.<\/p>\n\n\n\n Nach der Korrektur wird Zeit f\u00fcr die Aktualisierung des Repositorys und des Validators ben\u00f6tigt. Pr\u00fcfen Sie das Ergebnis erneut mit einem externen Validierungsdienst und einer BGP-Monitoring-Quelle. Die Route sollte als G\u00fcltig zur\u00fcckkehren, wenn Ursprung und Pr\u00e4fixl\u00e4nge mit der ver\u00f6ffentlichten Autorisierung \u00fcbereinstimmen.<\/p>\n\n\n\n Die RPKI-Validierung zieht nicht automatisch eine Route aus dem Internet zur\u00fcck. Das empfangende Netzwerk entscheidet, wie das Ergebnis in seiner Routing-Politik verwendet wird. Einige Betreiber lehnen ung\u00fcltige Routen ab, w\u00e4hrend andere sie mit geringerer Pr\u00e4ferenz kennzeichnen, Warnungen generieren oder sie unter bestimmten Bedingungen weiter akzeptieren.<\/p>\n\n\n\n Ein g\u00fcltiger Weg kann normale Behandlung erhalten, aber er konkurriert dennoch mit anderen Wegen gem\u00e4\u00df lokaler Pr\u00e4ferenz, Pfadl\u00e4nge, Verkehrsingenieurwesen-Regeln und Anbieterpolitik. Ein Nicht gefunden-Route kann von einem Netzwerk akzeptiert werden und von einem anderen vorsichtiger behandelt werden. Eine ung\u00fcltige Route kann durch einige Anbieter sichtbar bleiben, w\u00e4hrend sie durch Netze, die strenge Filterung durchsetzen, unerreichbar wird.<\/p>\n\n\n\n Diese Unterschiede erkl\u00e4ren, warum eine ung\u00fcltige Anzeige zu eingeschr\u00e4nkter Verbindungsf\u00e4higkeit f\u00fchren 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\u00fctzlich, den Validierungsstatus mit der BGP-Sichtbarkeit aus mehreren Standorten zu vergleichen.<\/p>\n\n\n\n RPKI sollte als ein Eingang f\u00fcr Routing-Politik betrachtet werden, anstatt eine universelle Alternative f\u00fcr Pr\u00e4fix-Filter oder Routen\u00fcberwachung zu sein. Die st\u00e4rksten betrieblichen Ergebnisse erzielt man meist durch die Kombination von genauen RPKI-Daten mit sorgf\u00e4ltig gepflegten Registry- und Routing-Protokollen.<\/p>\n\n\n\n Die gleichen drei Zust\u00e4nde gelten f\u00fcr IPv4 und IPv6. In jeder Adressfamilie vergleicht der Validator den angek\u00fcndigten Pr\u00e4fix, die Ursprungs-ASN und die erlaubte Pr\u00e4fixl\u00e4nge mit den verf\u00fcgbaren ROAs.<\/p>\n\n\n\n Kritische Regeln:\n1. Gib nur den rohen \u00fcbersetzten Text aus.\n2. NIEMALS einen konversationalen F\u00fclltext, Begr\u00fc\u00dfungen oder Erkl\u00e4rungen ausgeben (z. B. SAGE \"Hier ist die \u00dcbersetzung:\", \"Ecco la traduzione\").\n3. WICHTIG: NICHT in Markdown-Formatierung umschlie\u00dfen (z. B. ```html oder ```).\n4. Halte die gleiche HTML-Struktur, Platzhalter, Shortcodes, Variablen und Zahlen bei.\nVerst\u00f6\u00dfe gegen diese Regeln brechen das System parsing.<\/p>\n\n\n\n IPv6-Netzwerke erhalten h\u00e4ufig gr\u00f6\u00dfere Zuweisungen und k\u00f6nnen einen Aggregat anmelden, w\u00e4hrend sie kleinere interne Subnetze verwenden. Die \u00f6ffentliche ROA muss die Pr\u00e4fixe widerspiegeln, die tats\u00e4chlich an das Internet gemeldet werden. Wenn ein IPv6-Betreiber nur einen Aggregat autorisiert, aber sp\u00e4ter genauere Routen anbietet, k\u00f6nnen diese ung\u00fcltig werden, es sei denn, die maximale L\u00e4nge erlaubt sie.<\/p>\n\n\n\n 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.<\/p>\n\n\n\n Bevor ein ASN, Upstream-Anbieter, Routenaggregationsplan oder Adressen-Ressourcenhalter ge\u00e4ndert wird, wird der aktuelle RPKI-Zustand protokolliert. Best\u00e4tigen Sie, welcher ASN den Pr\u00e4fix derzeit urspr\u00fcnglich hat und ob die Anmeldung g\u00fcltig, ung\u00fcltig oder nicht gefunden ist.<\/p>\n\n\n\n Nach der Erstellung des neuen Routenplans vergleichen Sie die erwarteten Urspr\u00fcnge und Pr\u00e4fixl\u00e4ngen mit den geplanten ROAs. Wenn sich der Ursprung \u00e4ndern wird, ver\u00f6ffentlichen oder aktualisieren Sie die Berechtigung vor dem Ank\u00fcndigen der neuen Route, sobald der operative Zeitplan es erm\u00f6glicht. W\u00e4hrend einer kontrollierten Migration k\u00f6nnen tempor\u00e4re Berechtigungen f\u00fcr beide Urspr\u00fcnge angemessen sein, jedoch sollte die Vereinbarung dokumentiert werden und die alte Berechtigung entfernt werden, sobald der \u00dcbergang abgeschlossen ist.<\/p>\n\n\n\nWas ist RPKI-Validierung?<\/h2>\n\n\n\n
Was bedeutet RPKI-Valid?<\/h2>\n\n\n\n
203.0.113.0\/24<\/code> und ver\u00f6ffentlicht eine ROA, die erm\u00e4chtigt AS64500<\/code> hervorbringen, dass \/24<\/code>. Wenn das Unternehmen bekanntgibt 203.0.113.0\/24<\/code> von AS64500<\/code>, die Ank\u00fcndigung sollte \"Valide\" zur\u00fcckgeben. Das gilt auch f\u00fcr ein IPv6-Beispiel wie 2001:db8:1200::\/48<\/code> wenn der richtige ASN und die erlaubte Pr\u00e4fixl\u00e4nge verwendet werden.<\/p>\n\n\n\nWas bedeutet RPKI ung\u00fcltig?<\/h2>\n\n\n\n
AS64500<\/code> entstehen 198.51.100.0\/24<\/code>. Wenn AS64510<\/code> meldet dasselbe Pr\u00e4fix, stimmt die Ursprungs-ASN nicht \u00fcberein und der Weg wird ung\u00fcltig. Das Ergebnis kann auch auftreten, wenn AS64500<\/code> ist berechtigt f\u00fcr die \/24<\/code> aber k\u00fcndigt an 198.51.100.0\/25<\/code> w\u00e4hrend die ROA keine Pr\u00e4fixe zul\u00e4sst, die spezifisch sind.<\/p>\n\n\n\nWas bedeutet \"RPKI nicht gefunden\"?<\/h2>\n\n\n\n
Der Unterschied zwischen ung\u00fcltig und nicht gefunden<\/h2>\n\n\n\n
AS64500<\/code> f\u00fcr 192.0.2.0\/24<\/code>, aber AS64510<\/code> meldet den Pr\u00e4fix. Die Route ist ung\u00fcltig, weil der Ursprung mit der Autorisierung konfliktiert. Im zweiten Fall hat das Unternehmen keine ROA ver\u00f6ffentlicht, und AS64500<\/code> meldet das Pr\u00e4fix. Die Route wurde nicht gefunden, weil keine Berechtigung zum Auswerten vorhanden ist.<\/p>\n\n\n\nWarum kann eine rechtm\u00e4\u00dfige Route ung\u00fcltig werden?<\/h2>\n\n\n\n
\/20<\/code>, ein ROA mit einer maximalen L\u00e4nge von \/20<\/code>, und sp\u00e4ter zwei \/21<\/code> Route f\u00fcr Traffic Engineering. Diese weiter spezifischen Ank\u00fcndigungen k\u00f6nnen nicht durch die urspr\u00fcngliche Berechtigung abgedeckt sein. Die BGP-Konfiguration kann beabsichtigt sein, aber das RPKI-Richtlinienmodell ist f\u00fcr das neue Design zu restriktiv.<\/p>\n\n\n\nWie man ein RPKI-Invalid-Ergebnis behebt<\/h2>\n\n\n\n
Wie RPKI-Ergebnisse den BGP-Routing beeinflussen<\/h2>\n\n\n\n
RPKI Validation for IPv4 and IPv6<\/h2>\n\n\n\n
Wie man den RPKI-Status vor einer Netzwerk\u00e4nderung \u00fcberpr\u00fcft<\/h2>\n\n\n\n