Statische OpenVPN-clientadressen achter OPNsense

Namen hebben adressen nodig die niet bewegen, en het poolbestand van OpenVPN maakt een adres alleen maar plakkerig. Verlies dat bestand, of geef een certificaat opnieuw uit onder een andere common name, en de terugkerende client belandt ergens anders in de pool terwijl zijn DNS-record nog naar het oude adres wijst. Het duurzame antwoord is een clientspecifieke overschrijving die het adres vastpint, plus een breder tunnelnetwerk zodat vastgepinde adressen buiten het dynamische bereik liggen. De rekenkunde achter die verbreding is waar het meeste misverstand woont.

OPNsense bewaart die overschrijvingen in de clientspecifieke instellingen van de server, gesleuteld op de common name van het certificaat, waardoor de common name deel uitmaakt van het adresplan.

Een plakkerige lease is geen statisch adres

Het poolbestand schrijft adres-naar-client-koppelingen en geeft ze terug wanneer een bekende client opnieuw verbindt. Dat is gemak, geen contract: het bestand kan opnieuw worden gegenereerd, de koppeling verdwijnt wanneer de identiteit van de client verandert, en twee servers die een pool delen zijn het er niet over eens. Een clientspecifieke overschrijving werkt anders, omdat het adres uit de configuratie komt en niet uit de geschiedenis. Ze overleeft ook een herstart en een herinstallatie van het apparaat, mits de overschrijving samen met de rest van de configuratie wordt geback-upt.

Het dynamische alternatief, de VPN met een client-connect-script en dynamische updates in DNS hangen, werkt en vereist een resolver die updates accepteert plus een script bij elke verbinding. Op een apparaat ben je beperkt tot de pakketten die de leverancier levert, en daar stopt dat plan meestal.

De /30-rekenkunde waar niemand van houdt

Onder de standaard net30-topologie krijgt elke client zijn eigen /30: het eerste bruikbare adres gaat naar de serverkant, het tweede naar de client. Overschrijvingen moeten dus buiten het dynamische tunnelnetwerk van de server liggen, wat betekent dat dat netwerk eerst verbreed moet worden. Een server op 10.8.0.0/24 kan naar 10.8.0.0/23 gaan, waarbij de helft van het oude bereik voor dynamische clients blijft en de andere helft voor overschrijvingen. Voeg het oorspronkelijke /24 toe als extra lokaal IPv4-netwerk zodat verkeer naar beide helften de tunnel in gaat.

Elk overschrijvingsadres moet op een /30-grens vallen, dus de laatste octet is een veelvoud van vier. Een /30 op 10.8.1.0 geeft de client 10.8.1.2, en dat is het adres dat het DNS-record draagt. Kies je in plaats daarvan 10.8.1.3, dan krijg je een client die verbindt en geen verkeer kan doorlaten, omdat het adres bij een subnet hoort dat de topologie hem nooit heeft toegewezen.

Het plan is makkelijker te onderhouden als overschrijvingen van boven aan het verbrede bereik naar beneden worden toegewezen, zodat de dynamische pool in vrije ruimte groeit in plaats van rond vaste eilanden.

Lokale netwerken en de zone die clients opvragen

Client-naar-client-verkeer heeft zijn eigen toestemming nodig. De lijst met lokale IPv4-netwerken van de server moet beide helften van het bereik bevatten, dynamisch en statisch; zonder die lijst accepteert de server een pakket van de ene client en heeft hij geen beleid dat het naar een andere doorlaat. Het symptoom leest als een DNS-fout, omdat de naam oplost en de verbinding toch faalt. Controleer tegelijk de instelling voor client-naar-client, want een vermelding van een lokaal netwerk alleen schakelt doorsturen tussen peers niet in.

Publiceer de records in de zone die externe clients werkelijk opvragen. Een record in een zone die alleen door de LAN-resolver wordt bediend, is onzichtbaar voor een client wiens gepushte resolver elders heen wijst, en meer records aan de verkeerde zone toevoegen herstelt dat nooit. Bevestig de gepushte DNS-optie en het zoekdomein voordat je iets toevoegt.

Wat je moet controleren bij een nieuwe verbinding

Verbind de client opnieuw en bevestig dat het toegewezen adres bij zijn overschrijving past voordat je iets anders test. Los daarna de naam op vanaf een tweede client en verbind met de dienst op naam, wat het DNS-record, de route en de firewall samen test. Bevestig het antwoordpad aan de serverkant, want een naam die oplost terwijl de dienst onbereikbaar blijft, is een routerings- of beleidsprobleem en geen naamprobleem. Houd de overschrijvingstabel naast de certificatenlijst zodat beide samen worden beoordeeld.

Een certificaat dat onder een andere common name opnieuw wordt uitgegeven, past niet meer bij zijn overschrijving en stuurt de client terug naar de dynamische pool. Verwacht dat na elke identiteitswijziging.