Zašto promjena podataka u registru može učiniti ispravnu mrežu nedostupnom?

Zamislite da vaša usluga i dalje radi preko mobilne veze, ali joj korisnici druge mreže više ne mogu pristupiti. Serveri su ispravni. Kablovi su spojeni. Jedno moguće objašnjenje jeste da je druga mreža, nakon promjene zapisa, prestala prihvatati rutu do vaših adresa.

Karika koja nedostaje jeste odluka između zapisa i rutera. Promjena u bazi podataka može uticati na povezivost kada sistem tu promjenu koristi za izradu filtra ili procjenu objave rute. Da biste razumjeli kvar, pratite taj lanac. „Registar je pogrešan“ tek je početak dijagnoze.

Fizičke veze mogu ostati netaknute kada promjena zapisa utiče na prihvatanje ruta. Pratite dokaze i politiku prijema.

Prvo pitajte koji je zapis promijenjen

IP prefiks je blok adresa. Broj autonomnog sistema, odnosno ASN, označava mrežu koja razmjenjuje rute s drugim mrežama. BGP je protokol kojim te mreže objavljuju do kojih odredišta mogu doći.

Uz tu razmjenu postoji nekoliko vrsta zapisa. Oni odgovaraju na različita pitanja:

• Registracijski zapisi: koja je organizacija upisana uz blok adresa i koga treba kontaktirati. Dokumentacija baze RIPE razlikuje registraciju resursa, informacije o rutiranju i kontaktne zapise iako se nalaze u istoj bazi.
• Zapisi internetskog registra rutiranja (IRR): informacije pomoću kojih operatori mogu sastaviti liste ruta koje će prihvatati. Zapis opisuje predviđeno rutiranje; sam po sebi ne objavljuje rutu.
• Zapisi infrastrukture javnih ključeva za resurse (RPKI): uključuju potpisana ovlaštenja za izvor rute, zvana ROA, iz kojih validatori proizvode podatke za provjeru izvorne mreže i dopuštene dužine prefiksa.

Zastarjela kontaktna adresa e-pošte ne povlači direktno BGP rutu. Ako ruta nedostaje u filtru koji je pružalac usluge generisao, taj pružalac može prestati da je prihvata. Nazvati oba slučaja „nevažećim podacima registra“ znači sakriti razliku koja je važna.

Kako zapis dovodi do odbijanja rute

Uzmimo pružaoca usluge koji filtre za klijente izrađuje iz IRR podataka. Moguć je sljedeći niz događaja:

1. Zapis rute je uklonjen ili ga skup ruta klijenta više ne uključuje.
2. Pri sljedećoj izradi filtra pružalac izostavlja tu rutu.
3. Novi filtar dolazi do rutera pružaoca usluge, koji odbijaju klijentovu objavu.
4. Ako ne ostane upotrebljiva alternativa, ljudi koji zavise od tog puta gube pristup.

Da bi došlo do tog niza, podaci zaista moraju biti ulaz za taj filtar. Objavljena politika registra rutiranja kompanije NTT DATA daje konkretan primjer filtara za klijente zasnovanih na IRR-u i automatskih ažuriranja. Takođe dokumentuje odbijanje ruta sa stanjem RPKI Invalid i izostavljanje proturječnih IRR zapisa. To su prepoznatljivi operativni mehanizmi, a ne univerzalni prekidač kojim registar isključuje mrežu.

Šta RPKI „Invalid“ zaista znači

Pri provjeri izvora objavljena ruta poredi se s provjerenim podacima o ovlaštenju. RFC 6811 definiše tri ishoda:

• Valid (važeće): barem jedno ovlaštenje koje obuhvata rutu odgovara izvornom ASN-u i dopušta dužinu objavljenog prefiksa.
• Invalid (nevažeće): postoje podaci o ovlaštenju koji obuhvataju rutu, ali nijedno ovlaštenje ne zadovoljava oba uslova.
• NotFound (nije pronađeno): nijedan podatak o ovlaštenju ne obuhvata rutu.

Na primjer, ruta koju objavljuje mreža A može postati Invalid ako njeno odgovarajuće ovlaštenje nestane, dok ovlaštenje za mrežu B koje obuhvata tu rutu ostane. Ako ne ostane nijedno ovlaštenje koje je obuhvata, rezultat je NotFound. „Invalid“ je ovdje rezultat provjere rutiranja, a ne presuda o vlasništvu ili institucionalnoj legitimnosti. Provjera izvora takođe ne potvrđuje autentičnost cijelog puta kojim ruta tvrdi da je prošla.

Sljedeći korak je politika koju je operator podesio. RFC 8481 odvaja utvrđivanje stanja provjere od postupanja prema njemu: politiku mora podesiti operator. Mreža podešena da odbija Invalid rute tada može odbiti ovu objavu. Izmjena registra i odbijanje povezani su tim mehanizmom; nisu isti događaj.

Zašto neki izgube pristup prije drugih

