Welk adres geeft de pool vrij bij de volgende herverbinding?

Een regel die gisteren overeenkwam, komt vandaag niet meer overeen omdat de client via een ander tunneladres terugkwam. De allocator is echter niet willekeurig, en wie zijn volgorde kent, maakt van die verrassing een voorspelbare gebeurtenis. Hij verkiest het adres dat dezelfde client eerder had, valt terug op het langst ongebruikte vrije adres en vergeet alles, tenzij je hem ergens laat onthouden. Regels die uitgaan van een lease blijven overeenkomen tot de dag waarop ze dat stilletjes niet meer doen.

De volgorde die de allocator aanhoudt

Met een sessie per common name zoekt de allocator eerst een adres dat dezelfde client eerder gebruikte en dat nu vrij is. Is dat adres weg, dan neemt hij het vrije adres dat het langst ongebruikt is. Met gelijktijdige sessies voor dezelfde naam geldt de voorkeur voor het vorige adres niet en wordt in plaats daarvan het eerste vrije adres gebruikt, omdat de sessies als afzonderlijke peers worden behandeld.

Twee gevolgen volgen onmiddellijk. Een client die snel opnieuw verbindt, houdt meestal zijn adres, en daarom merkt niemand het mechanisme tot het verandert. En een ander apparaat dat zich in dat kleine venster verbindt, kan het adres innemen terwijl het even vrij is, waarna de eerste client iets anders krijgt en elke regel die op het oude nummer is gericht, fout is. Geen van beide gebeurtenissen levert een logregel op die op een fout lijkt.

Waarom een lease stabiel lijkt en dan verschuift

Stabiliteit is hier een emergente eigenschap van herverbindingen die aankomen voordat iemand anders het adres opeist. Het is geen belofte, en het wordt niet afgedwongen terwijl de client losgekoppeld is. Reken erop dat het adres verandert in plaats van erdoor verrast te worden. Een pool die nauwelijks groter is dan het aantal apparaten maakt botsingen routineus, omdat de terugval op het langst ongebruikte adres bijna niets te kiezen heeft.

Piekconcurrentie is het getal waarop je moet dimensioneren, niet het aantal gebruikers. Iemand die vanaf twee apparaten tegelijk test, of een client die opnieuw verbindt voordat de oude sessie verloopt, bezet een tijdje twee leases. Een pool die alleen op het aantal personen is berekend, levert precies het verloop op dat mensen de server verwijten.

Het persistbestand onthoudt, het reserveert niet

Een adres dat een dienstherstart overleeft, heeft een persistbestand nodig. Het slaat bij het afsluiten de clientnaam en het adres op en leest die bij het starten van de dienst terug, en daarom herschikt een geplande herstart niet meer elke regel die je hebt geschreven.

ifconfig-pool-persist /etc/openvpn/ipp.txt
server 10.8.0.0 255.255.255.0

Wat het niet doet, is het adres vasthouden terwijl de client weg is. In dat gat mag de allocator het nummer aan iemand anders geven, en het bestand legt dan een verouderde voorkeur vast die de volgende verbinding niet kan nakomen. Behandel het als een hint die het herstartgedrag verbetert, niet als statische adressering.

Controleer de pool tegen elk gerouteerd subnet terwijl je in het bestand bent. Een overlappend bereik deelt adressen uit waar de server niet naartoe kan routeren, en het symptoom is een client die verbindt, een adres krijgt en niets bereikt.

Een adres op de juiste manier vastzetten

Wanneer een firewallregel of een DNS-record echt een vast adres nodig heeft, wijs het dan toe in plaats van erop te hopen. Een configuratie-item per client kan een adres en masker rechtstreeks pushen, en dat item is gesleuteld op de effectieve clientnaam.

# client-config-dir entry for "laptop-acme"
ifconfig-push 10.8.0.50 255.255.255.0

Houd vaste adressen buiten de dynamische pool, zodat de allocator hetzelfde nummer nooit aan een andere sessie geeft. Controleer dan de tunneltopologie, want die verandert hoeveel pooladressen elke client verbruikt: de oudere punt-naar-punt-indeling verbruikt per client een klein blok, terwijl een subnetindeling elk een adres gebruikt. Een pool die onder de ene topologie ruim lijkt, kan onder de andere uitgeput raken.

Bevestig het resultaat op de client in plaats van de boekhouding van de server te vertrouwen. Zodra de sessie terug is, kijk naar het interfaceadres en de gepushte route, want een log op de server kan het aangevraagde adres melden terwijl de interface zelf een ander adres houdt.

Het remoteadres is een aparte vraag

Het adres in de remote-regel van de client moet bereikbaar zijn voordat er een tunnel bestaat. Zet je daar een pooladres neer, zoals het eigen tunnel-eindpunt van de server, dan probeert de client het eindpunt te bereiken door een tunnel die nog niet is opgebouwd, en het resultaat is een lus of een stille time-out in plaats van een kortere weg.

Gebruik het openbare eindpunt dat de beheerder heeft geleverd, en houd de pool voor waar hij voor bedoeld is: adressen binnen de tunnel. Het poolbereik, de vaste toewijzingen en het persistpad op een plek vastleggen bespaart de volgende persoon het behandelen van elke lease als willekeurig.