Hook na client-connect ng OpenVPN: saan talaga napupunta ang address mo

Ang pagbabalik ng address mula sa script na client-connect ay parang dapat itakda ang IP ng client. Hindi nito ginagawa: ang tanging channel ng hook patungo sa server ay isang pansamantalang file na ang path ay dumarating bilang huling argumento ng script, at ang address ay dapat isulat doon sa syntax na ifconfig-push. Ang script na nagpi-print ng address o nagtatapos sa zero nang walang isinulat ay gumagawa ng konektadong client na may address mula sa pool, at ang log ng server ay mukhang ganap na malusog.

Makatwiran ang pagkalito, dahil maraming iba pang hook ang talagang sumasagot sa pamamagitan ng exit code o environment variable. Ang isang ito ay may sariling kontrata, at ang kontrata ay nagsisimula sa isang pangalan ng file.

Ang hook ay nagsusulat ng file, hindi return value

Ang deklarasyon ay dalawang linya: script-security 2 para payagan ang tawag, pagkatapos client-connect /etc/openvpn/server/assign-address.sh. Kapag nag-authenticate ang client, pinapatakbo ng server ang script na iyon na may idinagdag na nabuong file path bilang huling argumento, na $1 lamang kung ang deklarasyon ay hindi nagpapasa ng sarili nitong karagdagang argumento. Lahat ng inilalapat sa client na iyon ay napupunta sa file na iyon bilang ordinaryong direktiba, isa sa bawat linya, eksaktong gaya ng lalabas sa isang configuration. Ang wrapper na nagdadagdag ng sarili nitong parameter ay nagbabago ng posisyon, at ang klasikong sintomas ay isang script na nagsusulat sa path na mukhang --verbose.

Ang exit status ay ang kabilang kalahati ng kontrata. Ang zero ay nangangahulugang tanggapin at basahin ang file; anumang iba pa ay tinatanggihan ang koneksyon, at ganoon tinatanggihan ang hindi naka-map na pagkakakilanlan sa halip na tahimik na bumalik sa pool. Isulat ang kumpletong direktiba bago ibalik ang tagumpay, upang ang kalahating nakasulat na file ay hindi maging configuration ng isang client.

Dalawang direktiba ang dapat bigyang pansin dahil nakikipag-ugnayan sila sa lahat ng iba pa. Ang ifconfig-push ay nagtatakda ng address, habang ang ipinadalang route ay nagsasabi sa client kung ano ang maaabot sa tunnel; ibalik ang una at kalimutan ang pangalawa at makakakuha ka ng client na may address ngunit walang pupuntahan. Ang pagkakasunod-sunod sa loob ng file ay hindi mahalaga, ngunit ang pagiging kumpleto ay mahalaga. Ang hook na nagpapadala ng ruta para sa isang prefix na walang kapantay na makakaabot ay ang parehong pagkakamali na nakita mula sa kabilang dulo.

Dumarating ang input sa pamamagitan ng environment variable: common_name, trusted_ip, ifconfig_pool_remote_ip at ang iba pa. Tratuhin silang lahat bilang string mula sa labas ng server, hindi kailanman bilang piraso ng shell.

Ang pagmamapa ng address ay isang patakaran, hindi aritmetika

Ang isang nakatutuksong shortcut ay i-parse ang pangalan ng certificate at gamitin ang mga digit nito bilang huling octet. Iyon ay hindi isang allocator, at nabigo ito sa mga ordinaryong paraan: dalawang pangalan na may parehong suffix ay nagbanggaan, ang pangalang nagtatapos sa 300 ay hindi address, at ang certificate na pinangalanang muli ng administrator ay tahimik na inililipat ang isang device. I-validate ang membership sa subnet, ang magagamit na host range, mga reserved address at uniqueness sa bawat tawag, at itago ang mapping sa isang talahanayan na mababasa ng tao.

Sino ang may kontrol sa pangalan ang may kontrol sa address, kaya magpasya kung ano talaga ang kinakatawan ng common_name sa deployment na ito. Kapag naka-enable ang username-as-common-name, ang pagkakakilanlan ay ang login at hindi ang subject ng certificate. Huwag kailanman ipasa ang halagang iyon sa shell evaluation, at huwag kailanman hayaang maimpluwensyahan ng client ang isang file path.

Ang allocator na may suporta ng registry ay dapat makatagal sa concurrency. I-reserve ang address nang atomiko, pangasiwaan ang nabigong write nang hindi tinatanggap ang kalahating naka-configure na client, at i-tag ang bawat allocation sa koneksyon na nagmamay-ari nito, upang ang huling pagdiskonekta mula sa mas lumang session ay hindi makapagpalaya ng address na hawak na ng mas bago. Maraming server instance na nagbabahagi ng isang pool ang nagpapatalas sa pangangailangang iyon, hindi ginagawang opsyonal.

Tinutukoy ng topology kung ano ang ibig sabihin ng ifconfig-push

Sa topology subnet sa 10.77.0.0/24, ang ifconfig-push 10.77.0.20 255.255.255.0 ay isang address at ang netmask nito. Sa ilalim ng topology net30 ang pangalawang argumento ay hindi netmask kundi ang address ng kapantay, kaya ang pagkopya ng anyo ng subnet sa isang net30 server ay nagbibigay sa iyo ng client na kumokonekta at hindi makapagpadala ng trapiko. Baguhin ang topology nang sadya, hindi kailanman upang magmukhang pare-pareho ang isang halimbawa. Ang server na tumatakbo na sa net30 ay may mga buhay na client sa lumang addressing, kaya ang paglipat ay isang migration na may maintenance window, hindi isang linyang edit.

Ang mga static na address ay dapat nasa labas ng dynamic pool at labas ng bawat iba pang static na assignment, kabilang ang mga ibinibigay ng ordinaryong file na client-config-dir. Kung dalawang mekanismo ang makakagawa ng parehong address para sa magkaibang client, isa sa kanila ang gagawa niyon sa huli.

Subukan ang apat na kaso bago ito pagkatiwalaan

Patakbuhin ang parehong mga check laban sa naka-map na pagkakakilanlan, hindi naka-map, muling pagkonekta at simulate na pagkabigo ng registry. Ipinapakita ng openvpn --config client.ovpn --verb 4 ang itinalagang address sa push reply, at sa server grep -A2 PUSH_REPLY /var/log/openvpn/openvpn.log ay nagkukumpirma kung ano ang aktwal na ipinadala. Para sa hindi naka-map na pagkakakilanlan ang inaasahang resulta ay tinanggihang koneksyon, hindi address mula sa pool.

Pagkatapos ay siyasatin ang direktoryo kung saan isinusulat ng daemon ang mga pansamantalang file na iyon. Tumatakbo ang script sa downgraded na konteksto ng serbisyo, kaya ang path na maisusulat ng root ngunit hindi ng daemon ay ginagawang pagtanggi ang bawat koneksyon na may error sa pahintulot na nakabaon ilang linya sa log.

Ang allocation ay hindi awtorisasyon: ang naka-pin na address ay hindi pa nagbibigay ng access sa bawat destinasyon sa likod ng server. Panatilihin ang patakaran sa routing at firewall sa sarili nitong layer, at i-verify ito laban sa address na kakapin mo lang.