Ne koriste sve mreže iste filtre, pružaoce usluga ili podatke u istom trenutku. RFC 7115 objašnjava da RPKI keševi mogu imati različite prikaze podataka i da ne postoji jedinstven, garantovan interval dolaska ažuriranja do rutera.

U uvodnom primjeru jedna mreža možda je već postupila prema izmijenjenim podacima, dok druga još ima prihvaćen put. Zato je moguć djelimičan prekid. To ne dokazuje da je registar izazvao bilo koji konkretan prekid: inženjeri i dalje moraju pregledati pogođenu rutu, podatke koji se koriste i odluku kojom je ruta odbijena.

Pronađite prekinutu kariku prije novih izmjena

Korisno pitanje za oporavak vrlo je konkretno: koji je sistem prestao prihvatati koju objavu i zašto? Operator to može razjasniti zajedno s pružaocem usluge:

1. Identifikujte objavu. Zabilježite pogođeni prefiks i izvorni ASN te provjerite objavljuje li se očekivana ruta i dalje.
2. Pronađite mjesto odbijanja. Uporedite instalirani filtar pružaoca usluge i rezultat provjere s rutom. Pitajte koji su izvor podataka i koje ažuriranje doveli do te odluke.
3. Sačuvajte dokaze. Zadržite relevantne zapise, opažanja i vremenske oznake kako biste mogli razlikovati pogrešno ažuriranje od neovlaštene objave.
4. Ispravite i provjerite. Uskladite tačnu ispravku zapisa ili konfiguracije, potvrdite da je stigla do sistema koji koriste podatke i ispitajte pristup s mreža na kojima nije radio.

Isključivanje provjere svuda uklonilo bi i zaštitu od loših objava. Operativni zadatak je vratiti ispravne dokaze i predviđeno rutiranje, a zatim provjeriti rezultat. Uspješna izmjena baze podataka sama po sebi ne dokazuje da se korisnici ponovo mogu povezati.

Dublji problem: korisni dokazi mogu postati koncentrisana moć

Ovdje se tehnički lanac susreće s argumentom Lu Henga. Administrator ne mora prosljeđivati ničije pakete da bi uticao na dostupnost njihove mreže. Ako drugi sistemi zavise od zapisa koje kontroliše, njegove odluke mogu nametnuti troškove operatorima i korisnicima daleko izvan njegovog ureda.

U Bilješci 65, Prvenstvo koda koji radi, Lu Heng tvrdi da koordinacija mora biti ograničena potrebama mreža koje rade. Uloga održavanja zapisa ne može sama sebe proširiti u trajni politički mandat. Činjenica da je zapis potpisan odgovara na tehničko pitanje o toj tvrdnji; ne uspostavlja pravo upravljanja svima na koje ona utiče.

Njegov prijedlog ide dalje od boljeg žalbenog postupka. Zajednička pravila treba da štite jedinstvenost, provjerljivu kontrolu i interoperabilnost, dok učesnici lokalno provjeravaju stanje i odlučuju koje će kompatibilne promjene usvojiti. Novi odbor s neograničenim vetom ponovio bi problem pod drugim imenom.

Kontinuitet traži izlaz koji druge mreže mogu koristiti

Upotrebljiva alternativa mora prenijeti pouzdane zapise, sigurnosne tvrdnje i operativne odnose. Druge mreže moraju moći provjeriti te zapise i koristiti ih. Samo kopiranje baze podataka neće ih navesti da prihvate zamjenu, a proglašenje nezavisnosti ne popravlja odbijenu rutu.

Bilješka 72 jasno navodi željeni ishod: tačni zapisi, operativni kontinuitet i stvarna mogućnost napuštanja koordinatora koji ne funkcioniše. Praktični izazov je izgraditi tu sposobnost bez gubitka zajedničke jedinstvenosti i kompatibilnosti koje nezavisnim mrežama omogućavaju komunikaciju.

O tome govori i vodič za izvoz stanja registra , koji razmatra dio posla vezan za prenošenje zapisa. To je jedna komponenta tranzicije, uz provjeru, usvajanje kod operatora i ispitivanje kontinuiteta.

Pripremite se dok usluga još radi

Zatražite od tima da prati jedan važan blok adresa od njegovih zapisa do pružalaca usluga i korisnika koji od njega zavise. Ko može promijeniti svaki zapis? Ko ga koristi? Kako bi se greška ispravila ako sadašnji administrator ne bi bio dostupan ili bi bio osporen?

Za utvrđivanje tih odgovora između organizacija potrebno je vrijeme. Ako ih nađete prije kvara, dobijate prostor za djelovanje; ako ih otkrivate tokom prekida, trošak nose korisnici. Hitnost je u izgradnji praktične nezavisnosti dok se kontinuitet još može zaštititi.

Nastavite čitanje uz Bilješku 65: Prvenstvo koda koji radi za cjelovit argument Lu Henga o koordinaciji zasnovanoj na mrežama koje rade, lokalnoj provjeri i dobrovoljnom usvajanju.