Stabila OpenVPN-adresser bör följa identitet, inte käll-IP

Adressplaner som säger ”den här laptopen får 10.90.0.10” är egentligen påståenden om identitet: vilken autentiserad enhet som får ha den adressen. Enhetens nuvarande offentliga IP har nästan ingenting med saken att göra, eftersom NAT och roaming ändrar den utan att ändra vem användaren är. Bygger man planen på källadressen får man regler som bryts på det första hotellnätet. Bygger man den på den autentiserade identiteten får man en plan som överlever resor.

Börja med vad servern kan verifiera och bestäm sedan vad adressen är till för.

Välj identitetsnyckeln före adressen

Ett separat klientcertifikat per enhet ger servern en stabil, verifierbar nyckel för varje medlem, vilket är den renaste grunden för en statisk tilldelning. En distribution med autentisering per användare kan i stället använda användarnamnet, så länge valet av konfiguration följer samma fält. Att blanda de två modellerna ger tilldelningar som passar ett certifikat för en klient och ett användarnamn för en annan, och ingen kan förutsäga vilken som vinner. Bestäm vilken nyckel planen använder innan du skriver en enda reservation.

Med duplicate-cn kan flera samtidiga sessioner presentera samma gemensamma namn, så en fastnålad adress kan inte identifiera dem individuellt. Det är en egenskap hos identitetsmodellen, inte något en bättre adressplan kan rätta till.

Reservera adresser utanför det dynamiska intervallet

I ett nätverk med subnätstopologi som 10.90.0.0/24 behåller du de låga adresserna för namngivna medlemmar och lägger den dynamiska poolen i ett separat intervall. En tilldelning för en fastnålad medlem ser ut så här ifconfig-push 10.90.0.10 255.255.255.0 i filen som servern väljer för den identiteten. Det andra argumentet betyder något annat under net30, så exemplet är inte topologineutralt. Läs topologin innan du kopierar det.

Poolens persistens registrerar nyligen gjorda leases och tenderar att ge tillbaka samma adress, vilket är en bekvämlighet och inte en reservation. Låt inte persistensfilen bli ägarregistret, eftersom den ändras med anslutningshistoriken och inte med policyn.

Tilldelningsprioritet avgör vem som vinner

Handboken dokumenterar en ordning: en explicit tilldelning som genereras under client-connect kan träda i kraft före en client-config-dir-post, som i sin tur föregår vanlig pooltilldelning. Den ordningen förklarar de flesta rapporterna om ”den fastnålade adressen tillämpades inte”. Det betyder också att en dynamisk allokator som skriver konfiguration per session tyst kan skriva över en statisk fil som du trodde var auktoritativ.

Välj ett lager som äger tilldelningarna och gör de andra skrivskyddade. Två lager som båda hävdar att de bestämmer ger tilldelningar som beror på timing.

En dynamisk allokator behöver samma modell

En client-connect-integration som delar ut adresser per session är en liten allokator med de vanliga allokatorproblemen. Den måste validera den begärande identiteten, reservera en adress atomiskt, bara skicka ut den stödda utdata per anslutning och frigöra reservationen vid frånkoppling eller fel. Samtidiga begäranden behöver ett lås eller en databasbegränsning, inte en läs-sedan-skriv-sekvens. Utan städning läcker poolen adresser till en omstart.

Håll allokatorns tillstånd där nästa operatör kan läsa det, och logga beslutet identitet-till-adress i stället för bara adressen.

Bestäm om adressen är policy eller bekvämlighet

Om en brandväggsregel eller en rutt tillåter trafik från en tunneladress deltar adressen i åtkomstpolicyn, och en omtilldelning ärver det tillståndet. Samordna livscykeln för identitet, adress och brandvägg, eller bind regeln till något som inte kan tilldelas på nytt. Stabil adressering gör konfigurationen läsbar; den ersätter inte autentisering.

Skriv planen som en förteckning med en ägare per post och granska den när en enhet tas ur bruk. Den oanvända reservationen är den som av misstag återanvänds.