GDOI: bakit wala ang key server sa iyong data path

Ang group key server ay nagbabahagi ng policy at mga key sa mga miyembro, at ang mga miyembro mismo ang nagpoprotekta sa trapiko. Ang pangungusap na iyon ay parang pormalidad hanggang sa ituring ng isang disenyo ang controller bilang relay para sa bawat protektadong packet; doon nagkakaroon ang topology ng isang hop na hindi kailanman kailangan at ang landas ng trapiko ay nakadepende sa isang aparato na para lamang magbahagi ng estado. Ang pagsasabi kung nasaan ang key server at kung saan dumadaloy ang data ay dalawang magkaibang diagram, at ang GDOI ay itinayo sa paligid ng pagkakaibang iyon. Ang baligtarin ito ay hindi maliit na pagkakamali sa pagmomodelo, dahil binabago nito kung ano ang sinusubaybayan at kung ano ang isinasakala. Ang mga seksyon sa ibaba ay sumusunod sa sariling paghahati ng protocol.

Dalawang uri ng estado ng seguridad

RFC 6407 ay tumutukoy sa pull exchange ng miyembro upang humiling ng policy at key material, at isang push exchange na nagbabahagi ng policy at mga key update sa awtorisadong miyembro. Pareho silang namamahala ng security association. Wala sa kanila ang data stream ng application, kaya ang matagumpay na exchange ay nagpapatunay lamang na gumana ang control channel. Ang isang miyembro ay maaaring malinis na magparehistro, humawak ng wastong mga key at nabigo pa rin na protektahan o ipasa ang trapiko kung mali ang data policy nito. Ang dalawang pagkabigo ay hindi magkatulad kapag alam mo kung aling exchange ang may dala ng alin.

Pinangalanan din ng pamantayan ang isang rekey security association na nagpoprotekta sa mga mensahe ng key update, hiwalay sa mga data security association na naglalarawan kung paano pinoprotektahan ng mga miyembro ang trapiko.

Sundin ang mga exchange, hindi ang diagram

Tingnan kung para saan ang bawat mensahe. Sinasabi ng pagpaparehistro sa controller kung aling miyembro ang nagtatanong at nagtatatag ng estado; sinasabi ng rekey sa mga miyembro na nagbago ang policy o mga key; pagkatapos ay dumadaloy ang protektadong trapiko ng application sa pagitan ng mga miyembro gamit ang naka-install na data security association. Lumilitaw ang address ng controller sa unang dalawa at hindi kailangang lumitaw sa ikatlo.

Kaya naman ang diagram ng interface na iginuhit ayon sa pisikal na pagkakalapit ay nakakalito dito. Ang interface ng controller ay pinagmumulan ng kontrol, hindi awtomatikong susunod na hop para sa bawat naka-encrypt na packet.

Tatlong rekord na sulit itago

Isulat ang awtentikadong pagpaparehistro ng miyembro at ang control source na maaabot nito, ang landas na naghahatid ng mga sumunod na key update, at ang mga ruta at koneksyon na nagdadala ng protektadong trapiko ng application. Tatlong rekord, tatlong may-ari, at ang pagkabigo sa alinman sa mga ito ay nagbibigay ng ibang sintomas. Ang miyembrong nagparehistro at pagkatapos ay hindi kailanman nakatanggap ng update ay mukhang kapareho ng miyembrong nagparehistro gamit ang lumang policy, maliban kung mayroon ka ng dalawang rekord.

Itago ang mga ito sa tabi ng configuration at hindi sa alaala ng sinuman. Bihira lang ang mga pagbabago sa pagiging miyembro kaya ang pangangatwiran ay laging nawala na sa oras na kailanganin ito.

Interface, service attachment, processing path

Sa isang gateway na nakabatay sa serbisyo may dagdag na pagkakaiba: ang pisikal na underlay address ay hindi katulad ng lokal na service attachment, at ang implementasyon ng platform ang nagpapasya kung paano naaabot ng trapiko ang processing path nito sa IPsec. Ang ilipat ang isang serbisyo sa pisikal na interface o magdagdag ng walang kaugnayang pagsasalin dahil binanggit ng mensahe ng error ang isang service-interface rule ay isang haka-haka na nakasuot ng pagkukumpuni.

Basahin ang sariling dokumentasyon ng platform tungkol sa kung paano tumatanggap ng trapiko ang service attachment. Ang mekanismo ay partikular sa vendor kahit pamantayan ang protocol.

Ang mga standardisadong mensahe ng protocol ay hindi rin nagtatatag ng pagiging tugma sa pagitan ng mga vendor. Ihambing ang mga kinakailangang tampok, ang mga katangian ng policy at association, ang paraan ng authentication, at ang eksaktong platform at release bago ipagpalagay na magtutulungan ang dalawang implementasyon.

Ang availability ng kontrol at pagpapasa ng data ay hiwalay na pagsusuri

Planuhin ang maabot ng controller para sa karaniwang operasyon, para sa mga pagbabago sa pagiging miyembro at para sa mga key update. Ang exchange ng application na nagtagumpay sa naka-install nang estado ay hindi nagpapatunay na maaabot ng susunod na pagpaparehistro o rekey ang miyembro, at ang agwat ay karaniwang lumilitaw pagkalipas ng mga oras bilang isang tunnel na humihinto sa pagtanggap ng mga bagong miyembro. Subukan ang bagong pagpaparehistro, hindi lamang ang gumaganang session.

Pagkatapos ay subukan ang pagpapasa nang hiwalay, na wala ang controller. Dalawang pagsusuri, dalawang resulta, at isang mas maikling pagtatalo kung aling kalahati ang sira.