Statisk OpenVPN-IP per klient: ifconfig-push, inte ipp.txt

Att redigera en rad i ipp.txt känns som att reservera en adress, och det är det inte. Den filen, som namnges av ifconfig-pool-persist, registrerar vilken adress ett gemensamt namn hade förra gången så att poolen kan lämna tillbaka samma när det passar. Ingenting i den binder nästa anslutning till det numret.

Kör kontrollerna nedan i ordning. Var och en bekräftar antingen mekanismen eller säger åt dig att stanna och reparera en inmatning.

Vad persistensfilen är till för

Filen finns för att hålla adresser stabila mellan omstarter, vilket gör återanslutningar vänligare och loggar lättare att läsa. Den läses som historik och skrivs som historik, och tilldelningsvägen står fri att välja en annan adress när tipset inte passar: en annan pool, en tilldelning i konflikt eller en klient som kom efter att poolen fyllts. Därför kan en manuell ändring se perfekt ut i filen och inte ändra något i anslutningen. Behandla den som en cache av tidigare beslut, inte som en källa till policy.

Om du behöver en specifik adress för en specifik klient är den dokumenterade mekanismen ifconfig-push, och den hör till konfigurationen som äger den klienten.

Kontrollera att rätt klient är vald

En explicit tilldelning slås upp på klientens gemensamma namn, så en fil som är namngiven efter fel identitet läses helt enkelt aldrig. Bekräfta vad servern anser vara namnet på den klienten, särskilt där username-as-common-name ändrar det efter autentisering. Bekräfta sedan att filnamnet stämmer exakt med det värdet, inklusive versaler och gemener.

Tänk på samtidighet medan du är här. Om duplicate-cn är tillåtet kan flera enheter presentera samma identitet, och en fast adress kan inte vara unik för alla. Bestäm om den fasta adressen är värd att neka samtidiga sessioner för den identiteten, eftersom de två kraven inte kan uppfyllas samtidigt.

Kontrollera att siffrorna matchar topologin

Betydelsen av argumenten beror på tunnelns topologi, och det är här ett kopierat exempel gör mest skada. I den äldre net30-ordningen tar varje klient ett block med fyra adresser, så push levererar ett par adresser. I subnätstopologi får klienten en adress plus poolens mask, och parformen är fel. Läs topologin från den körande konfigurationen innan du skriver raden.

# /etc/openvpn/ccd/partner-a   (subnet topology)
ifconfig-push 10.44.0.61 255.255.255.0

Kontrollera adressen mot allt annat som skulle kunna äga den: en annan explicit tilldelning, det dynamiska poolområdet och varje statisk rutt som förutsätter en fast värd. En adress som överlappar poolen fungerar tills poolen ger den till någon annan, och det felet kommer att se slumpmässigt ut.

Kontrollera resultatet på en ny anslutning

En befintlig session behåller adressen den fick, så det enda meningsfulla testet är en ny anslutning. Koppla från klienten, anslut igen och läs adressen den faktiskt fick tillsammans med rutterna som kom med den. Om adressen fortfarande är dynamisk tillämpades inte tilldelningen, och nästa steg är uppslaget i konfigurationen snarare än ännu en ändring i historikfilen.

Håll bevisen tillsammans: klientnamnet, filen som matchade, den tilldelade adressen och poolen den kom från.

Slutligen, en fast tunneladress är inte en enhetsuppgift. Den anger en plats i adressplanen, medan autentiseringen fortfarande vilar på certifikatet och kontot. Att förväxla de två gör en adresskonflikt till ett säkerhetsantagande som ingen har skrivit ned.