Stabile OpenVPN-adresser bør følgje identitet, ikkje kjelde-IP

Adresseplanar som seier «denne laptopen får 10.90.0.10», er eigentleg fråsegner om identitet: kva autentisert eining som kan ha den adressa. Den noverande offentlege IP-en til eininga har nesten ingenting med det å gjere, fordi NAT og roaming endrar han utan å endre kven brukaren er. Byggjer ein planen på kjeldeadressa, får ein reglar som bryt saman på det første hotellnettet. Byggjer ein han på den autentiserte identiteten, får ein ein plan som overlever reiser.

Start med det serveren kan verifisere, og avgjer deretter kva adressa er til.

Vel identitetsnøkkelen før adressa

Eit eige klientprogramvaresertifikat per eining gjev serveren ein stabil, verifierbar nøkkel for kvar medlem, som er det reinaste grunnlaget for ei statisk tildeling. Ei utrulling med autentisering per brukar kan i staden bruke brukarnamnet, så lenge valet av konfigurasjon følgjer det same feltet. Å blande dei to modellane gjev tildelingar som passar til eit sertifikat for éin klient og eit brukarnamn for ein annan, og ingen kan føreseie kven som vinn. Avgjer kva nøkkel planen brukar før du skriv ein einaste reservasjon.

Med duplicate-cn kan fleire samtidige økter presentere det same fellesnamnet, så éi fastsett adresse kan ikkje identifisere dei individuelt. Det er ein eigenskap ved identitetsmodellen, ikkje noko ein betre adresseplan kan rette opp.

Reserver adresser utanfor det dynamiske området

I eit nettverk med subnett-topologi som 10.90.0.0/24 held du dei låge adressene for namngjevne medlemmer og legg den dynamiske poolen i eit skilt område. Ei tildeling for ein fastsett medlem ser slik ut ifconfig-push 10.90.0.10 255.255.255.0 i fila serveren vel for den identiteten. Det andre argumentet tyder noko anna under net30, så dømet er ikkje topologinøytralt. Les topologien før du kopierer det.

Persistensen til poolen registrerer nylege leases og har ein tendens til å gje same adresse tilbake, noko som er ei lettvintheit og ikkje ein reservasjon. Ikkje lat persistensfila bli eigarskapsregisteret, fordi ho endrar seg med tilkoplingshistoria og ikkje med policyen.

Tildelingsprioritet avgjer kven som vinn

Handboka dokumenterer ein rekkjefølgje: ei eksplisitt tildeling generert under client-connect kan ta til å gjelde før eit client-config-dir-innslag, som igjen kjem før vanleg poolfordeling. Den rekkjefølgja forklarer dei fleste rapportane om «den fastsette adressa vart ikkje brukt». Det tyder også at ein dynamisk allokator som skriv konfigurasjon per økt, stille kan overstyre ei statisk fil du trudde var autoritativ.

Vel eitt lag som eig tildelingane, og gjer dei andre skriveverna. To lag som begge hevdar å avgjere, gjev tildelingar som avheng av tidspunktet.

Ein dynamisk allokator treng den same modellen

Ein client-connect-integrasjon som deler ut adresser per økt er ein liten allokator med dei vanlege allokatorproblema. Han må validere den førespurnadande identiteten, reservere ei adresse atomisk, berre sende ut støtta utdata per tilkopling og frigjere reservasjonen ved fråkopling eller feil. Samtidige førespurnader treng ein lås eller ein databaserestriksjon, ikkje ein les-deretter-skriv-sekvens. Utan opprydding lekk poolen adresser til ein omstart.

Hald tilstanden til allokatoren der neste operatør kan lese han, og logg avgjerda identitet-til-adresse i staden for berre adressa.

Avgjer om adressa er policy eller lettvintheit

Viss ein brannmurregel eller ei rute tillèt trafikk frå éi tunneladresse, deltek adressa i tilgangspolicyen, og ei ny tildeling arvar den løyva. Koordiner livssyklusen til identitet, adresse og brannmur, eller bind regelen til noko som ikkje kan tildelast på nytt. Stabil adressering gjer konfigurasjonen lesbar; ho erstattar ikkje autentisering.

Skriv planen som ei forteikning med ein eigar per oppføring, og gå gjennom han når ei eining blir teken ut av bruk. Den ubrukte reservasjonen er den som ved eit uhell blir brukt på nytt.