Ang matatag na address ng OpenVPN ay dapat sumunod sa pagkakakilanlan, hindi sa pinagmulang IP

Ang mga plano sa address na nagsasabing 'nakukuha ng laptop na ito ang 10.90.0.10' ay talagang pahayag tungkol sa pagkakakilanlan: aling authenticated na device ang maaaring humawak sa address na iyon. Halos walang kaugnayan dito ang kasalukuyang pampublikong IP ng device na iyon, dahil binabago ito ng NAT at roaming nang hindi binabago kung sino ang user. Ang pagbuo ng plano sa source address ay lumilikha ng mga patakarang nasisira sa unang network ng hotel. Ang pagbuo nito sa authenticated na pagkakakilanlan ay lumilikha ng planong nakakaligtas sa paglalakbay.

Magsimula sa kung ano ang maaaring i-verify ng server, pagkatapos ay magpasya kung para saan ang address.

Piliin ang identity key bago ang address

Ang hiwalay na client certificate sa bawat device ay nagbibigay sa server ng matatag at maaaring i-verify na key para sa bawat miyembro, na siyang pinakamalinis na batayan para sa static na assignment. Ang deployment na gumagamit ng per-user authentication ay maaaring mag-key sa username sa halip, hangga't ang pagpili ng configuration ay sumusunod sa parehong field. Ang paghahalo ng dalawang modelo ay lumilikha ng mga assignment na tumutugma sa certificate para sa isang client at username para sa isa pa, at walang makakapaghula kung alin ang mananaig. Magpasya kung aling key ang gagamitin ng plano bago magsulat ng kahit isang reservation.

Sa duplicate-cn, maraming sabay na session ang maaaring magpakita ng parehong common name, kaya hindi sila matukoy nang isa-isa ng isang naka-pin na address. Katangian iyon ng modelo ng pagkakakilanlan, hindi isang bagay na maaaring ayusin ng mas magandang plano sa address.

Magreserba ng address sa labas ng dynamic na range

Sa network na may subnet topology tulad ng 10.90.0.0/24, itago ang mabababang address para sa mga pinangalanang miyembro at ilagay ang dynamic na pool sa hiwalay na range. Ang assignment para sa naka-pin na miyembro ay mukhang ifconfig-push 10.90.0.10 255.255.255.0 sa file na pinipili ng server para sa pagkakakilanlang iyon. Iba ang ibig sabihin ng ikalawang argumento sa ilalim ng net30, kaya hindi neutral sa topology ang halimbawang ito. Basahin ang topology bago ito kopyahin.

Ang pagtitiyaga ng pool ay nagtatala ng mga kamakailang lease at may tendensiyang ibalik ang parehong address, na isang kaginhawahan sa halip na isang reservation. Huwag hayaang maging talaan ng pagmamay-ari ang persistence file, dahil nagbabago ito sa kasaysayan ng koneksyon sa halip na sa patakaran.

Ang precedence ng assignment ang nagpapasya kung sino ang mananaig

Nakadokumento sa manual ang isang pagkakasunod-sunod: ang tahasang assignment na nilikha sa panahon ng client-connect ay maaaring magkabisa bago ang entry sa client-config-dir, na nauuna naman sa ordinaryong paglalaan mula sa pool. Ipinapaliwanag ng orden na iyon ang karamihan sa mga ulat na 'hindi naipatupad ang naka-pin na address'. Ibig sabihin din nito ay ang dynamic na allocator na nagsusulat ng configuration kada session ay maaaring tahimik na palitan ang static na file na inaakala mong awtoritatibo.

Pumili ng isang layer na magmamay-ari ng mga assignment at gawing read-only ang iba. Ang dalawang layer na parehong nag-aangking magpapasya ay lumilikha ng mga assignment na nakadepende sa timing.

Kailangan ng dynamic na allocator ang parehong modelo

Ang client-connect integration na nagbibigay ng address kada session ay isang maliit na allocator na may karaniwang mga problema ng allocator. Kailangan nitong i-validate ang humihiling na pagkakakilanlan, magreserba ng address nang atomiko, maglabas lamang ng sinusuportahang output kada koneksyon, at magpalaya ng reservation kapag nadiskonekta o nabigo. Ang magkasabay na mga kahilingan ay nangangailangan ng lock o database constraint, hindi ng read-then-write na pagkakasunod-sunod. Kung walang cleanup, tumatagas ang pool ng mga address hanggang sa restart.

Itago ang estado ng allocator sa lugar na mababasa ng susunod na operator, at i-log ang desisyon mula sa pagkakakilanlan patungo sa address sa halip na ang address lamang.

Magpasya kung ang address ay patakaran o kaginhawahan

Kung pinapayagan ng firewall rule o ruta ang trapiko mula sa isang tunnel address, nakikilahok ang address na iyon sa patakaran sa pag-access at namamana ng pahintulot na iyon ang isang reassignment. I-coordinate ang lifecycle ng pagkakakilanlan, address at firewall, o i-key ang patakaran sa isang bagay na hindi maaaring i-reassign. Ginagawang madaling basahin ng matatag na addressing ang configuration; hindi nito pinapalitan ang authentication.

Isulat ang plano bilang imbentaryo na may may-ari sa bawat entry, pagkatapos ay repasuhin ito kapag retirado na ang isang device. Ang hindi ginagamit na reservation ang siyang muling nagagamit nang aksidente.