Kva adresse deler poolen ut ved neste gjenoppkopling?
Pooladresser følgjer ein rekkjefølgje som ikkje er tilfeldig: først den hugsa adressa, deretter den lengst ubrukte ledige. Les han før du låser ei regel.
Ei regel som passa i går, passar ikkje i dag, fordi klienten kom tilbake på ei anna tunneladresse. Tildelaren er likevel ikkje tilfeldig, og kjenner ein rekkjefølgja, blir den overraskinga ei føreseieleg hending. Han føretrekkjer adressa same klient hadde før, fell tilbake på den lengst ubrukte ledige og gløymer alt med mindre du gir han ein stad å hugse. Reglar som føreset ein lease, passar framleis til den dagen dei stille og roleg ikkje gjer det lenger.
Rekkjefølgja tildelaren følgjer
Med éi økt per common name ser tildelaren først etter ei adresse som same klient brukte tidlegare, og som er ledig no. Er den adressa borte, tek han den ledige adressa som har vore ubrukt lengst. Med samstundes økter for same namn gjeld ikkje føretrinet for den tidlegare adressa, og den første ledige adressa blir brukt i staden, fordi øktene blir handsama som separate peers.
| 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 |
To konsekvensar følgjer med ein gong. Ein klient som koplar raskt til att, held vanlegvis på adressa si, og difor merkar ingen mekanismen før han endrar seg. Og eit anna apparat som koplar til i det vesle vindauget, kan ta adressa medan ho kortvarig er ledig, og etterpå får den første klienten noko anna, og kvar regel som peikar på det gamle nummeret, er feil. Ingen av dei to hendingane gir ei logglinje som ser ut som ein feil.
Kvifor ein lease ser stabil ut og deretter flyttar seg
Stabilitet er her ein framveksande eigenskap ved gjenoppkoplingar som kjem før nokon andre gjer krav på adressa. Det er ikkje eit løfte, og det blir ikkje handheva medan klienten er fråkopla. Planlegg for at adressa endrar seg i staden for å bli overraska over det. Ein pool som knapt er større enn talet på einingar, gjer samanstøyt til kvardag, fordi tilbakefallet til den lengst ubrukte adressa nesten ikkje har noko å velje mellom.
Toppunktssamstundheit er talet ein dimensjonerer etter, ikkje talet på brukarar. Nokon som testar frå to einingar samstundes, eller ein klient som koplar til att før den gamle økta går ut, opptek to leases ei stund. Ein pool som berre er dimensjonert for talet på personar, gir nøyaktig den utskiftinga folk gir tenaren skulda for.
Persistensfila hugsar, ho reserverer ikkje
Ei adresse som overlever ein tenestestart, treng ei persistensfil. Ho lagrar klientnamn og adresse ved nedstenging og les dei inn att når tenesta startar, og difor stokkar ein planlagd omstart ikkje lenger om på alle reglane du skreiv.
ifconfig-pool-persist /etc/openvpn/ipp.txt
server 10.8.0.0 255.255.255.0
Det ho ikkje gjer, er å halde på adressa medan klienten er borte. I det gapet står tildelaren fritt til å gi nummeret til nokon andre, og fila registrerer då ein utdatert preferanse som den neste forbindinga ikkje kan innfri. Handsama ho som eit hint som betrar omstartsåtferda, ikkje som statisk adressering.
Kontroller poolen mot kvart rutta subnet medan du er i fila. Eit overlappande område deler ut adresser som tenaren ikkje kan rute til, og symtomet er ein klient som koplar til, får ei adresse og ikkje når noko.
Å feste ei adresse på rett måte
Når ein brannmurregel eller ein DNS-post verkeleg treng ei fast adresse, tildel ho i staden for å håpe på ho. Ei konfigurasjonsoppføring per klient kan pushe ei adresse og maske direkte, og den oppføringa er nøkla til det effektive klientnamnet.
# client-config-dir entry for "laptop-acme"
ifconfig-push 10.8.0.50 255.255.255.0
Hald faste adresser utanfor den dynamiske poolen, slik at tildelaren aldri gir same nummer til ei anna økt. Kontroller deretter tunneltopologien, fordi han endrar kor mange pooladresser kvar klient brukar: det eldre punkt-til-punkt-oppsettet brukar ein liten blokk per klient, medan eit subnettoppsett brukar éi adresse kvar. Ein pool som ser rikeleg ut under den eine topologien, kan vere uttømmande under den andre.
Stadfest resultatet på klienten i staden for å stole på bokføringa til tenaren. Når økta er tilbake, sjå på grensesnittadressa og den pusja ruta, fordi ein logg på tenaren kan rapportere adressa som vart beden om, medan grensesnittet sjølv har ei anna.
Fjernadressa er eit eige spørsmål
Adressa i remote-linja til klienten må vere nåbar før det finst nokon tunnel. Set ein ei pooladresse der, til dømes det eige tunnelendepunktet til tenaren, prøver klienten å nå endepunktet gjennom ein tunnel han ikkje har bygd enno, og resultatet er ei løkke eller ein stille timeout i staden for ein snarvveg.
Bruk det offentlege endepunktet operatøren oppgav, og hald poolen til det han er laga for: adresser inne i tunnelen. Å notere poolområdet, dei faste tildelingane og persistensstien på ein stad sparer den neste personen for å handsame kvar lease som vilkårleg.