Stabiele OpenVPN-adressen moeten identiteit volgen, niet bron-IP
Een statisch adres is een uitspraak over een identiteit, niet over een bron-IP. Kies de sleutel, houd reserveringen buiten de pool en kies dan de eigenaar van de toewijzing.
Adresplannen die zeggen ‘deze laptop krijgt 10.90.0.10’ zijn in werkelijkheid uitspraken over identiteit: welk geauthenticeerd apparaat dat adres mag hebben. Het huidige publieke IP van dat apparaat heeft er bijna niets mee te maken, omdat NAT en roaming het veranderen zonder te veranderen wie de gebruiker is. Het plan op het bronadres bouwen levert regels op die op het eerste hotelnetwerk breken. Het op de geauthenticeerde identiteit bouwen levert een plan op dat reizen overleeft.
Begin bij wat de server kan verifiëren en bepaal dan waarvoor het adres is.
Kies de identiteitssleutel vóór het adres
Een apart clientcertificaat per apparaat geeft de server een stabiele, verifieerbare sleutel voor elk lid, wat de schoonste basis voor een statische toewijzing is. Een implementatie met authenticatie per gebruiker kan in plaats daarvan op de gebruikersnaam vertrouwen, zolang de configuratiekeuze hetzelfde veld volgt. Het mengen van de twee modellen levert toewijzingen op die bij het ene client bij een certificaat passen en bij het andere bij een gebruikersnaam, en niemand kan voorspellen welke wint. Bepaal welke sleutel het plan gebruikt voordat u één reservering schrijft.
Met duplicate-cn kunnen meerdere gelijktijdige sessies dezelfde common name presenteren, dus één vastgezet adres kan ze niet afzonderlijk identificeren. Dat is een eigenschap van het identiteitsmodel, niet iets wat een beter adresplan kan oplossen.
Reserveer adressen buiten het dynamische bereik
In een netwerk met subnet-topologie zoals 10.90.0.0/24 houdt u de lage adressen voor benoemde leden en plaatst u de dynamische pool in een apart bereik. Een toewijzing voor een vastgezet lid ziet er zo uit ifconfig-push 10.90.0.10 255.255.255.0 in het bestand dat de server voor die identiteit kiest. Het tweede argument betekent iets anders onder net30, dus het voorbeeld is niet topologieneutraal. Lees de topologie voordat u het kopieert.
Poolpersistentie registreert recente leases en heeft de neiging hetzelfde adres terug te geven, wat een gemak is en geen reservering. Laat het persistentiebestand niet het eigendomsregister worden, want het verandert met de verbindingsgeschiedenis en niet met het beleid.
De toewijzingsprioriteit bepaalt wie wint
De handleiding documenteert een volgorde: een expliciete toewijzing die tijdens client-connect wordt gegenereerd, kan van kracht worden vóór een client-config-dir-item, dat op zijn beurt voorafgaat aan gewone pooltoewijzing. Die volgorde verklaart de meeste meldingen ‘het vastgezette adres is niet toegepast’. Het betekent ook dat een dynamische allocator die per sessie configuratie schrijft, stilzwijgend een statisch bestand kan overschrijven dat u als gezaghebbend beschouwde.
Kies één laag die toewijzingen bezit en maak de andere alleen-lezen. Twee lagen die beide beweren te beslissen, leveren toewijzingen op die van timing afhangen.
Een dynamische allocator heeft hetzelfde model nodig
Een client-connect-integratie die per sessie adressen uitgeeft is een kleine allocator met de gebruikelijke allocatorproblemen. Hij moet de aanvragende identiteit valideren, een adres atomair reserveren, alleen de ondersteunde uitvoer per verbinding uitgeven en de reservering vrijgeven bij verbreking of mislukking. Gelijktijdige aanvragen hebben een slot of een databasebeperking nodig, geen lees-dan-schrijf-reeks. Zonder opruiming lekt de pool adressen tot een herstart.
Houd de status van de allocator waar de volgende beheerder die kan lezen, en log de beslissing identiteit-naar-adres in plaats van alleen het adres.
Bepaal of het adres beleid of gemak is
Als een firewallregel of een route verkeer van één tunneladres toestaat, dan doet het adres mee aan het toegangsbeleid en erft een hertoewijzing die toestemming. Coördineer de levenscyclus van identiteit, adres en firewall, of koppel de regel aan iets dat niet opnieuw kan worden toegewezen. Stabiele adressering maakt de configuratie leesbaar; het vervangt geen authenticatie.
Schrijf het plan als een inventaris met een eigenaar per regel en beoordeel het wanneer een apparaat buiten gebruik wordt gesteld. De ongebruikte reservering is degene die per ongeluk opnieuw wordt gebruikt.