GDOI: zakaj strežnik ključev ni na vaši podatkovni poti

Skupinski strežnik ključev razdeljuje politiko in ključe članom, člani pa sami ščitijo promet. Ta stavek zveni kot formalnost, dokler neka zasnova ne začne obravnavati krmilnika kot posredovalnika za vsak zaščiten paket; takrat topologija dobi skok, ki ga nikoli ni potrebovala, pot prometa pa je odvisna od naprave, ki naj bi le razdeljevala stanje. Reči, kje je strežnik ključev, in reči, kam tečejo podatki, sta dva različna diagrama, in GDOI je zgrajen prav okoli te razlike. Obrniti to ni majhna napaka pri modeliranju, ker spreminja, kaj spremljate in kaj skalirate. Razdelki spodaj sledijo lastni delitvi protokola.

Dve vrsti varnostnega stanja

RFC 6407 določa izmenjavo vlečenja člana za zahtevo po politiki in ključnem gradivu ter izmenjavo potiskanja, ki razdeljuje politiko in posodobitve ključev pooblaščenim članom. Obe upravljata varnostne povezave. Nobena ni podatkovni tok aplikacije, zato uspešna izmenjava dokazuje le, da je krmilni kanal deloval. Član se lahko čisto registrira, ima veljavne ključe in vseeno ne more zaščititi ali posredovati prometa, če je njegova podatkovna politika napačna. Ti dve okvari sta videti popolnoma različno, ko veš, katera izmenjava katero nosi.

Standard poimenuje tudi varnostno povezavo obnove ključev, ki ščiti sporočila o posodobitvi ključev, ločeno od podatkovnih varnostnih povezav, ki opisujejo, kako člani ščitijo promet.

Sledite izmenjavam, ne diagramu

Poglejte, čemu je namenjeno vsako sporočilo. Registracija pove krmilniku, kateri član sprašuje, in vzpostavi stanje; obnova ključev pove članom, da so se politika ali ključi spremenili; nato zaščiten promet aplikacije teče med člani z nameščeno podatkovno varnostno povezavo. Naslov krmilnika se pojavi v prvih dveh in v tretji mu ni treba pojaviti sploh.

Zato diagram vmesnikov, narisan po fizični soseščini, tukaj zavaja. Vmesnik krmilnika je vir nadzora, ne pa samodejno naslednji skok za vsak šifriran paket.

Trije zapisi, ki jih je vredno hraniti

Zapišite overjeno registracijo člana in krmilni vir, ki ga lahko doseže, pot, ki dostavlja poznejše posodobitve ključev, ter poti in priključke, ki nosijo zaščiten promet aplikacije. Trije zapisi, trije lastniki, in okvara v katerem koli od njih da drugačen simptom. Član, ki se registrira in nato nikoli ne prejme posodobitve, je videti enako kot član, registriran z zastarelo politiko, razen če imate oba zapisa.

Hranite to ob konfiguraciji in ne v spominu nekoga. Spremembe članstva so dovolj redke, da je utemeljitev vedno izginila do trenutka, ko je potrebna.

Vmesnik, priključek storitve, pot obdelave

Na prehodu, ki temelji na storitvah, je še ena razlika: naslov fizičnega podlage ni isto kot lokalni priključek storitve, in izvedba platforme odloči, kako promet doseže njeno pot obdelave IPsec. Premikanje storitve na fizični vmesnik ali dodajanje nepovezanega prevajanja, ker je sporočilo o napaki omenilo pravilo vmesnika storitve, je ugibanje, oblečeno v popravek.

Preberite lastno dokumentacijo platforme o tem, kako priključek storitve sprejema promet. Mehanizem je specifičen za dobavitelja, tudi ko je protokol standarden.

Standardizirana protokolna sporočila tudi ne vzpostavljajo združljivosti med dobavitelji. Primerjajte zahtevane funkcije, atribute politike in povezave, metodo preverjanja ter natančno platformo in izdajo, preden domnevate, da bosta dve izvedbi sodelovali.

Razpoložljivost nadzora in posredovanje podatkov sta ločeni preveritvi

Načrtujte dosegljivost krmilnika za običajno delovanje, za spremembe članstva in za posodobitve ključev. Izmenjava aplikacije, ki uspe na že nameščenem stanju, ne dokazuje, da lahko naslednja registracija ali obnova doseže člana, in vrzel se običajno pokaže ure pozneje kot predor, ki preneha sprejemati nove člane. Preizkusite svežo registracijo, ne le delujoče seje.

Nato preizkusite posredovanje ločeno, brez krmilnika. Dve preveritvi, dva rezultata in veliko krajša razprava o tem, katera polovica je pokvarjena.