Stabile OpenVPN-adresser bør følge identitet, ikke kilde-IP

Adresseplaner som sier «denne laptopen får 10.90.0.10», er egentlig erklæringer om identitet: hvilken autentisert enhet som kan ha den adressen. Enhetens nåværende offentlige IP har nesten ingenting med det å gjøre, fordi NAT og roaming endrer den uten å endre hvem brukeren er. Bygger man planen på kildeadressen, får man regler som bryter sammen på det første hotellnettet. Bygger man den på den autentiserte identiteten, får man en plan som overlever reiser.

Start med det serveren kan verifisere, og bestem deretter hva adressen er til.

Velg identitetsnøkkelen før adressen

Et eget klientprogramvaresertifikat per enhet gir serveren en stabil, verifiserbar nøkkel for hvert medlem, som er det reneste grunnlaget for en statisk tildeling. En utrulling med autentisering per bruker kan i stedet bruke brukernavnet, så lenge valget av konfigurasjon følger det samme feltet. Å blande de to modellene gir tildelinger som passer til et sertifikat for én klient og et brukernavn for en annen, og ingen kan forutsi hvilken som vinner. Bestem hvilken nøkkel planen bruker før du skriver en eneste reservasjon.

Med duplicate-cn kan flere samtidige økter presentere det samme fellesnavnet, så én festet adresse kan ikke identifisere dem individuelt. Det er en egenskap ved identitetsmodellen, ikke noe en bedre adresseplan kan rette opp.

Reserver adresser utenfor det dynamiske området

I et nettverk med subnett-topologi som 10.90.0.0/24 beholder du de lave adressene for navngitte medlemmer og legger den dynamiske poolen i et adskilt område. En tildeling for et festet medlem ser slik ut ifconfig-push 10.90.0.10 255.255.255.0 i filen serveren velger for den identiteten. Det andre argumentet betyr noe annet under net30, så eksempelet er ikke topologinøytralt. Les topologien før du kopierer det.

Poolens persistens registrerer nylige leases og har en tendens til å gi samme adresse tilbake, noe som er en bekvemmelighet og ikke en reservasjon. Ikke la persistensfilen bli eierskapsregisteret, fordi den endres med tilkoblingshistorikken og ikke med policyen.

Tildelingsprioritet avgjør hvem som vinner

Håndboken dokumenterer en rekkefølge: en eksplisitt tildeling generert under client-connect kan tre i kraft før en client-config-dir-oppføring, som igjen kommer før vanlig poolfordeling. Den rekkefølgen forklarer de fleste rapportene om «den festede adressen ble ikke brukt». Det betyr også at en dynamisk allokator som skriver konfigurasjon per økt, stille kan overstyre en statisk fil du trodde var autoritativ.

Velg ett lag som eier tildelingene, og gjør de andre skrivebeskyttet. To lag som begge hevder å bestemme, gir tildelinger som avhenger av tidspunktet.

En dynamisk allokator trenger den samme modellen

En client-connect-integrasjon som deler ut adresser per økt er en liten allokator med de vanlige allokatorproblemene. Den må validere den forespørrende identiteten, reservere en adresse atomisk, bare sende ut støttet utdata per tilkobling og frigjøre reservasjonen ved frakobling eller feil. Samtidige forespørsler trenger en lås eller en databaserestriksjon, ikke en les-deretter-skriv-sekvens. Uten opprydding lekker poolen adresser til en omstart.

Hold allokatorens tilstand der neste operatør kan lese den, og logg beslutningen identitet-til-adresse i stedet for bare adressen.

Bestem om adressen er policy eller bekvemmelighet

Hvis en brannmurregel eller en rute tillater trafikk fra én tunneladresse, deltar adressen i tilgangspolicyen, og en ny tildeling arver den tillatelsen. Koordiner livssyklusen til identitet, adresse og brannmur, eller bind regelen til noe som ikke kan tildeles på nytt. Stabil adressering gjør konfigurasjonen lesbar; den erstatter ikke autentisering.

Skriv planen som en fortegnelse med en eier per oppføring, og gjennomgå den når en enhet tas ut av bruk. Den ubrukte reservasjonen er den som ved et uhell brukes på nytt.