OpenVPN server na may nopool: magpahayag ng tahasang saklaw ng pool

Ang mga katulong ng server ay nag-configure ng subnet at pagkatapos ay pinupuno ito ng dinamikong pool na sarili nilang pinili. Ang default na iyon ay maginhawa hanggang sa ang ilang address ay dapat manatili sa labas ng pamamahagi — maging nakalaan man para sa mga fixed na pagtatalaga o itinatabi para sa hinaharap na segment. Ang pagpigil sa awtomatikong pool at pagpapahayag ng saklaw nang mag-isa ay nangangailangan ng dalawang linya at isang sadyang desisyon tungkol sa kung aling mga address ang hindi para sa pamamahagi. Ang natitira ay disiplina sa operasyon: imbentaryo, paglalapat, pagpapatunay, pag-rollback.

Ito ay pagbabago sa isang serbisyong tumatakbo, kaya ituring itong gawaing pang-operasyon: imbentaryo muna, paglalapat sa normal na lifecycle, pagpapatunay gamit ang bagong kliyente at isang nakahandang rollback.

Magsimula sa subnet na mayroon ka na

Basahin ang kasalukuyang configuration ng server at ang mga address na talagang hawak ng mga kliyente. May saysay lamang ang pagbabago ng pool kung ihahambing sa baseline na iyon, at ang baseline ay hindi laging siyang ipinahihiwatig ng file, dahil ang isang pinamamahalaang produkto o generator ng configuration ay maaaring may-ari ng file na binabasa mo.

grep -nE '^(topology|server|ifconfig-pool|max-clients|client-config-dir)' /etc/openvpn/server/lab.conf
ip -4 addr show tun0

Kumpirmahin ang topolohiyang may bisa. Sa topolohiya ng subnet, ang bawat kliyente ay kumukuha ng isang address mula sa pool; ang mga lumang layout na net30 ay naglalaan ng maliit na bloke sa bawat kliyente at ganap na iba ang aritmetika. Kung ang server ay nasa net30 pa rin, ang pahinang ito ay maling gabay sa paglipat at ang mga numero ng pool ay hindi mangangahulugan ng inaasahan mo. Suriin ang linyang iyon bago kopyahin ang aritmetika ng address mula sa ibang lugar.

Isulat ang sariling address ng server, bawat fixed na pagtatalaga sa direktoryo ng mga configuration ng kliyente, at anumang address na pinagbabatayan ng ruta o tuntunin sa pag-access. Ito ang mga address na dapat manatili sa labas ng dinamikong saklaw. Ang unang pagsulat sa mga ito ang gumagawa sa saklaw na desisyon sa halip na haka-haka. Nagbibigay din ito sa rollback ng konkretong bagay na maibabalik.

Idagdag ang nopool at ipahayag ang saklaw

Tinatanggap ng keyword ng katulong ang nopool, na nagpapanatili sa configuration ng subnet at pumipigil sa awtomatikong dinamikong pool, gaya ng inilalarawan ng manwal ng OpenVPN 2.6. Pagkatapos, ang tahasang linyang ifconfig-pool ay nagbibigay ng inklusibong saklaw na nilalayon mo, at tumutugma ang netmask nito sa subnet. Parehong linya ay nabibilang sa iisang bloke ng server, dahil walang kahulugan ang pool na walang subnet nito. Ang pagkakasunod-sunod sa pagitan nila ay mahalaga lamang para sa pagiging madaling basahin, dahil binubuksan ng katulong ang pares kapag nagsimula ang serbisyo.

topology subnet
server 10.70.0.0 255.255.255.0 nopool
ifconfig-pool 10.70.0.50 10.70.0.120 255.255.255.0

Inklusibo ang dalawang hangganan, kaya nag-aalok ang halimbawa ng pitumpu't isang address. Panatilihin ang address ng server at bawat fixed na pagtatalaga sa labas ng saklaw na iyon; ang fixed na pagtatalaga na mahuhulog sa loob ng dinamikong saklaw ay lumilikha ng banggaan na nakadepende sa pagkakasunod-sunod ng koneksyon, at iyon ang pinakamasamang uri para i-debug. Mag-iwan ng margin sa pagitan ng nakalaang set at ng saklaw kung malamang na lumaki ang mga fixed na pagtatalaga.

Ang laki ng saklaw at sabay-sabay na paggamit ay magkaibang limitasyon. Ang isandaang address ay hindi nangangahulugang isandaang sabay na kliyente kung iba ang sinasabi ng max-clients, at ang pool na mas malaki kaysa sa limitasyon ng sabay-sabay na paggamit ay normal at hindi pag-aaksaya. Ang mahalaga ay ang dalawang limitasyon ay sadyang pinipili sa halip na minamana mula sa default.

