OpenVPN client-config-dir: pangalan ng file laban sa CN ng sertipiko

Dalawang pangalan ang nasa laro bago pa kumonekta ang kliyente: ang pangalan ng file sa laptop (nuc.ovpn) at ang pagkakakilanlang hinahango ng server mula sa kredensyal. Ang paghahanap sa client-config-dir ay gumagamit ng pangalawa. Ang pagpapalit ng pangalan ng profile sa kliyente, o pagdaragdag ng .conf sa file ng server, ay walang binabago sa kung aling file ang bubuksan ng server.

Ang kapaki-pakinabang na paghahambing ay hindi «anong pangalan ang ginamit ko» kundi «anong tuntunin ang inilalapat ng server», dahil ang pagpapatunay sa sertipiko at pagpapatunay sa pangalan ng gumagamit/password ay maaaring magbigay ng magkaibang epektibong pangalan mula sa iisang pag-login.

Pangalan ng profile laban sa karaniwang pangalan ng sertipiko

Sa default na setup na nakabatay sa sertipiko, kinukuha ng server ang X.509 na karaniwang pangalan at naghahanap ng file na eksaktong may ganoong pangalan sa loob ng client-config-dir. Ang profile na tinatawag na nuc.ovpn na ang sertipiko ay nagsasabing tester ay nireresolba sa /etc/openvpn/server/ccd/tester. Ang pangalan ng file ng kliyente ay hindi kailanman pumapasok sa kalkulasyon. Iyon ang unang lugar kung saan nagtatago ang hindi pagkakatugma.

Kaya ang isang direktoryo na puno ng maingat na pinangalanang profile ay maaaring mabalisa sa bawat pagkakataon. Ang file ay hindi itinatapat sa subject, sa email address, o sa pangalang ipinapakita sa isang GUI; itinatapat ito sa string ng karaniwang pangalan.

Sa isang file system na sensitibo sa malaki at maliit na titik, ang Tester at tester ay dalawang magkaibang file, at isa lang ang nabubuksan. Suriin ang karaniwang pangalan mula sa sertipikong aktuwal na inihaharap ng kliyente, hindi mula sa kopya sa iyong mga tala.

Binabaligtad ng username-as-common-name ang tuntunin

Kapag pinapatakbo ng server ang pagpapatunay sa pangalan ng gumagamit/password gamit ang username-as-common-name, pinapalitan ng na-authenticate na pangalan ng gumagamit ang karaniwang pangalan ng sertipiko para sa paghahanap na ito.

Ihambing nang direkta ang dalawang kaso: sa pagkakakilanlan mula sa sertipiko, sinusunod ng file ang sertipiko at walang kinalaman ang pagbabago ng password; sa pagkakakilanlan mula sa pangalan ng gumagamit, sinusunod ng file ang pangalan ng pag-login at walang kinalaman ang muling pag-isyu ng sertipiko. Ang field na pinapalitan ng server ang batayan ng pagpapalit ng pangalan. Ang sertipikong muling inisyu na may bagong CN ay tahimik na nagbabago ng target ng paghahanap, at ang lumang file ng CCD ay nananatili sa disk at mukhang tama.

May magkahalong configuration, at doon nagsisimula ang karamihan ng kalituhan. Kung ang isang bloke ng serbisyo ay nagbubukas ng pagpapalit at ang isa ay hindi, ang epektibong pangalan ay nakadepende sa kung aling instance ang humawak ng koneksyon. Kumpirmahin ang aktibong configuration sa halip na ipagpalagay na nalalapat ang pangkalahatang file. Ang sanggunian sa mga opsyon ng server sa upstream ay nagdodokumento ng paghahanap sa pinangalanang file at ng opsyonal na fallback.

Ano ang binabasa ng server, at ano ang tahimik nitong nilalaktawan

Dalawang maliit na pagkakaiba ang nagtatakda kung mapipili ang isang file. Ang una ay ang idinagdag na extension. Ang pangalawa ay ang naligaw na karakter sa pangalan.

Hindi nagdaragdag ang OpenVPN ng .conf sa pangalang hinahanap nito, kaya hindi tumutugma ang tester.conf sa tester. Ang editor na nagtatago ng mga extension ay maaaring mag-iwan ng file na mukhang tama sa listahan at hindi kailanman tumutugma.

Kapag walang tumutugmang file, maaaring bumagsak ang server sa file na tinatawag na DEFAULT. Kaya ang pagdating ng ilang setting ay hindi patunay na ginamit ang file para sa bawat kliyente. Ihambing ang itinalagang address o ang mga rutang itinulak sa ibibigay ng file para sa bawat kliyente. Ang mga pahintulot ang ikatlong filter, dahil binubuksan ng server ang file pagkatapos nitong bitawan ang mga pribilehiyo; ang root shell na makakabasa nito ay walang pinapatunayan.

Ang tamang pangalan ng file ay hindi nagpapatunay ng nilalaman

Magkaibang pagkabigo ang pagpili at nilalaman. Kapag nabuksan ang tamang file, dapat pa ring valid ang mga direktiba nito para sa kliyenteng iyon.

Dapat magtalaga ang ifconfig-push ng address na aktuwal na magagamit ng topology, at ang iroute ay may saysay lamang para sa isang naka-route na subnet sa likod ng kliyenteng iyon.

Isang pagkakakilanlan, maraming device

Dalawang laptop na naghaharap ng parehong karaniwang pangalan ay pipili ng parehong file at tatanggap ng parehong setting na espesipiko sa kliyente. Kung kailangan mo ng hiwalay na address o hiwalay na pagbawi, kailangan mo ng hiwalay na pagkakakilanlan, hindi dalawang kopya ng isang file.

Ang paghahambing ay sa pagitan ng pagbabahagi ng isang pagkakakilanlan at pag-isyu ng isang sertipiko bawat device. Ang pagbabahagi ay mas simple pangasiwaan at mas magaspang bawiin, samantalang ang mga sertipiko bawat device ay mas maraming setup at nagbibigay sa iyo ng malinis na yunit na maaaring i-disable.