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

Adresseplaner, der siger »denne laptop får 10.90.0.10«, er i virkeligheden erklæringer om identitet: hvilken autentificeret enhed der må have den adresse. Enhedens nuværende offentlige IP har næsten intet med det at gøre, fordi NAT og roaming ændrer den uden at ændre, hvem brugeren er. Bygger man planen på kildeadressen, får man regler, der bryder sammen på det første hotelnetværk. Bygger man den på den autentificerede identitet, får man en plan, der overlever rejser.

Start med det, serveren kan verificere, og beslut derefter, hvad adressen er til.

Vælg identitetsnøglen før adressen

Et separat klientcertifikat pr. enhed giver serveren en stabil, verificerbar nøgle til hvert medlem, hvilket er det reneste grundlag for en statisk tildeling. En udrulning med autentificering pr. bruger kan i stedet bruge brugernavnet, så længe valget af konfiguration følger det samme felt. At blande de to modeller giver tildelinger, der passer til et certifikat for én klient og et brugernavn for en anden, og ingen kan forudsige, hvilken der vinder. Beslut, hvilken nøgle planen bruger, før du skriver en eneste reservation.

Med duplicate-cn kan flere samtidige sessioner præsentere det samme fælles navn, så én fastlåst adresse kan ikke identificere dem individuelt. Det er en egenskab ved identitetsmodellen, ikke noget en bedre adresseplan kan rette.

Reservér adresser uden for det dynamiske interval

I et netværk med undernetstopologi som 10.90.0.0/24 beholder du de lave adresser til navngivne medlemmer og lægger den dynamiske pulje i et adskilt interval. En tildeling til et fastlåst medlem ser sådan ud ifconfig-push 10.90.0.10 255.255.255.0 i den fil, serveren vælger til den identitet. Det andet argument betyder noget andet under net30, så eksemplet er ikke topologineutralt. Læs topologien, før du kopierer det.

Puljens persistens registrerer nylige leases og har tendens til at give den samme adresse tilbage, hvilket er en bekvemmelighed frem for en reservation. Lad ikke persistensfilen blive ejerskabsfortegnelsen, fordi den ændrer sig med forbindelseshistorikken frem for med politikken.

Tildelingsprioritet afgør, hvem der vinder

Manualen dokumenterer en rækkefølge: en eksplicit tildeling genereret under client-connect kan træde i kraft før en client-config-dir-post, som igen kommer før almindelig puljetildeling. Den rækkefølge forklarer de fleste rapporter om »den fastlåste adresse blev ikke anvendt«. Det betyder også, at en dynamisk allokator, der skriver konfiguration pr. session, kan overskrive en statisk fil, som du troede var autoritativ, uden at sige det.

Vælg ét lag til at eje tildelinger, og gør de andre skrivebeskyttede. To lag, der begge hævder at bestemme, giver tildelinger, der afhænger af timing.

En dynamisk allokator har brug for den samme model

En client-connect-integration, der uddeler adresser pr. session, er en lille allokator med de sædvanlige allokatorproblemer. Den skal validere den anmodende identitet, reservere en adresse atomisk, kun udsende det understøttede output pr. forbindelse og frigive reservationen ved afbrydelse eller fejl. Samtidige anmodninger kræver en lås eller en databaserestriktion, ikke en læs-derefter-skriv-sekvens. Uden oprydning lækker puljen adresser indtil en genstart.

Hold allokatorens tilstand, hvor den næste operatør kan læse den, og log beslutningen identitet-til-adresse frem for kun adressen.

Beslut, om adressen er politik eller bekvemmelighed

Hvis en firewallregel eller en rute tillader trafik fra én tunneladresse, deltager adressen i adgangspolitikken, og en gentildeling arver den tilladelse. Koordinér identitets-, adresse- og firewalllivscyklussen, eller bind reglen til noget, der ikke kan gentildeles. Stabil adressering gør konfigurationen læsbar; den erstatter ikke autentificering.

Skriv planen som en fortegnelse med en ejer pr. post, og gennemgå den, når en enhed tages ud af drift. Den ubrugte reservation er den, der ved et uheld bliver genbrugt.