GDOI: de ce serverul de chei nu se află pe calea datelor
Un controler GDOI distribuie politica de grup și cheile; membrii protejează datele. Înregistrarea, livrarea reînnoirii cheilor și redirecționarea necesită verificări separate.
Serverul de chei al grupului distribuie politică și chei membrilor, iar membrii protejează singuri traficul. Această frază sună ca o formalitate până când un proiect tratează controlerul ca un releu pentru fiecare pachet protejat; atunci topologia câștigă un salt de care nu a avut niciodată nevoie, iar calea traficului depinde de un dispozitiv care trebuia doar să distribuie stare. A spune unde se află serverul de chei și a spune încotro curg datele sunt două diagrame diferite, iar GDOI este construit exact în jurul acestei diferențe. Inversarea ei nu este o mică eroare de modelare, pentru că schimbă ce monitorizezi și ce scalezi. Secțiunile de mai jos urmează împărțirea proprie a protocolului.
Două tipuri de stare de securitate
RFC 6407 definește schimbul de tragere al membrului pentru a cere politică și material de cheie, și un schimb de împingere care distribuie politică și actualizări de chei membrilor autorizați. Ambele administrează asocieri de securitate. Niciunul nu este fluxul de date al aplicației, așa că un schimb reușit dovedește doar că canalul de control a funcționat. Un membru se poate înregistra curat, poate ține chei valide și totuși poate eșua în protejarea sau redirecționarea traficului dacă politica sa de date este greșită. Cele două eșecuri nu seamănă deloc odată ce știi care schimb îl poartă pe care.
Standardul numește și o asociere de securitate de reînnoire a cheilor care protejează mesajele de actualizare a cheilor, separată de asocierile de securitate a datelor care descriu cum membrii protejează traficul.
Urmează schimburile, nu diagrama
Privește la ce servește fiecare mesaj. Înregistrarea îi spune controlerului care membru întreabă și stabilește stare; reînnoirea le spune membrilor că politica sau cheile s-au schimbat; apoi traficul protejat al aplicației curge între membri folosind asocierea de securitate a datelor instalată. Adresa controlerului apare în primele două și nu trebuie să apară deloc în a treia.
De aceea o diagramă de interfețe desenată după vecinătatea fizică induce în eroare aici. Interfața controlerului este o sursă de control, nu automat următorul salt pentru fiecare pachet criptat.
Trei înregistrări care merită păstrate
Notează înregistrarea autentificată a membrului și sursa de control pe care o poate atinge, calea care livrează actualizările ulterioare de chei, precum și rutele și atașamentele care poartă traficul protejat al aplicației. Trei înregistrări, trei proprietari, iar o defecțiune în oricare dintre ele produce un simptom diferit. Un membru care se înregistrează și apoi nu primește niciodată o actualizare arată identic cu un membru înregistrat cu politică învechită, dacă nu ai ambele înregistrări.
Păstrează-le lângă configurație, nu în memoria cuiva. Schimbările de apartenență sunt destul de rare încât raționamentul a dispărut mereu până când este nevoie de el.
Interfață, atașament de serviciu, cale de procesare
Pe o poartă bazată pe servicii există o distincție suplimentară: adresa fizică de bază nu este același lucru cu atașamentul local de serviciu, iar implementarea platformei decide cum ajunge traficul la calea ei de procesare IPsec. Mutarea unui serviciu pe o interfață fizică sau adăugarea unei traduceri nelegate pentru că un mesaj de eroare a menționat o regulă de interfață de serviciu este o presupunere îmbrăcată în reparație.
Citește documentația proprie a platformei despre cum primește atașamentul de serviciu traficul. Mecanismul este specific furnizorului chiar și când protocolul este standard.
Mesajele de protocol standardizate nu stabilesc nici compatibilitatea între furnizori. Compară funcțiile necesare, atributele de politică și asociere, metoda de autentificare și platforma și versiunea exacte înainte de a presupune că două implementări vor interoperă.
Disponibilitatea controlului și redirecționarea datelor sunt verificări separate
Planifică accesibilitatea controlerului pentru operarea obișnuită, pentru schimbările de apartenență și pentru actualizările de chei. Un schimb de aplicație care reușește pe stare deja instalată nu dovedește că următoarea înregistrare sau reînnoire poate ajunge la membru, iar decalajul apare de obicei ore mai târziu ca un tunel care nu mai acceptă membri noi. Testează o înregistrare nouă, nu doar o sesiune funcțională.
Apoi testează redirecționarea separat, fără controler. Două verificări, două rezultate și o discuție mult mai scurtă despre care jumătate este stricată.