OpenVPN-server met nopool: verklaar een expliciet poolbereik

Serverhulpprogramma’s configureren een subnet en vullen dat vervolgens met een dynamische pool naar eigen keuze. Die standaard is handig tot sommige adressen buiten de toewijzing moeten blijven — of ze nu gereserveerd zijn voor vaste toewijzingen of achtergehouden voor een toekomstig segment. De automatische pool onderdrukken en het bereik zelf verklaren kost twee regels en één bewuste beslissing over welke adressen niet voor toewijzing zijn. De rest is operationele discipline: inventarisatie, toepassen, verifiëren, terugdraaien.

Dit is een wijziging aan een draaiende dienst, dus behandel het als een operationele taak: eerst inventarisatie, dan toepassing via de normale levenscyclus, verificatie met een nieuwe client en een voorbereide terugdraaiing.

Begin bij het subnet dat je al hebt

Lees de huidige serverconfiguratie en de adressen die clients werkelijk vasthouden. De poolwijziging heeft alleen zin ten opzichte van die basislijn, en de basislijn is niet altijd wat het bestand suggereert, omdat een beheerd product of een configuratiegenerator eigenaar kan zijn van het bestand dat je leest.

grep -nE '^(topology|server|ifconfig-pool|max-clients|client-config-dir)' /etc/openvpn/server/lab.conf
ip -4 addr show tun0

Bevestig de geldende topologie. Bij subnettopologie neemt elke client één adres uit de pool; oudere net30-indelingen wijzen een klein blok per client toe en de rekenkunde is totaal anders. Draait de server nog op net30, dan is deze pagina de verkeerde migratiegids en betekenen de poolnummers niet wat je verwacht. Controleer die regel voordat je adresrekenkunde elders vandaan kopieert.

Schrijf het eigen adres van de server op, elke vaste toewijzing in de map met clientconfiguraties en elk adres waarvan een route of een toegangsregel afhangt. Dat zijn de adressen die buiten het dynamische bereik moeten blijven. Ze eerst opschrijven is wat het bereik tot een beslissing maakt in plaats van een gok. Het geeft een terugdraaiing ook iets concreets om te herstellen.

Voeg nopool toe en verklaar het bereik

Het hulptrefwoord accepteert nopool, dat de subnetconfiguratie behoudt en de automatische dynamische pool onderdrukt, zoals de OpenVPN 2.6-handleiding beschrijft. De expliciete regel ifconfig-pool levert vervolgens het inclusieve bereik dat je bedoelt, en de netmasker ervan komt overeen met het subnet. Beide regels horen in hetzelfde serverblok, omdat een pool zonder zijn subnet geen betekenis heeft. De volgorde ertussen is alleen voor de leesbaarheid van belang, omdat de hulp het paar uitbreidt wanneer de dienst start.

topology subnet
server 10.70.0.0 255.255.255.0 nopool
ifconfig-pool 10.70.0.50 10.70.0.120 255.255.255.0

Beide grenzen zijn inclusief, dus het voorbeeld biedt eenenzeventig adressen. Houd het serveradres en elke vaste toewijzing buiten dat bereik; een vaste toewijzing binnen het dynamische bereik levert een botsing op die van de verbindingsvolgorde afhangt, en dat is de slechtste soort om te debuggen. Laat een marge tussen de gereserveerde set en het bereik als de vaste toewijzingen waarschijnlijk groeien.

De grootte van het bereik en gelijktijdigheid zijn aparte limieten. Honderd adressen betekenen niet honderd gelijktijdige clients als max-clients iets anders zegt, en een pool groter dan de gelijktijdigheidslimiet is normaal in plaats van verspilling. Belangrijk is dat de twee limieten bewust worden gekozen in plaats van geërfd van een standaardwaarde.

Houd vaste toewijzingen buiten het dynamische bereik

Een cliëntspecifieke ifconfig-push is een ander mechanisme dan toewijzing uit de pool, en moet parameters gebruiken die bij de actieve topologie passen. In subnetmodus is dat één adres en netmasker; een net30-paar overnemen omdat het in een oud voorbeeld stond, is een veelgemaakte fout.

Toewijzingsgeschiedenis is een aanwijzing, geen autoriteit. Een persist-bestand onthoudt welke client welk adres had, zodat clients die opnieuw verbinden doorgaans hetzelfde krijgen, en het reserveert geen adressen, geeft ze niet vrij en vervangt geen vaste toewijzing. Moet een bepaald apparaat altijd een bepaald adres houden, gebruik dan een vaste toewijzing in plaats van te vertrouwen op het persist-bestand.

Controleer daarna de paden die van adressen afhangen. Een route die naar clients wordt geduwd, een firewallregel die een subnet toelaat, of een monitoringcontrole die een bepaalde host verwacht kunnen allemaal het oude bereik veronderstellen. De pool wijzigen zonder ze te lezen verplaatst de fout naar een plek die ongerelateerd lijkt.

Pas toe via de levenscyclus en verifieer daarna

Pas de wijziging toe zoals de dienst gewoonlijk configuratie ontvangt — of dat een direct bestand plus herstart is of een beheerlaag die het bestand opnieuw genereert. Een handmatige bewerking van een gegenereerd bestand overleeft tot de volgende generatie, en niet langer. Leg vast welk mechanisme het bestand bezit, want de volgende operator moet weten waar dezelfde wijziging moet worden gemaakt. Herstart daarna één keer en lees de log voordat je een client uitnodigt.

systemctl restart openvpn-server@lab
journalctl -u openvpn-server@lab -n 30 --no-pager
# on a fresh client
ip -4 addr show tun0

Verbind een client die niet eerder verbonden was en bevestig dat het adres binnen het verklaarde bereik en buiten de gereserveerde set valt. Bevestig daarna het retourpad: de client moet bereiken wat het beleid toestaat en niets meer. Een adres dat bij het plan past maar geen werkende route heeft, is geen geslaagde wijziging.

Verbind een client die een adres uit het oude bereik had opnieuw. Die moet een adres uit het nieuwe bereik krijgen, en alle sessiegebonden toestand die aan het oude adres hing, moet weg zijn. Blijft het oude adres staan, dan wijst iets anders het toe en is de pool niet de eigenaar die je denkt.

Een bereikwijziging terugdraaien

Bewaar de vorige drie regels in je wijzigingslog, niet alleen het vorige bestand. Ze herstellen en herstarten brengt de toewijzing terug naar het oude gedrag, en clients die daarna opnieuw verbinden krijgen daar adressen van.

Twee waarschuwingen horen in het log. Clients die al verbonden zijn wanneer je terugdraait, behouden hun huidige adressen tot ze opnieuw verbinden, dus een terugdraaiing is niet direct in de hele vloot. En als het oude bereik een vaste toewijzing overlapte, herstelt het terugzetten ook de botsing; juist die overlap was de reden voor de wijziging, en die vraagt een andere oplossing dan een terugdraaiing.

Een poolwijziging is klaar wanneer een nieuwe client een adres binnen het bereik krijgt, een gereserveerd adres nooit wordt uitgedeeld en de routes en regels die die adressen gebruiken zich nog steeds gedragen zoals bedoeld. Alles minder laat de volgende persoon ontdekken welke van de drie niet klopt.