Panatilihin ang fixed na pagtatalaga sa labas ng dinamikong saklaw

Ang ifconfig-push na partikular sa kliyente ay ibang mekanismo kaysa sa pamamahagi mula sa pool, at dapat itong gumamit ng mga parameter na angkop sa aktibong topolohiya. Sa mode na subnet ito ay isang address at netmask; ang pagdala ng pares na net30 dahil lumitaw ito sa lumang halimbawa ay karaniwang pagkakamali.

Ang kasaysayan ng pamamahagi ay palatandaan, hindi awtoridad. Ang file na persist ay tumatanda kung aling kliyente ang may aling address, kaya ang mga kliyenteng muling kumokonekta ay madalas makatanggap ng pareho, at hindi ito naglalaan ng address, hindi nagpapalaya at hindi pumapalit sa fixed na pagtatalaga. Kung ang isang partikular na device ay dapat laging may partikular na address, gumamit ng fixed na pagtatalaga sa halip na umasa sa file na persist.

Pagkatapos, suriin ang mga landas na nakadepende sa mga address. Ang rutang itinutulak sa mga kliyente, ang tuntunin ng firewall na pumapayag sa subnet, o ang pagsusuri ng monitoring na umaasa sa partikular na host ay maaaring ipalagay ang lumang saklaw. Ang pagbabago ng pool nang hindi binabasa ang mga ito ay naglilipat ng kabiguan sa lugar na mukhang walang kaugnayan.

Ilapat sa lifecycle, pagkatapos ay i-verify

Ilapat ang pagbabago sa paraang karaniwang tinatanggap ng serbisyo ang configuration — maging direktang file at restart, o layer ng pamamahala na muling bumubuo ng file. Ang manu-manong pag-edit sa nabuong file ay tumatagal hanggang sa susunod na pagbuo, at hindi na. Itala kung aling mekanismo ang may-ari ng file, dahil kailangang malaman ng susunod na operator kung saan gagawin ang parehong pagbabago. Pagkatapos, isang beses na i-restart at basahin ang log bago anyayahan ang kliyente.

systemctl restart openvpn-server@lab
journalctl -u openvpn-server@lab -n 30 --no-pager
# on a fresh client
ip -4 addr show tun0

Ikonekta ang kliyenteng hindi pa nakakonekta at kumpirmahin na ang address ay nasa loob ng ipinahayag na saklaw at labas ng nakalaang set. Pagkatapos, kumpirmahin ang daan pabalik: dapat maabot ng kliyente ang pinapayagan ng patakaran at wala nang iba pa. Ang address na umaayon sa plano ngunit walang gumaganang ruta ay hindi matagumpay na pagbabago.

Muling ikonekta ang kliyenteng may address mula sa lumang saklaw. Dapat siyang makatanggap ng address mula sa bagong saklaw, at ang anumang estado sa antas ng session na nakatali sa lumang address ay dapat na wala na. Kung pinapanatili niya ang lumang address, may ibang nagtatalaga nito at ang pool ay hindi ang may-aring inaakala mo.

Pag-rollback ng pagbabago sa saklaw

Itago ang nakaraang tatlong linya sa iyong talaan ng pagbabago, hindi lamang ang nakaraang file. Ang pagbabalik sa mga ito at pag-restart ay nagbabalik ng pamamahagi sa lumang pag-uugali, at ang mga kliyenteng muling kumonekta pagkatapos ay makakatanggap ng mga address mula rito.

Dalawang babala ang nabibilang sa talaan. Ang mga kliyenteng nakakonekta na kapag nag-rollback ka ay pinapanatili ang kasalukuyang address hanggang sa muling kumonekta, kaya ang rollback ay hindi agaran sa buong fleet. At kung ang lumang saklaw ay nagsapaw sa isang fixed na pagtatalaga, ibinabalik din ng pagbabalik ang banggaan; ang pagsasapaw na iyon ang dahilan ng pagbabago, at nangangailangan ito ng ibang pagtatama kaysa sa rollback.

Tapos na ang pagbabago ng pool kapag ang bagong kliyente ay nakatanggap ng address sa loob ng saklaw, ang nakalaang address ay hindi kailanman ibinigay, at ang mga ruta at tuntuning gumagamit ng mga address na iyon ay patuloy na kumikilos ayon sa layunin. Anumang kulang ay nag-iiwan sa susunod na tao na tuklasin kung alin sa tatlo ang hindi totoo.