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

Serverhjelpere konfigurerer et undernett og fyller det deretter med en dynamisk pool etter eget valg. Den standarden er praktisk helt til noen adresser må holdes utenfor tildelingen — enten de er reservert for faste tildelinger eller holdt av til et fremtidig segment. Å undertrykke den automatiske poolen og erklære området selv krever to linjer og én bevisst beslutning om hvilke adresser som ikke er til tildeling. Resten er operativ disiplin: inventar, anvend, verifiser, rull tilbake.

Dette er en endring i en tjeneste som kjører, så behandle den som en operativ oppgave: inventar først, anvend gjennom den normale livssyklusen, verifiser med en ny klient og hold en tilbakerulling klar.

Start med undernettet du allerede har

Les gjeldende serverkonfigurasjon og adressene klientene faktisk holder. Poolendringen gir bare mening mot den basislinjen, og basislinjen er ikke alltid det filen antyder, fordi et administrert produkt eller en konfigurasjonsgenerator kan eie filen du leser.

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

Bekreft topologien som gjelder. Under undernettstopologi tar hver klient én adresse fra poolen; eldre net30-oppsett tildeler en liten blokk per klient, og aritmetikken er helt annerledes. Hvis serveren fortsatt er på net30, er denne siden feil migreringsveiledning, og pooltallene vil ikke bety det du forventer. Kontroller den linjen før du kopierer adressearitmetikk fra andre steder.

Skriv ned serverens egen adresse, hver fast tildeling i mappen for klientkonfigurasjoner og enhver adresse som en rute eller en tilgangsregel avhenger av. Det er disse adressene som må holde seg utenfor det dynamiske området. Å skrive dem ned først er det som gjør området til en beslutning i stedet for en gjetning. Det gir også en tilbakerulling noe konkret å gjenopprette.

Legg til nopool og erklær området

Hjelpenøkkelordet godtar nopool, som beholder undernettkonfigurasjonen og undertrykker den automatiske dynamiske poolen, slik OpenVPN 2.6-håndboken beskriver. Den eksplisitte ifconfig-pool-linjen gir deretter det inklusive området du ønsker, og nettverksmasken samsvarer med undernettet. Begge linjene hører til i samme serverblokk, fordi en pool uten undernettet sitt ikke har noen betydning. Rekkefølgen mellom dem betyr bare noe for lesbarheten, siden hjelperen utvider paret 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 grensene er inklusive, så eksemplet tilbyr syttien adresser. Hold serveradressen og hver fast tildeling utenfor det spennet; en fast tildeling som ligger inne i det dynamiske området gir en kollisjon som avhenger av tilkoblingsrekkefølgen, og det er den verste typen å feilsøke. Ha en margin mellom det reserverte settet og området hvis de faste tildelingene sannsynligvis vil vokse.

Områdets størrelse og samtidighet er atskilte grenser. Hundre adresser betyr ikke hundre samtidige klienter hvis max-clients sier noe annet, og en pool som er større enn samtidighetsgrensen er normalt og ikke sløsing. Det viktige er at de to grensene velges bevisst i stedet for å arves fra en standard.

Hold faste tildelinger utenfor det dynamiske området

En klientspesifikk ifconfig-push er en annen mekanisme enn tildeling fra poolen, og den må bruke parametere som passer til den aktive topologien. I undernettsmodus er det én adresse og nettverksmaske; å overføre et net30-par fordi det dukket opp i et gammelt eksempel er en vanlig feil.

Tildelingshistorikk er et hint, ikke en autoritet. En persist-fil husker hvilken klient som hadde hvilken adresse, slik at klienter som kobler til på nytt har en tendens til å få den samme, og den reserverer ikke adresser, frigjør dem ikke eller erstatter en fast tildeling. Hvis en bestemt enhet alltid skal ha en bestemt adresse, bruk en fast tildeling i stedet for å stole på persist-filen.

Kontroller deretter banene som avhenger av adresser. En rute som skyves ut til klientene, en brannmurregel som slipper inn et undernett, eller en overvåkingssjekk som forventer en bestemt vert kan alle forutsette det gamle området. Å endre poolen uten å lese dem flytter feilen til et sted som ser urelatert ut.

Anvend gjennom livssyklusen, og verifiser deretter

Anvend endringen slik tjenesten vanligvis mottar konfigurasjon — enten en direkte fil pluss omstart eller et administrasjonslag som genererer filen på nytt. En manuell endring i en generert fil overlever til neste generering, og ikke lenger. Noter hvilken mekanisme som eier filen, fordi neste operatør må vite hvor den samme endringen skal gjøres. Start deretter én gang på nytt og les 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

Koble til en klient som ikke har vært tilkoblet før, og bekreft at adressen ligger innenfor det erklærte området og utenfor det reserverte settet. Bekreft deretter returveien: klienten skal nå det retningslinjen tillater og ikke mer. En adresse som passer planen, men som ikke har en fungerende rute, er ikke en vellykket endring.

Koble til en klient som hadde en adresse fra det gamle området, på nytt. Den skal få en adresse fra det nye området, og all sesjonsnivåtilstand knyttet til den gamle adressen skal være borte. Hvis den beholder den gamle adressen, er det noe annet som tildeler den, og poolen er ikke den eieren du tror.

Tilbakerulling av en områdeendring

Behold de tre forrige linjene i endringsloggen din, ikke bare den forrige filen. Å gjenopprette dem og starte på nytt fører tildelingen tilbake til den gamle oppførselen, og klienter som kobler til etterpå, vil få adresser derfra.

To advarsler hører med i loggen. Klienter som allerede er tilkoblet når du ruller tilbake, beholder sine nåværende adresser til de kobler til på nytt, så en tilbakerulling er ikke umiddelbar i hele flåten. Og hvis det gamle området overlappet en fast tildeling, gjenoppretter en gjenoppretting også kollisjonen; nettopp den overlappingen var grunnen til endringen, og den krever en annen løsning enn en tilbakerulling.

En poolendring er ferdig når en ny klient får en adresse innenfor området, en reservert adresse aldri deles ut, og rutene og reglene som bruker disse adressene fortsatt oppfører seg som tiltenkt. Alt mindre overlater til neste person å finne ut hvilken av de tre som ikke stemmer.