Static na key o TLS para sa OpenVPN link sa pagitan ng dalawang peer?

Dalawang makina na sa isa’t isa lang nag-uusap ay maaaring panatilihin ang topology na iyon at makakuha pa rin ng napagkasunduang traffic key. Ang hugis ng network at ang mode ng proteksyon ay magkahiwalay na pagpipilian, at ang paghahalo sa dalawa ang dahilan kung bakit sinusubukan ng mga tao na ikutin ang isang static na lihim sa pamamagitan ng pagpapalit ng file habang tumatakbo pa ang dalawang daemon. Ang pagpapalit ng key file sa ilalim ng tumatakbong pares ay walang inikot. Ang static-key mode, na minarkahan ng OpenVPN 2.6 bilang lipas na, ay may isang key sa buong buhay ng tunnel, kaya ang file sa disk at ang key sa memorya ay muling magtutugma lamang matapos i-restart ang dalawang dulo. Kung awtomatikong pag-renew ang kailangan, kailangang magbago ang mode ng proteksyon.

Ano ang hindi kayang gawin ng static-key mode

Sa secret mode, ang dalawang peer ay may pinagsasaluhang key na direktang nag-e-encrypt at nagpapatunay sa tunnel. Walang handshake, kaya walang mekanismo para sa alinmang panig na magmungkahi ng bagong key material, patunayan ang pagkakakilanlan, o makabangon mula sa hindi pagkakatugma nang walang interbensyon ng operator. Ang dalawang katangian ay nagmumula sa kawalan ng control channel at hindi sa kulang na opsyon, at walang configuration flag ang nagdaragdag ng isa sa mode na ito.

Ang manwal ng OpenVPN 2.6 ay malinaw na nagsasabi na ang key ay nananatili hanggang makabuo ng bago. Ito ay katanggap-tanggap para sa laboratory link o nakapirming pares ng device na may nakadokumentong pamamaraan ng pag-ikot, at hindi katanggap-tanggap saanman may tunay na panganib ang pangmatagalang lihim. Ang pagpapalit ng file ay hindi lumilikha ng bagong key para sa tumatakbong pares; lumilikha ito ng dalawang peer na hindi nagkakasundo. Kaya ang pagpapalit ng file ay nagdaragdag ng pagkaantala nang hindi nagdaragdag ng pag-ikot.

Wala ring konsepto ng pagkakakilanlan ng peer bukod sa pagmamay-ari ng file. Sinumang may hawak ng key ay peer, at walang anuman sa tunnel ang nagtatala kung aling panig ang alin, kaya ang pagbawi ay lahat o wala.

Lumipat sa TLS nang hindi nire-redesign ang link

Ang TLS mode ay nagdaragdag ng control channel, at kasama nito ang kakayahang makipagkasundo sa mga key ng data channel. Sa point-to-point deployment, ang isang panig ay kumukuha ng papel ng server at ang isa pa ng kliyente, ngunit nananatiling link sa pagitan ng dalawang peer ang topology: alam ng bawat panig ang endpoint ng isa, at walang pool o multiuser service na lumalabas. Ang mga papel ay detalye ng handshake, hindi bagong arkitektura.

Bigyan ang bawat makina ng sarili nitong pagkakakilanlan. Kailangan ng bawat panig ang sertipiko at pribadong key, ang trust anchor na nagpapatunay sa isa, at patakaran sa pagpapatunay ng peer na nagpangalan kung sino ang inaasahan. Huwag muling gamitin ang pribadong key ng isang peer sa isa pa para makatipid ng oras; ginagawa nitong isa ang dalawang pagkakakilanlan at inaalis ang kakayahang bawiin ang alinmang panig nang hiwalay. Ang enrollment ang lugar para gawin ito nang tama, dahil ang pagwawasto mamaya ay nangangahulugan ng muling pag-isyu ng mga sertipiko.

Panatilihing hindi nagbabago ang kontrata ng network habang nagbabago ang proteksyon. Ang parehong mga address ng tunnel, ruta at pinapayagang serbisyo ay dapat gumana bago at pagkatapos, upang ang pagpalya habang lumilipat ay problema sa proteksyon at hindi nakatagong sorpresa sa routing. Isulat ang mga address at ruta bago ang pagbabago; ang paghahambing sa mga ito pagkatapos ay mas mabilis kaysa sa muling pagbuo mula sa alaala.

