Statiske OpenVPN-klientadresser bag OPNsense
En poolfil gør en adresse klæbrig, ikke permanent. Fastgør klientadresser med tilsidesættelser, udvid tunnelområdet til /30-aritmetikken, og udgiv dem derefter.
Navne har brug for adresser, der ikke flytter sig, og OpenVPNs poolfil gør kun en adresse klæbrig. Mist den fil, eller genudsted et certifikat under et andet almindeligt navn, og den tilbagevendende klient lander et andet sted i poolen, mens dens DNS-post stadig peger på den gamle adresse. Det holdbare svar er en klientspecifik tilsidesættelse, der fastlåser adressen, plus et bredere tunnelnettværk, så fastlåste adresser ligger uden for det dynamiske område. Aritmetikken bag den udvidelse er, hvor det meste af forvirringen bor.
OPNsense opbevarer disse tilsidesættelser i serverens klientspecifikke indstillinger, nøglet på certifikatets almindelige navn, hvilket gør det almindelige navn til en del af adresseplanen.
En klæbrig lease er ikke en statisk adresse
Poolfilen skriver adresse-til-klient-tilknytninger og giver dem tilbage, når en kendt klient genopretter forbindelsen. Det er bekvemmelighed frem for en kontrakt: filen kan gendannes, tilknytningen forsvinder, når klientens identitet ændres, og to servere, der deler en pool, vil ikke være enige om den. En klientspecifik tilsidesættelse virker anderledes, fordi adressen kommer fra konfiguration i stedet for fra historik. Den overlever også en genstart og en geninstallation af enheden, forudsat at tilsidesættelsen sikkerhedskopieres sammen med resten af konfigurationen.
Det dynamiske alternativ, at koble VPN’en til DNS med et klientforbindelsesskript og dynamiske opdateringer, virker og kræver en resolver, der accepterer opdateringer, plus et skript ved hver forbindelse. På en enhed er du begrænset til de pakker, leverandøren sender, og det er normalt der, den plan stopper.
/30-aritmetikken, som ingen nyder
Under den standard net30-topologi får hver klient sin egen /30: den første brugbare adresse går til serversiden, den anden til klienten. Tilsidesættelser skal derfor ligge uden for serverens dynamiske tunnelnettværk, hvilket betyder, at netværket først skal udvides. En server på 10.8.0.0/24 kan flytte til 10.8.0.0/23 og efterlade den ene halvdel af det gamle område til dynamiske klienter og den anden halvdel til tilsidesættelser. Tilføj det oprindelige /24 som et ekstra lokalt IPv4-netværk, så trafik til begge halvdele sendes ind i tunnelen.
Hver tilsidesættelsesadresse skal ligge på en /30-grænse, så den sidste oktet er et multiplum af fire. En /30 på 10.8.1.0 giver klienten 10.8.1.2, og det er den adresse, DNS-posten bærer. Vælger du i stedet 10.8.1.3, får du en klient, der forbinder og ikke kan sende trafik, fordi adressen tilhører et undernet, som topologien aldrig tildelte den.
Planen er lettere at holde, hvis tilsidesættelser tildeles fra toppen af det udvidede område og nedad, så den dynamiske pool udvider sig i ledig plads i stedet for omkring faste øer.
Lokale netværk og den zone, klienter spørger
Klient-til-klient-trafik har brug for sin egen tilladelse. Serverens liste over lokale IPv4-netværk skal indeholde begge halvdele af området, dynamisk og statisk; uden den accepterer serveren en pakke fra én klient og har ingen politik, der tillader den igennem til en anden. Symptomet ligner en DNS-fejl, fordi navnet slår op, og forbindelsen fejler stadig. Kontroller indstillingen for klient-til-klient samtidig, da en post for lokalt netværk alene ikke aktiverer videresendelse mellem peers.
Udgiv posterne i den zone, som fjernklienter faktisk spørger. En post i en zone, der kun betjenes af LAN-resolveren, er usynlig for en klient, hvis pushede resolver peger et andet sted, og flere poster i den forkerte zone reparerer det aldrig. Bekræft den pushede DNS-indstilling og søgedomænet før du tilføjer noget.
Hvad skal kontrolleres på en ny forbindelse
Genopret klientens forbindelse, og bekræft at den tildelte adresse svarer til dens tilsidesættelse, før du tester noget andet. Slå derefter navnet op fra en anden klient, og forbind til tjenesten ved navn, hvilket prøver DNS-posten, ruten og firewallaen sammen. Bekræft svarvejen på serversiden, da et navn, der slår op, mens tjenesten forbliver utilgængelig, er et rute- eller politikproblem snarere end et navneproblem. Hold tilsidesættelsestabellen ved siden af certifikatlisten, så begge gennemgås sammen.
Et certifikat, der genudstedes under et andet almindeligt navn, holder op med at matche sin tilsidesættelse og sender klienten tilbage til den dynamiske pool. Forvent det efter enhver identitetsændring.