OpenVPN-server med nopool: erklær et eksplicit poolområde

Serverhjælpere konfigurerer et undernet og fylder det derefter med en dynamisk pool efter eget valg. Den standard er bekvem, indtil nogle adresser skal holdes uden for tildelingen, hvad enten de er reserveret til faste tildelinger eller holdt tilbage til et fremtidigt segment. At undertrykke den automatiske pool og selv erklære området kræver to linjer og én bevidst beslutning om, hvilke adresser der ikke er til tildeling. Resten er operationel disciplin: inventar, anvend, verificér, rul tilbage.

Dette er en ændring af en kørende tjeneste, så behandl den som en operationel opgave: inventar først, anvend gennem den normale livscyklus, verificér med en ny klient, og hold en tilbagerulning klar.

Begynd med det undernet, du allerede har

Læs den aktuelle serverkonfiguration og de adresser, klienterne faktisk holder. Poolændringen giver kun mening mod den baseline, og baselinen er ikke altid det, filen antyder, fordi et administreret produkt eller en konfigurationsgenerator kan eje den fil, du læser.

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

Bekræft den gældende topologi. Under undernetstopologi tager hver klient én adresse fra poolen; ældre net30-layouts tildeler en lille blok til hver klient, og aritmetikken er helt anderledes. Hvis serveren stadig kører net30, er denne side den forkerte migrationsguide, og pooltallene betyder ikke det, du forventer. Kontrollér den linje, før du kopierer adressearitmetik fra andre steder.

Skriv serverens egen adresse ned, hver fast tildeling i mappen med klientkonfigurationer og enhver adresse, som en rute eller en adgangsregel afhænger af. Det er de adresser, der skal blive uden for det dynamiske område. At skrive dem ned først er det, der gør området til en beslutning i stedet for et gæt. Det giver også en tilbagerulning noget konkret at gendanne.

Tilføj nopool, og erklær området

Hjælpenøgleordet accepterer nopool, som beholder undernetskonfigurationen og undertrykker den automatiske dynamiske pool, som OpenVPN 2.6-manualen beskriver. Den eksplicitte ifconfig-pool-linje leverer derefter det inklusive område, du ønsker, og dens netmaske svarer til undernettet. Begge linjer hører i samme serverblok, fordi en pool uden sit undernet ikke har nogen betydning. Rækkefølgen mellem dem betyder kun noget for læsbarheden, da hjælperen udfolder parret, når tjenesten starter.

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

Begge grænser er inklusive, så eksemplet tilbyder enoghalvfjerds adresser. Hold serveradressen og hver fast tildeling uden for det spænd; en fast tildeling, der ligger inden for det dynamiske område, giver en kollision, der afhænger af forbindelsesrækkefølgen, og det er den værste slags at fejlfinde. Behold en margen mellem det reserverede sæt og området, hvis de faste tildelinger sandsynligvis vokser.

Områdets størrelse og samtidighed er adskilte grænser. Hundrede adresser betyder ikke hundrede samtidige klienter, hvis max-clients siger noget andet, og en pool, der er større end samtidighedsgrænsen, er normalt frem for spild. Det vigtige er, at de to grænser vælges bevidst i stedet for at arves fra en standard.

Hold faste tildelinger uden for det dynamiske område

En klientspecifik ifconfig-push er en anden mekanisme end tildeling fra poolen, og den skal bruge parametre, der passer til den aktive topologi. I undernetsmodus er det en enkelt adresse og netmaske; at overføre et net30-par, fordi det optrådte i et gammelt eksempel, er en almindelig fejl.

Tildelingshistorik er et hint, ikke en autoritet. En persist-fil husker, hvilken klient der havde hvilken adresse, så klienter, der genopretter forbindelse, har tendens til at få den samme, og den reserverer ikke adresser, frigiver dem ikke og erstatter ikke en fast tildeling. Hvis en bestemt enhed altid skal have en bestemt adresse, brug en fast tildeling i stedet for at stole på persist-filen.

Kontrollér derefter de stier, der afhænger af adresser. En rute, der skubbes til klienterne, en firewallregel, der tillader et undernet, eller et overvågningstjek, der forventer en bestemt vært, kan alle forudsætte det gamle område. At ændre poolen uden at læse dem flytter fejlen til et sted, der ser uvedkommende ud.

Anvend gennem livscyklussen, og verificér derefter

Anvend ændringen, som tjenesten normalt modtager konfiguration — hvad enten det er en direkte fil plus genstart eller et administrationslag, der gendanner filen. En manuel redigering af en genereret fil overlever til næste generering og ikke længere. Notér, hvilken mekanisme der ejer filen, fordi den næste operatør skal vide, hvor den samme ændring skal laves. Genstart derefter én gang, og læs loggen, før du inviterer en klient.

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

Tilslut en klient, der ikke har været tilsluttet før, og bekræft, at adressen ligger inden for det erklærede område og uden for det reserverede sæt. Bekræft derefter returvejen: klienten bør nå det, politikken tillader, og intet mere. En adresse, der passer til planen, men ikke har nogen fungerende rute, er ikke en vellykket ændring.

Tilslut igen en klient, der havde en adresse fra det gamle område. Den bør få en adresse fra det nye område, og enhver sessionstilstand knyttet til den gamle adresse bør være væk. Hvis den beholder den gamle adresse, er det noget andet, der tildeler den, og poolen er ikke den ejer, du tror.

Tilbagerulning af en områdeændring

Behold de forrige tre linjer i din ændringslog, ikke kun den forrige fil. At gendanne dem og genstarte bringer tildelingen tilbage til den gamle adfærd, og klienter, der derefter genopretter forbindelse, vil få adresser derfra.

To forbehold hører med i loggen. Klienter, der allerede er tilsluttet, når du ruller tilbage, beholder deres nuværende adresser, indtil de genopretter forbindelse, så en tilbagerulning er ikke øjeblikkelig i hele flåden. Og hvis det gamle område overlappede en fast tildeling, gendanner en gendannelse også kollisionen; netop den overlapning var grunden til ændringen, og den kræver en anden løsning end en tilbagerulning.

En poolændring er færdig, når en ny klient får en adresse inden for området, en reserveret adresse aldrig uddeles, og de ruter og regler, der bruger disse adresser, stadig opfører sig som tilsigtet. Alt mindre overlader det til den næste person at finde ud af, hvilken af de tre der ikke holder.