De RPKI-validatie is nu een belangrijk onderdeel van de moderne BGP-routingsbeveiliging. Het helpt netwerkbeheerders om te bepalen of een Autonome Systeemnummer (ASN) geautoriseerd is om een bepaald IPv4- of IPv6-voorvoegsel te origineren. Wanneer een router een routeaanmelding ontvangt, kan het de aanmelding vergelijken met de gepubliceerde RPKI-vergunning voor dat adresbereik.
Het resultaat wordt meestal weergegeven als Geldig, Ongeldig of Niet gevonden. Deze drie labels zijn eenvoudig, maar worden vaak verkeerd begrepen. Een geldig resultaat betekent niet dat elk deel van de route perfect is. Een ongeldig resultaat betekent niet altijd dat iemand het netwerk aanvalt. Een niet gevonden resultaat betekent niet automatisch dat de aankondiging onveilig is.
De labels beschrijven alleen de relatie tussen een BGP-announcment en de beschikbare Route Origin Authorization-gegevens. Om het resultaat correct te begrijpen, moet u drie details vergelijken: de aangekondigde IP-prefix, de origin ASN en de maximale prefixlengte die door de autorisatie is toegestaan.
Deze artikel legt elke RPKI-status in praktische termen uit, toont waarom legitieme routes ongeldig kunnen worden en biedt een probleemoplossingsproces voor netwerkbeheerders die hun eigen ASN, IPv4-resources, IPv6-toewijzingen of upstream-routing beheren. Als u nieuw bent met het onderwerp, begin dan met onze gids naar Wat is RPKI? en dan lezen Wat Is een ROA in RPKI? voor een gedetailleerde uitleg van de autorisatiegegevens zelf.
Wat is RPKI-validatie?
RPKI staat voor Resource Public Key Infrastructure. Het verbindt internet-nummerbronnen met cryptografisch ondertekende autorisatiegegevens. De eigenaar of geautoriseerde beheerder van een IP-voorvoegsel kan een ROA publiceren die aangeeft dat een bepaalde ASN toegestaan is om dat voorvoegsel in BGP te origineren.
Een validator verzamelt deze ondertekende records, controleert hun authenticiteit en maakt een geverifieerd dataset voor netwerkbeheerders. Wanneer een BGP-route wordt ontvangen, vergelijkt het routing-systeem van de beheerder de route met die dataset. De vergelijking stelt drie basisvragen: Is het aangekondigde voorvoegsel gedekt door een toestemming? Is de oorsprong ASN de in die toestemming vermelde? Is de lengte van het aangekondigde voorvoegsel binnen de toegestane maximumlengte?
Het antwoord op die vragen levert de RPKI-status op. De status geldt voor route-origineverificatie, niet voor elk attribuut van het BGP-pad. RPKI bewijst niet dat alle tussenliggende netwerken correct zijn, dat het verkeer het beste pad volgt, of dat het adresresource wettig beschikbaar is voor verkoop. Het is een gerichte beveiligingssignaal dat het vertrouwen in de oorsprong van een route verbetert.
Wat betekent RPKI geldig?
Een route is RPKI geldig wanneer de BGP-annunciatie wordt gedekt door ten minste één toepasselijke ROA, komt de oorsprong ASN overeen met de geautoriseerde ASN en is de aangemelde voorvoegsel lengte toegestaan door de maximale lengte van de ROA. In praktische termen is de route consistent met de door de resourcehouder gepubliceerde routing autorisatie.
Bijvoorbeeld, stel dat een bedrijf controleert 203.0.113.0/24 en publiceert een ROA die machtiging verleent AS64500 afkomstig zijn dat /24. Als het bedrijf aankondigt 203.0.113.0/24 van AS64500, de aankondiging moet geldig retourneren. Hetzelfde geldt voor een IPv6-voorbeeld zoals 2001:db8:1200::/48 wanneer het juiste ASN en toegestane voorvoegsel lengte worden gebruikt.
Een geldig resultaat is een positief signaal, maar moet niet worden geïnterpreteerd als een volledige garantie. De route kan nog steeds een verkeerde pad hebben, een slechte zakelijke reputatie, een verouderde registerbeschrijving of een operationeel probleem buiten de oorsprong autorisatie hebben. Netwerkbeheerders combineren RPKI normaal gesproken met BGP-monitoring, prefix filtering, registercontroles en incidentresponsprocedures.
Een geldige status kan ook veranderen wanneer het netwerk verandert. Als een bedrijf een prefix naar een ander ASN verplaatst, begint met het aankondigen van een meer-specifieke route of zijn adresplan wijzigt, kan de bestaande ROA mogelijk niet meer overeenkomen met de nieuwe aankondiging. RPKI weergeeft de huidige autorisatiegegevens, dus het moet onderdeel zijn van de normale netwerkbedrijfsvoering.
Wat betekent RPKI ongeldig?
Een route is RPKI ongeldig wanneer er een toepasselijke autorisatie bestaat, maar de BGP-announcemet in conflict is met deze. Het conflict betreft meestal één van de volgende twee dingen: de oorsprongs ASN is niet geautoriseerd, of het aangekondigde voorvoegsel is specifieker dan de maximale lengte die door de ROA is toegestaan.
Bijvoorbeeld mag een ROA autoriseren AS64500 ontstaan 198.51.100.0/24. Als AS64510 meldt dat dezelfde voorvoegsel, de oorsprong ASN komt niet overeen en de route wordt ongeldig. Het resultaat kan ook voorkomen wanneer AS64500 is geautoriseerd voor de /24 maar annouce 198.51.100.0/25 terwijl de ROA geen voorvoegsels toestaat die specifiek zijn.
Ongeldig betekent niet per se dat er een kwajonge inname plaatsvindt. Veel ongeldige routes worden veroorzaakt door gewone operationele fouten. Een ingenieur kan bijvoorbeeld vergeten om een ROA te updaten na een ASN-migratie, een provider kan een klantprefix met de verkeerde oorsprong aankondigen, of het netwerk begint meer-specifieke voorvoegsels te gebruiken zonder de maximumlengte te wijzigen.
Tegelijkertijd mag een ongeldig resultaat niet worden genegeerd. Het kan wijzen op een onbevoegde aankondiging, een routeleak met een onverwachte oorsprong of een configuratiefout die ervoor zorgt dat het voorvoegsel via netwerken met strikte RPKI-filtering onbereikbaar is. Het juiste antwoord is om het resultaat snel te onderzoeken en te vergelijken met het beoogde routingontwerp.
Wat betekent RPKI niet gevonden?
Een route is RPKI niet gevonden wanneer de validator geen toepasselijke ROA kan vinden voor het aangekondigde voorvoegsel. Er is geen gepubliceerd authentificatie dat kan bevestigen of ontkrachten de oorsprong ASN voor die route.
Niet gevonden wordt soms "onbekend" genoemd, omdat het validatiesysteem niet voldoende autorisatie-informatie heeft om tot een conclusie te komen. Het betekent niet dat de route ongeldig is, en bewijst ook niet dat de oorsprong onbevoegd is. Veel legitieme voorvoegsels op het internet hebben nog steeds geen ROA, ofwel omdat de resource-houder er geen heeft gemaakt of omdat de autorisatie nog niet zichtbaar is geworden voor de validator.
Het ontbreken van een ROA vermindert het aantal beschikbare informatie voor netwerken die de route willen valideren. Als een onbevoegde ASN hetzelfde voorvoegsel aankondigt, kan een netwerk dat beide aankondigingen ziet moeite hebben om de legitieme route te onderscheiden van de valse met alleen RPKI.
Belanghebbenden moeten normaal gesproken nauwkeurige ROAs publiceren voor de prefixen die ze openbaar aankondigen, vooral wanneer deze prefixen belangrijke diensten ondersteunen. Toch moeten operatoren vermijden om een haastig of te breed geautoriseerd ROA aan te maken alleen om 'Not Found' in 'Valid' te veranderen. Een slecht geconfigureerd ROA kan een legitieme route ongeldig maken, wat een directere operationele impact kan hebben.
Het verschil tussen ongeldig en niet gevonden
De belangrijkste onderscheid is dat Ongeldig is een conflict, terwijl Niet gevonden is het ontbreken van autorisatiegegevens. Ongeldig betekent dat de validator een relevante ROA heeft gevonden, maar de route voldoet hieraan niet. Niet gevonden betekent dat er geen toepasselijke ROA is gevonden.
Beschouw twee voorbeelden. In het eerste geval publiceert een bedrijf een ROA die autoriseert AS64500 voor 192.0.2.0/24, maar AS64510 maakt de voorvoegsel bekend. De route is ongeldig omdat de oorsprong in conflict is met de autorisatie. In de tweede, heeft het bedrijf geen ROA gepubliceerd, en AS64500 maakt het voorvoegsel bekend. De route is niet gevonden omdat er geen toestemming is om te evalueren.
Deze verschillen zijn belangrijk bij het creëren van routebeleid. Veel netwerken geven ongeldige routes speciale behandeling omdat een bestaande autorisatie aangeeft dat de resource-houder een specifieke verwachting heeft uitgedrukt. 'Niet gevonden'-routes kunnen worden geïnformeerd, een lagere voorkeur krijgen of volgens het lokale beleid worden geaccepteerd. Elk netwerk beslist hoe het resultaat moet worden toegepast.
Netwerkbeheerders moeten ook onthouden dat validatieresultaten tijdelijk kunnen variëren terwijl repositories en validators worden bijgewerkt. Als een ROA pas enkele minuten geleden is gemaakt of gewijzigd, kunnen verschillende tools verschillende statussen tonen tot de update zich door het validatiesysteem heeft verspreid.
Waarom Kan Een Legitieme Route Ongeldig Worden?
De meest voorkomende oorzaak is een ASN-verandering. Een bedrijf kan oorspronkelijk een prefix aankondigen vanaf een ASN die wordt geleverd door een upstream of ondersteunende organisatie en verplaatst de prefix later naar zijn eigen ASN. Als de ROA nog steeds de oude oorsprong autoriseert, wordt de nieuwe aankondiging ongeldig.
Een tweede oorzaak is een onjuiste maximale voorvoegsel lengte. Een organisatie kan een /20, publiceer een ROA met een maximumlengte van /20, en later twee /21 routes voor verkeersengineering. Deze meer-specifieke aankondigingen kunnen niet worden gedekt door de oorspronkelijke toestemming. De BGP-configuratie kan opzettelijk zijn, maar het RPKI-beleid is te restrictief voor het nieuwe ontwerp.
Overdrachten van IPv4 kunnen vergelijkbare problemen veroorzaken. Tijdens een overdracht kunnen de administratieve houder en de route-origine op verschillende tijdstippen veranderen. Als de autorisatie van de vorige houder actief blijft terwijl de nieuwe houder het voorvoegsel vanaf een ander ASN aankondigt, kan de overgang een ongeldig staat produceren.
Oude records, onjuiste netwerk grenzen en verkeerde begrip over de rol van de transitverstrekkers zijn andere veelvoorkomende oorzaken. Een leverancier kan een klantens route meenemen zonder de oorsprongs-ASN te zijn. De ROA heeft meestal de autorisatie nodig van de ASN die als routeoorsprong verschijnt, niet simpelweg de draagster die het verkeer vervoert.
Hoe te troubleshooten een RPKI-ongeldig resultaat
Begin met het vastleggen van het exacte voorvoegsel en de oorsprongs-ASN die in de BGP-aankondiging worden weergegeven. Vertrouw niet op een afgekorte weergave of een vorige configuratiedocumentatie. Bevestig het adresfamilie, voorvoegsellengte en oorsprong die door ten minste één betrouwbare routeringsmonitor worden waargenomen.
Volgende, inspecteer de actieve ROAs voor dat prefix. Controleer de geautoriseerde ASN en de maximale prefixlengte. Als de oorsprongs-ASN niet overeenkomt, bepaal of de route of de autorisatie verkeerd is. Als de ASN juist is, controleer of het aangekondigde prefix specifieker is dan de toegestane maximale lengte.
Controleer de recente wijzigingen. Zoek naar een ASN-migratie, verandering van upstream leverancier, IPv4-overdracht, IPv6-implementatie, datacenterverplaatsing, routeaggregatiewijziging of BGP-beleidsupdate. De meeste legitieme ongeldige resultaten kunnen worden gecorrigeerd door een recente wijziging die niet is weerspiegeld in de RPKI-beheer.
Als de ROA fout is, verwerk deze dan via de betrokken Regionale Internet Registry, sponsoring LIR of RPKI-beheersysteem. Als de BGP-announcering fout is, corrigeer dan de routebeleidsregel. Geef geen onnodig brede ROA vrij, omdat dit kan leiden tot annoucements die nooit bedoeld waren.
Na het aanbrengen van de correctie, laat tijd voor de opslagplaats en de validatie om te vernieuwen. Controleer het resultaat opnieuw met een externe validatieservice en een BGP-monitoringsbron. De route moet terugkeren naar Geldig wanneer de bron en prefixlengte overeenkomen met de gepubliceerde autorisatie.
Hoe RPKI-resultaten BGP-routing beïnvloeden
De RPKI-validatie trekt een route niet automatisch van het internet terug. Het ontvangende netwerk beslist hoe het de resultaten gebruikt in zijn routebeleid. Sommige operators verwerpen ongeldige routes, terwijl anderen ze markeren met een lagere voorkeur, waarschuwingen genereren of ze onder bepaalde omstandigheden blijven accepteren.
Een geldige route kan normale behandeling ontvangen, maar stelt nog steeds concurrentie met andere routes volgens lokale voorkeur, padlengte, verkeersingenieurstechnieken en leveranciersbeleid. Een niet gevonden route kan worden geaccepteerd door één netwerk en zorgzamer worden behandeld door een ander. Een ongeldige route kan zichtbaar blijven via sommige leveranciers terwijl het onbereikbaar wordt via netwerken die strikte filtering toepassen.
Deze verschillen verklaren waarom een ongeldig bericht kan leiden tot gedeeltelijke connectiviteit. Een service kan werken vanuit één regio, maar falen vanuit een andere, omdat verschillende netwerken verschillende beleidsregels toepassen. Bij het diagnosticeren van een storing is het daarom nuttig om de validatiestatus te vergelijken met BGP-zichtbaarheid van meerdere locaties.
RPKI moet worden beschouwd als een invoer voor routingbeleid in plaats van een universele vervanging voor prefixfilters of route monitoring. De sterkste operationele resultaten komen meestal voort uit het combineren van nauwkeurige RPKI-gegevens met zorgvuldig onderhouden register- en routinggegevens.
RPKI Validation for IPv4 and IPv6
Dezelfde drie staten gelden voor zowel IPv4 als IPv6. In elke adresfamilie vergelijkt de validator de aangekondigde prefix, de oorsprong ASN en de toegestane prefixlengte met de beschikbare ROAs.
Bewerkingen met IPv4 betreffen vaak relatief kleine voorvoegsels, overdrachten, leaseovereenkomsten en meerdere leveranciers. Een verandering in de oorsprongs-ASN of het gebruik van meer-specifieke aankondigingen kan snel het validatieresultaat beïnvloeden. Houders van IPv4-resources moeten RPKI controleren wanneer een blok wordt overgedragen, geleend, verplaatst tussen leveranciers of vanuit een nieuwe locatie wordt aangekondigd.
IPv6-netwerken ontvangen vaak grotere toewijzingen en kunnen een aggregaat aankondigen terwijl ze kleinere interne subnetten gebruiken. De publieke ROA moet overeenkomen met de voorvoegsels die daadwerkelijk worden aangekondigd aan het internet. Als een IPv6-operator alleen een aggregaat autoriseert, maar later meer specifieke routes publiceert, kunnen deze routes ongeldig worden tenzij de maximumlengte dat toelaat.
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.
Hoe u de RPKI-status controleert voordat er een netwerkverandering plaatsvindt
Voordat u een ASN, upstream leverancier, route aggregatieplan of adresresourcehouder wijzigt, noteert u de huidige RPKI-status. Bevestig welke ASN de prefix momenteel origineert en of de aankondiging geldig, ongeldig of niet gevonden is.
Na het opstellen van het nieuwe routeontwerp, vergelijk de verwachte oorsprong en voorvoegsel lengtes met de geplande ROAs. Als de oorsprong zal veranderen, publiceer of werk de autorisatie bij voordat u de nieuwe route aankondigt, wanneer het operationele schema dat toelaat. Tijdens een beheerde migratie kan tijdelijke autorisatie voor beide oorsprongen geschikt zijn, maar de overeenkomst moet worden vastgelegd en de oude autorisatie verwijderd worden wanneer de overgang voltooid is.
Een technische voorcontrole kan ook gerelateerde onvolledigheden ontdekken. De IP-bronnen gereedheidscontrole kan help bij het controleren van openbare registerinformatie, oorsprongs-ASN-gegevens, routeobjecten, RPKI-status en BGP-zichtbaarheid voor een openbare IPv4- of IPv6-prefix. Het is een technische controle in plaats van bewijs van eigendom of overdrachtsgeschiktheid, dus contractuele en registerverificatie blijven noodzakelijk.
Veelgestelde vragen over RPKI-status
Is RPKI niet gevonden hetzelfde als ongeldig?
Niet gevonden betekent dat er geen toepbare ROA is gevonden. Ongeldig betekent dat een relevante ROA bestaat, maar het BGP-announceringsconflict met deze. Ongeldig vereist meestal urgentere onderzoek omdat het een directe onjuistheid met gepubliceerde toestemming vertegenwoordigt.
Kan een geldige route nog steeds een probleem hebben?
Ja. Geldig bevestigt alleen dat de oorsprong ASN en voorvoegselgrootte overeenkomen met een toepasselijke ROA. Het verifieert niet elk deel van de BGP-pad, toepassingsbeveiliging, IP-reputatie, juridisch eigendom of dienstbeschikbaarheid.
Waarom is mijn route ongeldig na het veranderen van leveranciers?
Het wijzigen van de draagster zelf kan geen nieuw ROA vereisen als de oorsprong ASN hetzelfde blijft. Echter, als de providerwijziging ook de oorsprong ASN verandert, of als de nieuwe provider een ander prefixlengte aankondigt, kan het ROA mogelijk bijgewerkt moeten worden.
Hoelang duurt het voordat een ROA-wijziging verschijnt?
De wijziging moet worden gepubliceerd door het relevante RPKI-systeem en opgehaald door validatoren. Het is gebruikelijk dat er een kort tijdsverschil optreedt. Tijdens een productiewijziging, controleer meer dan één validatiesbron en laat tijd voor de vernieuwingsintervallen.
Moet ik elke Niet gevonden-route afwijzen?
Dat hangt af van je netwerkbeleid en risico-model. Not Found bewijst niet dat een route verkeerd is. Veel legitieme routes hebben geen ROA. Sommige netwerken accepteren Not Found-routes terwijl ze monitoring toepassen of lagere voorkeur geven; andere gebruiken strengere beleidsregels voor geselecteerde omgevingen.
Kan RPKI zowel IPv4 als IPv6 beschermen?
Ja. RPKI ondersteunt oorsprongsverificatie voor beide adresfamilies. De praktische configuratie moet overeenkomen met de voorvoegsels en voorvoegselgroottes die elk netwerk daadwerkelijk aankondigt.
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.
Deze resultaten zijn van bijzonder belang tijdens ASN-migraties, leverancierwijzigingen, IPv4-overdrachten, IPv6-implementaties en netwerkherontwerpen. Een legitieme route kan ongeldig worden wanneer de BGP-origine verandert maar de ROA niet wordt bijgewerkt, of wanneer het netwerk begint met het aankondigen van prefixen die specifieker zijn dan de toegestane maximumlengte.
Voor betrouwbare bedrijfsvoering, overweeg de aangekondigde voorvoegsel, oorsprong ASN en maximum voorvoegsel lengte samen. Houd RPKI-gegevens in lijn met het echte routeontwerp, bewaak veranderingen na publicatie en onderzoek ongeldige resultaten op tijd. Gebruik RPKI samen met registergegevens, BGP-monitoring, IRR-gegevens en gedocumenteerde wijzigingsbeheer, in plaats van het te beschouwen als een volledige vervanging voor die systemen.
Als u het serie wilt voortzetten, is het volgende nuttige artikel How to Fix an RPKI Invalid Route, dat meer in detail kan uitleggen over migratieplanning, overlappende autorisaties, leverancierwijzigingen en praktische validatiecontroles.