Aling address ang ibibigay ng pool sa susunod na muling pagkonekta?

Ang panuntunang tumugma kahapon ay hindi na tumutugma ngayon dahil bumalik ang kliyente sa ibang address ng tunnel. Gayunman ang tagahati ay hindi random, at ang pag-alam sa pagkakasunod-sunod nito ay ginagawang mahuhulaan na pangyayari ang sorpresang iyon. Mas gusto nito ang address na hawak ng parehong kliyente noon, bumabalik ito sa libreng address na pinakamatagal nang walang ginagawa, at nakakalimutan ang lahat kung hindi mo ito bibigyan ng lugar na maaalala. Ang mga panuntunang umaasa sa pag-upa ay patuloy na tumutugma hanggang sa araw na tahimik nang hindi na ito tumutugma.

Ang pagkakasunod-sunod na sinusunod ng tagahati

Sa isang sesyon bawat common name, hinahanap muna ng tagahati ang address na ginamit ng parehong kliyente noon at libre ngayon. Kung wala na ang address na iyon, kinukuha nito ang libreng address na pinakamatagal nang walang aktibidad. Kapag pinagana ang sabay-sabay na sesyon para sa parehong pangalan, hindi nalalapat ang kagustuhan sa dating address at ang unang libreng address ang ginagamit sa halip, dahil itinuturing ang mga sesyon na magkahiwalay na pantay na node.

Dalawang kahihinatnan agad ang sumusunod. Ang kliyenteng mabilis na muling kumonekta ay karaniwang nagpapanatili ng address nito, kaya walang nakapansin sa mekanismong ito hanggang magbago ito. At ang ibang device na kumonekta sa maliit na window na iyon ay maaaring makuha ang address habang panandaliang libre ito, pagkatapos ay nakakuha ang unang kliyente ng iba at mali ang bawat panuntunang nakabatay sa lumang numero. Wala sa dalawang pangyayaring ito ang gumagawa ng linya ng log na mukhang sira.

Bakit parang matatag ang pag-upa at pagkatapos ay gumagalaw

Ang katatagan dito ay isang katangiang lumilitaw mula sa mga muling pagkonektang dumarating bago pa man ang iba ay mag-angkin ng address. Hindi ito pangako, at hindi ito ipinapatupad habang disconnected ang kliyente. Magplano para sa pagbabago ng address sa halip na magulat dito. Ang pool na bahagya lamang mas malaki kaysa bilang ng mga device ay ginagawang karaniwan ang mga banggaan, dahil halos wala nang mapipili ang pagbabalik sa pinakamatagal nang hindi ginamit na address.

Ang pinakamataas na sabay-sabay ay ang bilang na pagbabatayan ng sukat, hindi ang bilang ng gumagamit. Ang isang sumusubok mula sa dalawang device nang sabay, o kliyenteng muling kumonekta bago mag-expire ang lumang sesyon, ay humahawak ng dalawang pag-upa nang ilang sandali. Ang pool na sinukat lamang sa bilang ng tao ay gagawa ng eksaktong pagpapalitan na ipinapako ng mga tao sa server.

Ang file ng pagtitiyaga ay naaalala, hindi nagrereserba

Ang address na nakakaligtas sa muling pag-restart ng serbisyo ay nangangailangan ng file ng pagtitiyaga. Iniimbak nito ang pangalan ng kliyente at address sa pagpapatay at binabasa muli ang mga ito sa pagsisimula ng serbisyo, kaya ang planong pag-restart ay hindi na nagpapagulo sa lahat ng panuntunang isinulat mo.

ifconfig-pool-persist /etc/openvpn/ipp.txt
server 10.8.0.0 255.255.255.0

Ang hindi nito ginagawa ay hawakan ang address habang wala ang kliyente. Sa puwang na iyon ay malaya ang tagahati na ibigay ang numero sa ibang tao, at itinatala ng file ang isang lumang kagustuhang hindi matutupad ng susunod na koneksyon. Ituring ito na pahiwatig na nagpapabuti sa pag-uugali sa pag-restart, hindi bilang static na pag-address.

Suriin ang pool laban sa bawat na-routing na subnet habang nasa file ka. Ang magkakapatong na saklaw ay nagbibigay ng mga address na hindi kayang i-routing ng server, at ang sintomas ay kliyenteng kumonekta, tumanggap ng address at walang marating.

Ang pagpako ng address nang tama

Kapag ang panuntunan ng firewall o tala ng DNS ay talagang nangangailangan ng fixed na address, italaga ito sa halip na umasa. Ang entry ng configuration sa bawat kliyente ay maaaring direktang magtulak ng address at mask, at ang entry na iyon ay naka-key sa epektibong pangalan ng kliyente.

# client-config-dir entry for "laptop-acme"
ifconfig-push 10.8.0.50 255.255.255.0

Itago ang mga fixed na address sa labas ng dynamic na pool para hindi kailanman ibigay ng tagahati ang parehong numero sa ibang sesyon. Pagkatapos ay suriin ang topolohiya ng tunnel, dahil binabago nito kung ilang address ng pool ang ginagamit ng bawat kliyente: ang lumang layout na point-to-point ay gumagamit ng maliit na bloke bawat kliyente, samantalang ang layout ng subnet ay gumagamit ng isang address bawat isa. Ang pool na mukhang sagana sa isang topolohiya ay maaaring maubos sa isa pa.

Kumpirmahin ang resulta sa kliyente sa halip na magtiwala sa pagtutuos ng server. Kapag bumalik ang sesyon, tingnan ang address ng interface at ang itinulak na ruta, dahil ang log sa server ay maaaring mag-ulat ng hiniling na address habang ang interface mismo ay may iba.

Ang remote na address ay hiwalay na tanong

Ang address sa remote na linya ng kliyente ay dapat maabot bago pa man umiral ang anumang tunnel. Ang paglalagay doon ng address ng pool, halimbawa ang sariling endpoint ng tunnel ng server, ay nangangahulugang sinusubukan ng kliyente na maabot ang endpoint sa pamamagitan ng tunnel na hindi pa nito naitatayo, at ang resulta ay loop o tahimik na paghihintay sa halip na shortcut.

Gamitin ang pampublikong endpoint na ibinigay ng operator, at itago ang pool para sa kung ano ito dinisenyo: mga address sa loob ng tunnel. Ang pagtala ng saklaw ng pool, mga fixed na pagtatalaga at ang path ng pagtitiyaga sa isang lugar ay nagliligtas sa susunod na tao mula sa pagtingin sa bawat pag-upa bilang arbitraryo.