Ang ilang deployment ay pinoprotektahan din ang control channel ng sarili nitong static na key, na hindi umiikot kasama ng data channel. Ang key na iyon ay nagbabantay sa handshake at hindi sa payload, kaya ang pagkakalantad nito ay nagbubunyag ng negosasyon at hindi ng traffic. Itago ito nang hiwalay sa materyal ng data channel, at bigyan ito ng petsa ng pagpapalit na pagmamay-ari ng pinangalanang tao. Ang pag-ikot nito ay nangangahulugan ng muling pag-restart ng dalawang peer sa isang koordinadong window, kaya karapat-dapat ito sa tala sa kalendaryo at hindi sa alaala.

Sino ang nagre-renew ng ano, at kailan

Sa TLS mode, ang pag-renew ay pinapatakbo ng mga naka-configure na limitasyon: agwat ng oras, bilang ng byte o bilang ng packet. Ang nakadokumentong kontrol sa oras ang pinagkakatiwalaan ng karamihan ng deployment, at ang mas mababang epektibong halaga sa dalawang peer ay maaaring magsimula ng pagpapalit, kaya ang pagtataas nito sa isang panig lamang ay hindi pipigil sa pangyayari. Umiiral ang mga limitasyon batay sa volume dahil ang abalang link ay maaaring maubos ang key nang matagal bago gawin iyon ng orasan. Wala sa mga limitasyon ang pagsusuri sa kalusugan at wala sa kanila ang nagsasabi sa iyo na nagtagumpay ang pag-renew.

Kaya ang pag-diagnose ng paulit-ulit na muling negosasyon mula sa isang configuration file ay nakaliligaw. Basahin ang mga setting sa dalawang peer, pagkatapos tingnan ang transisyon sa log sa halip na ipagpalagay na may sira. Ang pag-renew na malinis na natatapos ay mukhang maikling pagsabog ng traffic ng control channel, hindi tulad ng pagkadiskonekta.

Panatilihing hiwalay ang mga bagay sa iyong isipan. Ang sertipiko ay nagpapatunay ng pangmatagalang pagkakakilanlan at pinapalitan ayon sa iskedyul na kinokontrol mo. Ang key ng data channel ay awtomatikong nire-refresh, at ang hiwalay na palitan ng authentication, kung kailangan ito ng deployment, ay sumusunod sa patakaran ng account at maaaring mangailangan ng sarili nitong mga kaayusan para sa mga susunod na palitan.

Ang ganap na pagpapahinto sa pag-renew sa pamamagitan ng pagtatakda ng agwat sa zero ay hindi solusyon sa maingay na log. Ginagawa nitong permanenteng key ang isang malusog na pangyayari sa lifecycle, na nagbabalik sa iyo sa katangiang sinusubukan mong iwanan.

Pagtanggap sa pagbabago

Buuin ang bagong configuration mula sa sinusuportahang halimbawa ng naka-install na release, hindi mula sa lumang minimal na snippet na ang mga algorithm at path ng file ay minana mula sa ibang lugar. I-coordinate ang paglilipat upang magbago ang dalawang peer nang sabay, at panatilihin ang aprubadong daan ng pagbawi kung sakaling hindi bumangon ang isang panig. Ibaba ang link nang sadyang paraan sa halip na maghintay ng pagkaantala para subukan ang rollback. Ang rollback na naensayo mo ay mas mahalaga kaysa sa rollback na inilarawan mo.

Subukan ang tatlong bagay: nagtagumpay ang paunang pagpapatunay ng pagkakakilanlan, gumagana ang nilalayong daloy ng aplikasyon, at nangyayari ang kontroladong pag-renew nang hindi nawawala ang traffic. Pagkatapos basahin ang transisyon sa log para sa tunay nitong pinapatunayan: ang bagong identifier ng key ay nangangahulugan na natapos ng mga peer ang pagpapalit, hindi na muling kumonekta ang tunnel. Ituring ito bilang ebidensya ng isang hakbang, at suriin ang mga counter ng traffic bago ideklarang tapos ang migrasyon.

Ang itatago ng pangakong walang pagkaantala ay ang pagpalya na hindi mo pa nakikita. Ang nabigong pag-renew, sertipikong nag-expire o depekto sa ruta ay maaari pa ring makagambala sa link, at wala sa mga ito ang naibubukod ng malinis na pagsubok. Ang katangiang sulit idisenyo ay mas makitid at mas kapaki-pakinabang: ang karaniwang pagpapalit ng key ay tumitigil na maging manuwal na pagpapalit ng file.