Maaari bang maglingkod sa maraming kliyente ang OpenVPN link na may static key?

Ang static key mode ay nag-uugnay ng eksaktong dalawang peer, at iyon ang disenyo nito, hindi limitasyong nakalimutang alisin ng isang tao. Ang client-to-client ay opsyon sa pagpapasa sa server mode, kaya ang pagdaragdag nito sa isang --secret configuration ay walang binabago sa kung ilang kliyente ang makakonekta. Ang desisyon ay hindi kung aling flag ang idaragdag, kundi kung kailangan ng deployment ng point-to-point na link o serbisyo para sa maraming kliyente. Kung maraming device ang dapat kumonekta nang nakapag-iisa, nagbabago ang proteksyon mode at bawat device ay nakakakuha ng pagkakakilanlan.

Dalawang peer, isang key at walang estado sa bawat kliyente: ang hugis na iyon ang buong kuwento ng mode.

Para saan ang static key mode

Sa secret mode, ang dalawang peer ay nagbabahagi ng isang key file, at ang key na iyon ay direktang nagpoprotekta sa trapiko. Walang handshake, walang palitan ng certificate at walang session sa bawat kliyente, dahil walang kliyente sa kahulugan ng server, dalawang endpoint lamang.

Nananatiling kapaki-pakinabang ang mode para sa isang nakapirming pares ng makina na may dokumentadong proseso ng key rotation, at minamarkahan ito ng OpenVPN 2.6 bilang deprecated dahil saklaw ng TLS mode ang mga kasong iyon nang may mas mahusay na katangian. Ang hindi nito kaya ay ang makilala ang isang kumokonektang device sa isa pa, dahil ang paghawak sa file ay ang buong kuwento ng authentication. Ang pagdaragdag ng ikatlong device ay nangangahulugan ng pagbabahagi ng parehong key dito, at pagkatapos ay hindi na ito makikilala ng unang dalawa mula sa kanilang sarili.

Iyon ang dahilan kung bakit ang limitasyon ng dalawang peer ay estruktural at hindi setting na mababago.

Bakit hindi ang client-to-client ang kulang na piraso

Kinokontrol ng client-to-client kung maaaring magpalitan ng trapiko ang mga konektadong kliyente sa pamamagitan ng server. Hindi ito tumatanggap ng kliyente, hindi nagbibigay ng pagkakakilanlan at hindi gumagawa ng server mode na hindi na-configure, at sa static key configuration ay walang listahan ng kliyente na mangangasiwaan nito.

Ang isa pang karaniwang kalituhan ay tungkol sa materyal na tls-crypt o tls-auth. Maaaring ibahagi ng TLS server ang isa sa mga key na iyon sa lahat ng kliyente, dahil pinoprotektahan nito ang control channel sa halip na patunayan kung sino ang bawat kliyente. Ang shared control-channel key sa TLS mode ay ibang bagay kaysa shared static data key, kahit pareho silang dumarating bilang mga file na magkamukha.

Ang pagpili sa pagitan ng mga mode ay bumaba sa dalawang tanong. Kailangan bang kumonekta nang nakapag-iisa ng higit sa isang device, at kailangan ba ng deployment ng revocation sa bawat device? Ang hindi sa pareho ay nagpapanatili sa static key mode na mabubuhay; ang oo sa alinman sa dalawa ay tumuturo sa TLS. Walang ikatlong opsyon kung saan tinatanggap ang ikalawang kliyente nang walang sariling pagkakakilanlan.

Pagbuo ng server para sa maraming kliyente

Ang server para sa maraming kliyente ay nangangailangan ng TLS mode, certificate sa panig ng server at pagkakakilanlan sa bawat kliyente. Ang server helper ay nagse-set up ng address pool at ng mode para sa maraming kliyente, ngunit hindi ito nagbibigay ng TLS configuration, trust anchor o mga client certificate na nagbibigay-kahulugan sa pagtanggap.

Irehistro ang bawat device sa pamamagitan ng umiiral na certificate authority sa halip na kopyahin ang mga kredensyal ng isang kliyente. Ang magkakaibang pagkakakilanlan ang nagpapahintulot ng revocation, routing sa bawat kliyente at kapaki-pakinabang na log, at ang isang shared client certificate ay nagpapaubos sa tatlo.

Kung ang deployment ay nagpapatunay ng mga user sa pamamagitan ng external na direktoryo o ikalawang factor, mananatili ang disenyong iyon kung ano ito. Ang paglipat sa TLS server mode ay nagpapasya kung paano nagpapatunay ang mga peer sa tunnel layer, at hindi nito idinidikta ang account backend. Panatilihing hiwalay ang dalawang desisyon upang ang pagbabago sa isa ay hindi tahimik na magbago sa isa.

Pagkatapos ay sadyang magpasya sa patakaran ng pagpapasa. Ang client-to-client ay nagbibigay-daan sa trapiko sa pagitan ng mga kliyente sa server path sa user space, na gusto ng maraming deployment at hindi dapat magkaroon ang ilan. Ito ay policy switch, hindi mekanismo ng pagkakakilanlan, at dapat itong buksan dahil kailangan ito ng disenyo, hindi dahil isinama ito ng tutorial.

Pagpapatunay na tunay na malaya ang mga kliyente

Ikonekta ang dalawang kliyente at kumpirmahin na nakakatanggap sila ng magkaibang address at lumalabas na may magkaibang pagkakakilanlan sa log ng server. Pagkatapos ay i-revoke ang isa at kumpirmahin na patuloy na gumagana ang isa, na siyang praktikal na pagsubok na hindi ibinahagi ang mga pagkakakilanlan.

Subukan ang pinapayagang serbisyo sa pagitan ng mga peer at ang isang dapat manatiling naka-block. Ang dalawang matagumpay na pag-login ay nagpapatunay ng pagtanggap, hindi ng paghihiwalay, at mahalaga ang pagkakaiba kapag dapat paghiwalayin ng deployment ang mga grupo ng user.

Sa huli, basahin ang server mode mula sa tumatakbong configuration at hindi mula sa memorya. Ang static key configuration na may karagdagang opsyon ay point-to-point link pa rin, at ang tamang TLS server ang tanging kaayusan kung saan tunay na hiwalay na peer ang maraming kliyente.

Kung ang log ay nagpapakita ng isang karaniwang pangalan para sa bawat device, hindi ang mode ang problema. Ang problema ay ang proseso ng pagpaparehistro.