GDOI: zašto server ključeva nije na vašoj putanji podataka

Grupni server ključeva dijeli politiku i ključeve članovima, a članovi sami štite promet. Ta rečenica zvuči kao formalnost dok neki dizajn ne počne tretirati kontroler kao relej za svaki zaštićeni paket; tada topologija dobija hop koji joj nikad nije trebao, a putanja prometa zavisi od uređaja koji je samo trebao izdavati stanje. Reći gdje se nalazi server ključeva i kuda teku podaci dvije su različite sheme, a GDOI je izgrađen upravo oko te razlike. Okrenuti to naopako nije mala greška u modeliranju, jer mijenja šta nadzirete i šta skalirate. Odsjeci ispod slijede vlastitu podjelu protokola.

Dvije vrste sigurnosnog stanja

RFC 6407 definiše članovu razmjenu povlačenja za traženje politike i ključnog materijala, i razmjenu guranja koja dijeli politiku i ažuriranja ključeva ovlaštenim članovima. Obje upravljaju sigurnosnim asocijacijama. Nijedna nije podatkovni tok aplikacije, pa uspješna razmjena dokazuje samo da je kontrolni kanal radio. Član se može čisto registrovati, držati važeće ključeve i ipak ne moći zaštititi ili proslijediti promet ako je njegova podatkovna politika pogrešna. Te dvije greške izgledaju potpuno različito kad znate koja razmjena nosi koju.

Standard također imenuje sigurnosnu asocijaciju obnove ključeva koja štiti poruke ažuriranja ključeva, odvojeno od sigurnosnih asocijacija podataka koje opisuju kako članovi štite promet.

Slijedite razmjene, ne shemu

Pogledajte čemu služi svaka poruka. Registracija govori kontroleru koji član pita i uspostavlja stanje; obnova ključeva govori članovima da su se politika ili ključevi promijenili; zatim zaštićeni promet aplikacije teče između članova koristeći instaliranu sigurnosnu asocijaciju podataka. Adresa kontrolera pojavljuje se u prve dvije i ne mora se uopće pojaviti u trećoj.

Zato dijagram interfejsa nacrtan po fizičkoj susjednosti ovdje zavodi. Interfejs kontrolera je kontrolni izvor, a ne automatski sljedeći hop za svaki šifrovani paket.

Tri zapisa koja vrijedi čuvati

Zapišite članovu autentifikovanu registraciju i kontrolni izvor do kojeg može doći, putanju koja dostavlja kasnija ažuriranja ključeva, te rute i priključke koji nose zaštićeni promet aplikacije. Tri zapisa, tri vlasnika, a greška u bilo kojem od njih daje drugačiji simptom. Član koji se registruje i nikad ne primi ažuriranje izgleda isto kao član koji se registrovao sa zastarjelom politikom, osim ako imate oba zapisa.

Držite to uz konfiguraciju, a ne u nečijem sjećanju. Promjene članstva su dovoljno rijetke da obrazloženje uvijek nestane do trenutka kad zatreba.

Interfejs, priključak usluge, putanja obrade

Na mrežnom prolazu zasnovanom na uslugama postoji dodatna razlika: adresa fizičkog podloška nije isto što i lokalni priključak usluge, a implementacija platforme odlučuje kako promet dolazi do njene IPsec putanje obrade. Premještanje usluge na fizički interfejs ili dodavanje nepovezanog prevođenja jer je poruka o grešci spomenula pravilo interfejsa usluge je nagađanje obučeno u popravku.

Pročitajte vlastitu dokumentaciju platforme o tome kako priključak usluge prima promet. Mehanizam zavisi od dobavljača čak i kad je protokol standardan.

Standardizovane protokolske poruke također ne uspostavljaju kompatibilnost između dobavljača. Uporedite obavezne funkcije, atribute politike i asocijacije, metodu autentifikacije te tačnu platformu i izdanje prije nego pretpostavite da će dvije implementacije sarađivati.

Dostupnost kontrole i prosljeđivanje podataka su odvojene provjere

Planirajte dostupnost kontrolera za uobičajeni rad, za promjene članstva i za ažuriranja ključeva. Razmjena aplikacije koja uspije na već instaliranom stanju ne dokazuje da sljedeća registracija ili obnova može doći do člana, a jaz se obično pojavi satima kasnije kao tunel koji prestaje primati nove članove. Testirajte svježu registraciju, ne samo radnu sesiju.

Zatim testirajte prosljeđivanje odvojeno, bez kontrolera. Dvije provjere, dva rezultata i mnogo kraća rasprava o tome koja je polovina pokvarena.