GDOI: per què el servidor de claus no és al vostre camí de dades
Un controlador GDOI distribueix la política de grup i les claus; els membres protegeixen les dades. El registre, el lliurament de claus noves i l’encaminament necessiten comprovacions separades.
El servidor de claus de grup distribueix política i claus als membres, i els membres protegeixen ells mateixos el trànsit. Aquesta frase sembla una formalitat fins que un disseny tracta el controlador com un relé per a cada paquet protegit; llavors la topologia afegeix un salt que mai no calia i el camí del trànsit depèn d’un dispositiu que només havia de repartir estat. Dir on és el servidor de claus i dir on flueixen les dades són dos diagrames diferents, i GDOI està construït al voltant d’aquesta diferència. Invertir-ho no és un error petit de modelatge, perquè canvia què superviseu i què escaleu. Les seccions següents segueixen la divisió pròpia del protocol.
Dos tipus d’estat de seguretat
RFC 6407 defineix l’intercanvi de tracció del membre per sol·licitar política i material de clau, i un intercanvi d’empenta que distribueix política i actualitzacions de claus als membres autoritzats. Tots dos gestionen associacions de seguretat. Cap dels dos és el flux de dades de l’aplicació, així que un intercanvi correcte només demostra que el canal de control ha funcionat. Un membre es pot registrar net, tenir claus vàlides i tot i així no protegir ni encaminar el trànsit si la seva política de dades és incorrecta. Aquests dos errors no s’assemblen gens quan saps quin intercanvi porta cadascun.
L’estàndard també anomena una associació de seguretat de rekey que protegeix els missatges d’actualització de claus, separada de les associacions de seguretat de dades que descriuen com els membres protegeixen el trànsit.
Seguiu els intercanvis, no el diagrama
Mireu per a què serveix cada missatge. El registre diu al controlador quin membre pregunta i estableix estat; el rekey diu als membres que la política o les claus han canviat; després el trànsit protegit de l’aplicació flueix entre membres amb l’associació de seguretat de dades instal·lada. L’adreça del controlador apareix en els dos primers i no cal que aparegui gens en el tercer.
Per això un diagrama d’interfícies dibuixat per adjacència física aquí enganya. La interfície del controlador és una font de control, no automàticament el següent salt de cada paquet xifrat.
Tres registres que val la pena guardar
Anoteu el registre autenticat del membre i la font de control que pot assolir, el camí que lliura les actualitzacions de claus posteriors, i les rutes i els enllaços que porten el trànsit protegit de l’aplicació. Tres registres, tres responsables, i una fallada en qualsevol d’ells produeix un símptoma diferent. Un membre que es registra i després no rep mai cap actualització sembla idèntic a un membre registrat amb política obsoleta, tret que tingueu tots dos registres.
Guardeu-ho al costat de la configuració i no a la memòria d’algú. Els canvis de pertinença són prou infreqüents que el raonament sempre ha desaparegut quan cal.
Interfície, adjunció de servei, camí de processament
En una passarel·la basada en serveis hi ha una distinció més: l’adreça física subjacent no és el mateix que l’adjunció local de servei, i la implementació de la plataforma decideix com arriba el trànsit al seu camí de processament IPsec. Moure un servei a una interfície física o afegir traducció no relacionada perquè un missatge d’error esmentava una regla d’interfície de servei és una conjectura vestida de correcció.
Llegiu la documentació pròpia de la plataforma sobre com l’adjunció de servei rep el trànsit. El mecanisme és específic del fabricant fins i tot quan el protocol és estàndard.
Els missatges de protocol estandarditzats tampoc no estableixen compatibilitat entre fabricants. Compareu les funcions necessàries, els atributs de política i associació, el mètode d’autenticació i la plataforma i versió exactes abans de suposar que dues implementacions interoperaran.
Disponibilitat del control i encaminament de dades són comprovacions separades
Planifiqueu l’abast del controlador per a l’operació ordinària, per als canvis de pertinença i per a les actualitzacions de claus. Un intercanvi d’aplicació que té èxit sobre estat ja instal·lat no demostra que el proper registre o rekey pugui arribar al membre, i el buit sol aparèixer hores més tard com un túnel que deixa d’acceptar membres nous. Proveu un registre nou, no només una sessió que funciona.
Després proveu l’encaminament per separat, amb el controlador fora de la imatge. Dues comprovacions, dos resultats i una discussió molt més curta sobre quina meitat està trencada.