Hvilken adresse deler poolen ut ved neste gjenoppkobling?
Pooladresser følger en rekkefølge som ikke er tilfeldig: først den huskede adressen, deretter den lengst ubrukte ledige. Les den før du låser en regel.
En regel som passet i går, passer ikke i dag, fordi klienten kom tilbake på en annen tunneladresse. Tildeleren er likevel ikke tilfeldig, og kjenner man rekkefølgen, blir den overraskelsen en forutsigbar hendelse. Den foretrekker adressen samme klient hadde før, faller tilbake på den lengst ubrukte ledige og glemmer alt med mindre du gir den et sted å huske. Regler som forutsetter en lease, passer fortsatt til den dagen de stille og rolig ikke gjør det lenger.
Rekkefølgen tildeleren følger
Med én sesjon per common name ser tildeleren først etter en adresse som samme klient brukte tidligere, og som er ledig nå. Er den adressen borte, tar den den ledige adressen som har vært ubrukt lengst. Med samtidige sesjoner for samme navn gjelder ikke fortrinnet for den tidligere adressen, og den første ledige adressen brukes i stedet, fordi sesjonene behandles 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 konsekvenser følger umiddelbart. En klient som kobler raskt til igjen, beholder vanligvis adressen sin, og derfor merker ingen mekanismen før den endrer seg. Og en annen enhet som kobler til i det lille vinduet, kan ta adressen mens den kortvarig er ledig, hvoretter den første klienten får noe annet, og enhver regel som peker på det gamle nummeret, er feil. Ingen av de to hendelsene gir en logglinje som ser ut som en feil.
Hvorfor en lease ser stabil ut og deretter flytter seg
Stabilitet er her en fremvoksende egenskap ved gjenoppkoblinger som ankommer før noen andre gjør krav på adressen. Det er ikke et løfte, og det håndheves ikke mens klienten er frakoblet. Planlegg for at adressen endrer seg i stedet for å bli overrasket over det. En pool som knapt er større enn antallet enheter, gjør sammenstøt til hverdag, fordi tilbakefallet til den lengst ubrukte adressen nesten ikke har noe å velge blant.
Toppunktssamtidighet er tallet man dimensjonerer etter, ikke antallet brukere. Noen som tester fra to enheter samtidig, eller en klient som kobler til igjen før den gamle sesjonen utløper, opptar to leases en stund. En pool som bare er dimensjonert for antallet personer, gir nøyaktig den utskiftingen folk gir serveren skylden for.
Persistensfilen husker, den reserverer ikke
En adresse som overlever en tjenestegenstart, trenger en persistensfil. Den lagrer klientnavn og adresse ved nedstengning og leser dem inn igjen når tjenesten starter, og derfor stokker en planlagt omstart ikke lenger om på alle reglene du skrev.
ifconfig-pool-persist /etc/openvpn/ipp.txt
server 10.8.0.0 255.255.255.0Det den ikke gjør, er å holde på adressen mens klienten er borte. I det gapet står tildeleren fritt til å gi nummeret til noen andre, og filen registrerer da en utdatert preferanse som den neste forbindelsen ikke kan innfri. Behandle den som et hint som forbedrer omstartsatferden, ikke som statisk adressering.
Kontroller poolen mot hvert rutet subnet mens du er i filen. Et overlappende område deler ut adresser som serveren ikke kan rute til, og symptomet er en klient som kobler til, får en adresse og ikke når noe.
Å feste en adresse på riktig måte
Når en brannmurregel eller en DNS-post virkelig trenger en fast adresse, tildel den i stedet for å håpe på den. En konfigurasjonsoppføring per klient kan pushe en adresse og maske direkte, og den oppføringen er nøklet til det effektive klientnavnet.
# client-config-dir entry for "laptop-acme"
ifconfig-push 10.8.0.50 255.255.255.0Hold faste adresser utenfor den dynamiske poolen, slik at tildeleren aldri gir samme nummer til en annen sesjon. Kontroller deretter tunneltopologien, fordi den endrer hvor mange pooladresser hver klient bruker: det eldre punkt-til-punkt-oppsettet bruker en liten blokk per klient, mens et subnettoppsett bruker én adresse hver. En pool som ser rikelig ut under den ene topologien, kan være uttømmende under den andre.
Bekreft resultatet på klienten i stedet for å stole på serverens bokføring. Når sesjonen er tilbake, se på grensesnittadressen og den pushede ruten, fordi en logg på serveren kan rapportere adressen som ble bedt om, mens grensesnittet selv har en annen.
Fjernadressen er et eget spørsmål
Adressen i klientens remote-linje må være nåbar før det finnes noen tunnel. Setter man en pooladresse der, for eksempel serverens eget tunnelendepunkt, prøver klienten å nå endepunktet gjennom en tunnel den ikke har bygget ennå, og resultatet er en løkke eller en stille timeout i stedet for en snarvei.
Bruk det offentlige endepunktet operatøren oppga, og hold poolen til det den er laget for: adresser inne i tunnelen. Å notere poolområdet, de faste tildelingene og persistensstien på ett sted sparer den neste personen for å behandle enhver lease som vilkårlig.