Kiun adreson la baseno donos ĉe la sekva rekonekto?
Basenaj adresoj sekvas ordon, kiu ne estas hazarda: unue la memorata adreso, poste la libera plej longe neuzata. Legu ĝin antaŭ ol fiksi regulon.
Regulo, kiu pasis hieraŭ, ne plu pasas hodiaŭ, ĉar la kliento revenis kun alia tunela adreso. La alokilo tamen ne estas hazarda, kaj koni ĝian ordon transformas tiun surprizon en antaŭvideblan eventon. Ĝi preferas la adreson, kiun la sama kliento havis antaŭe, falas reen al la libera plej longe neuzata kaj forgesas ĉion, se vi ne donas al ĝi lokon por memori. Reguloj, kiuj supozas luon, daŭre pasas ĝis la tago, kiam ili silente ne plu faras tion.
La ordo, kiun sekvas la alokilo
Kun unu sesio por common name, la alokilo unue serĉas adreson, kiun la sama kliento uzis antaŭe kaj kiu nun estas libera. Se tiu adreso malaperis, ĝi prenas la liberan adreson, kiu estis neuzata plej longe. Kun samtempaj sesioj ŝaltitaj por la sama nomo, la prefero por la antaŭa adreso ne validas kaj anstataŭe uziĝas la unua libera adreso, ĉar la sesioj estas traktataj kiel apartaj peer-oj.
| Situation | Address chosen | Practical effect |
|---|---|---|
| Reconnect, old address still free | The remembered address | Rules appear stable for days |
| Old address taken by another client | Least recently used free address | A working rule silently stops matching |
| Concurrent sessions, same name | First free address, per session | One identity can hold several leases |
El tio tuj sekvas du konsekvencoj. Kliento, kiu rapide rekonektas, kutime konservas sian adreson, kaj tial neniu rimarkas la mekanismon ĝis ĝi ŝanĝiĝas. Kaj alia aparato, kiu konektas dum tiu malgranda fenestro, povas preni la adreson dum ĝi mallonge liberas, post kio la unua kliento ricevas ion alian kaj ĉiu regulo ligita al la malnova numero estas malĝusta. Neniu el la du eventoj produktas loglinion, kiu aspektas kiel paneo.
Kial luo aspektas stabila kaj poste moviĝas
Stabileco ĉi tie estas emerĝa eco de rekonektoj alvenantaj antaŭ ol iu alia postulas la adreson. Ĝi ne estas promeso, kaj ĝi ne estas devigata dum la kliento estas malkonektita. Planu, ke la adreso ŝanĝiĝos, anstataŭ esti surprizita de ĝi. Baseno apenaŭ pli granda ol la nombro de aparatoj igas koliziojn rutinaj, ĉar la defalo al la plej longe neuzata adreso preskaŭ havas el kio elekti.
Pinta samtempeco estas la nombro, laŭ kiu oni dimensias, ne la nombro de uzantoj. Iu, kiu testas de du aparatoj samtempe, aŭ kliento, kiu rekonektas antaŭ ol la malnova sesio eksvalidiĝas, okupas du luojn dum iom da tempo. Baseno dimensiita nur laŭ la nombro de personoj produktos ĝuste tiun rotacion, kiun homoj riproĉas al la servilo.
La persista dosiero memoras, ĝi ne rezervas
Adreso, kiu postvivas servan restartigon, bezonas persistan dosieron. Ĝi konservas la klientan nomon kaj la adreson ĉe malŝalto kaj relegas ilin ĉe la starto de la servo, kaj tial planita restartigo ne plu miksas ĉiujn regulojn, kiujn vi skribis.
ifconfig-pool-persist /etc/openvpn/ipp.txt
server 10.8.0.0 255.255.255.0Kion ĝi ne faras, estas teni la adreson dum la kliento forestas. En tiu breĉo la alokilo libere rajtas doni la numeron al iu alia, kaj la dosiero tiam registras eksvalidiĝintan preferon, kiun la sekva konekto ne povas plenumi. Traktu ĝin kiel indikon, kiu plibonigas la restartigan konduton, ne kiel statikan adresadon.
Kontrolu la basenon kontraŭ ĉiu enkursigita subreto dum vi estas en la dosiero. Koincida gamo disdonas adresojn, al kiuj la servilo ne povas enkursigi, kaj la simptomo estas kliento, kiu konektas, ricevas adreson kaj atingas nenion.
Fiksi adreson ĝuste
Kiam fajroŝirma regulo aŭ DNS-rikordo vere bezonas fiksan adreson, asignu ĝin anstataŭ esperi ĝin. Po-klienta agorda ero povas puŝi adreson kaj maskon rekte, kaj tiu ero estas ŝlosita per la efektiva klienta nomo.
# client-config-dir entry for "laptop-acme"
ifconfig-push 10.8.0.50 255.255.255.0Tenu fiksajn adresojn ekster la dinamika baseno, por ke la alokilo neniam donu la saman numeron al alia sesio. Poste kontrolu la tunelan topologion, ĉar ĝi ŝanĝas kiom da basenaj adresoj konsumas ĉiu kliento: la pli malnova punkto-al-punkto-aranĝo konsumas malgrandan blokon por kliento, dum subreta aranĝo uzas unu adreson po unu. Baseno, kiu aspektas malavara sub unu topologio, povas elĉerpiĝi sub la alia.
Konfirmu la rezulton sur la kliento anstataŭ fidi la librotenadon de la servilo. Post kiam la sesio revenis, rigardu la interfacan adreson kaj la puŝitan itineron, ĉar log sur la servilo povas raporti la petitan adreson, dum la interfaco mem tenas alian.
La fora adreso estas aparta demando
La adreso en la fora linio de la kliento devas esti atingebla antaŭ ol ekzistas iu tunelo. Meti tie basenan adreson, ekzemple la propran tunelan finpunkton de la servilo, signifas, ke la kliento provas atingi la finpunkton tra tunelo, kiun ĝi ankoraŭ ne konstruis, kaj la rezulto estas buklo aŭ silenta tempolimo anstataŭ mallongigo.
Uzu la publikan finpunkton, kiun la operatoro provizis, kaj tenu la basenon por tio, por kio ĝi estis desegnita: adresoj ene de la tunelo. Noti la basenan gamon, la fiksajn atribuojn kaj la persistan vojon en unu loko ŝparas al la sekva persono trakti ĉiun luon kiel arbitran.