GDOI: miks võtmeserver ei asu teie andmete teel

Grupi võtmeserver jagab poliitikat ja võtmeid liikmetele ning liikmed kaitsevad liiklust ise. See lause kõlab formaalsusena, kuni mõni lahendus hakkab kontrollerit käsitlema iga kaitstud paketi releena; siis saab topoloogia hüppe, mida tal kunagi vaja ei olnud, ja liiklustee sõltub seadmest, mille ainus ülesanne oli seisundit väljastada. Öelda, kus võtmeserver asub, ja öelda, kuhu andmed voolavad, on kaks erinevat diagrammi ning GDOI on ehitatud täpselt selle erinevuse ümber. Selle tagurpidi mõistmine ei ole väike modelleerimisviga, sest see muudab, mida te jälgite ja mida te skaleerite. Allpool olevad jaotised järgivad protokolli enda jaotust.

Kahte tüüpi turbeseisund

RFC 6407 määratleb liikme tõmbevahetuse poliitika ja võtmematerjali küsimiseks ning lükkamisvahetuse, mis jagab poliitikat ja võtmeuuendusi volitatud liikmetele. Mõlemad haldavad turvaassotsiatsioone. Kumbki ei ole rakenduse andmevoog, seega tõestab edukas vahetus ainult seda, et juhtkanal töötas. Liige võib puhtalt registreeruda, kehtivaid võtmeid hoida ja siiski liiklust mitte kaitsta ega edastada, kui tema andmepoliitika on vale. Need kaks tõrget näevad täiesti erinevad välja, kui tead, milline vahetus kumba kannab.

Standard nimetab ka võtmeuuenduse turvaassotsiatsiooni, mis kaitseb võtmeuuendusteateid, eraldi andmeturbe assotsiatsioonidest, mis kirjeldavad, kuidas liikmed liiklust kaitsevad.

Järgige vahetusi, mitte diagrammi

Vaadake, mille jaoks iga sõnum on. Registreerimine ütleb kontrollerile, milline liige küsib, ja loob seisundi; võtmeuuendus ütleb liikmetele, et poliitika või võtmed on muutunud; seejärel voolab kaitstud rakendusliiklus liikmete vahel paigaldatud andmeturbe assotsiatsiooni abil. Kontrolleri aadress esineb kahes esimeses ja ei pea kolmandas üldse esinema.

Seetõttu füüsilise naabruse järgi joonistatud liidesediagramm eksitab siin. Kontrolleri liides on juhtallikas, mitte automaatselt iga krüpteeritud paketi järgmine hüpe.

Kolm kirjet, mida tasub hoida

Kirjutage üles liikme autenditud registreerimine ja juhtallikas, milleni ta ulatub, tee, mis toimetab järgmised võtmeuuendused kohale, ning marsruudid ja ühendused, mis kannavad kaitstud rakendusliiklust. Kolm kirjet, kolm omanikku ja tõrge ükskõik millises neist annab erineva sümptomi. Liige, kes registreerub ja ei saa seejärel kunagi uuendust, näeb välja täpselt nagu liige, kes registreerus aegunud poliitikaga, kui teil pole mõlemat kirjet.

Hoidke neid konfiguratsiooni kõrval, mitte kellegi mälus. Liikmelisuse muutused on nii harvad, et põhjendus on alati kadunud selleks ajaks, kui seda vaja läheb.

Liides, teenuseühendus, töötlemistee

Teenusepõhisel lüüsil on veel üks erinevus: füüsilise aluskihi aadress ei ole sama mis kohalik teenuseühendus, ja platvormi teostus otsustab, kuidas liiklus jõuab tema IPsec-töötlemisteele. Teenuse liigutamine füüsilisele liidesele või mitteseotud tõlke lisamine, sest veateade mainis teenuseliidese reeglit, on paranduseks maskeeritud oletus.

Lugege platvormi enda dokumentatsiooni selle kohta, kuidas teenuseühendus liiklust vastu võtab. Mehhanism on müüjaspetsiifiline ka siis, kui protokoll on standardne.

Standardiseeritud protokollisõnumid ei loo ka müüjatevahelist ühilduvust. Võrrelge nõutavaid funktsioone, poliitika- ja assotsiatsiooniatribuute, autentimismeetodit ning täpset platvormi ja versiooni, enne kui eeldate, et kaks teostust hakkavad koos töötama.

Juhtimise kättesaadavus ja andmete edastamine on eraldi kontrollid

Planeerige kontrolleri kättesaadavust tavakasutuseks, liikmelisuse muutusteks ja võtmeuuendusteks. Rakenduse vahetus, mis õnnestub juba paigaldatud seisundil, ei tõesta, et järgmine registreerimine või uuendus jõuab liikmeni, ja lünk ilmneb tavaliselt tunde hiljem tunnelina, mis lakkab uusi liikmeid vastu võtmast. Testige värsket registreerimist, mitte ainult töötavat seanssi.

Seejärel testige edastamist eraldi, kontrollerit pildilt välja jättes. Kaks kontrolli, kaks tulemust ja palju lühem vaidlus selle üle, milline pool on katki.