OpenVPN-palvelin ja nopool: ilmoita eksplisiittinen poolialue

Palvelimen apurit määrittävät aliverkon ja täyttävät sen sitten oman valintansa mukaisella dynaamisella poolilla. Tämä oletus on kätevä, kunnes joidenkin osoitteiden on pysyttävä jaon ulkopuolella — oli ne varattu kiinteille määrityksille tai pidätetty tulevaa segmenttiä varten. Automaattisen poolin vaientaminen ja alueen ilmoittaminen itse vaatii kaksi riviä ja yhden tietoisen päätöksen siitä, mitkä osoitteet eivät ole jakoa varten. Loppu on operatiivista kurinalaisuutta: kartoitus, käyttöönotto, varmistus, peruutus.

Tämä on muutos käynnissä olevaan palveluun, joten käsittele sitä operatiivisena tehtävänä: ensin kartoitus, sitten käyttöönotto tavallisen elinkaaren kautta, varmistus tuoreella asiakkaalla ja valmiiksi mietitty peruutus.

Aloita aliverkosta, joka sinulla jo on

Lue nykyinen palvelinkokoonpano ja osoitteet, joita asiakkailla todella on. Poolin muutos on mielekäs vain tuota lähtötilannetta vasten, eikä lähtötilanne ole aina se, mitä tiedosto antaa ymmärtää, koska hallinnoitu tuote tai kokoonpanogeneraattori voi omistaa lukemasi tiedoston.

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

Vahvista voimassa oleva topologia. Aliverkkotopologiassa jokainen asiakas ottaa yhden osoitteen poolista; vanhemmat net30-asettelut varaavat pienen lohkon asiakasta kohti ja aritmetiikka on täysin erilaista. Jos palvelin on yhä net30:ssa, tämä sivu on väärä migraatio-opas eivätkä poolin numerot tarkoita sitä, mitä odotat. Tarkista se rivi ennen kuin kopioit osoitearitmetiikkaa muualta.

Kirjoita muistiin palvelimen oma osoite, jokainen kiinteä määritys asiakaskokoonpanojen hakemistossa ja jokainen osoite, josta reitti tai käyttösääntö riippuu. Juuri näiden osoitteiden on pysyttävä dynaamisen alueen ulkopuolella. Niiden ensin kirjaaminen tekee alueesta päätöksen eikä arvauksen. Se antaa myös peruutukselle jotain konkreettista palautettavaa.

Lisää nopool ja ilmoita alue

Apurin avainsana hyväksyy nopool, joka säilyttää aliverkon kokoonpanon ja vaientaa automaattisen dynaamisen poolin, kuten OpenVPN 2.6 -käsikirja kuvaa. Eksplisiittinen rivi ifconfig-pool antaa sitten haluamasi sulkevan alueen, ja sen verkkomaski vastaa aliverkkoa. Molemmat rivit kuuluvat samaan palvelinlohkoon, koska poolilla ilman aliverkkoaan ei ole merkitystä. Niiden välinen järjestys on tärkeä vain luettavuuden vuoksi, sillä apuri laajentaa parin palvelun käynnistyessä.

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

Molemmat rajat ovat sulkevia, joten esimerkki tarjoaa seitsemänkymmentäyksi osoitetta. Pidä palvelimen osoite ja jokainen kiinteä määritys tuon välin ulkopuolella; dynaamisen alueen sisään osuva kiinteä määritys aiheuttaa törmäyksen, joka riippuu yhteyksien järjestyksestä, ja se on ikävin laji vianetsintään. Jätä marginaali varatun joukon ja alueen väliin, jos kiinteät määritykset todennäköisesti kasvavat.

Alueen koko ja samanaikaisuus ovat erillisiä rajoja. Sata osoitetta ei tarkoita sataa samanaikaista asiakasta, jos max-clients sanoo toisin, ja samanaikaisuusrajaa suurempi pool on normaalia eikä tuhlausta. Tärkeää on, että molemmat rajat valitaan tietoisesti eikä peritä oletusarvosta.

Pidä kiinteät määritykset dynaamisen alueen ulkopuolella

Asiakaskohtainen ifconfig-push on eri mekanismi kuin poolista jakaminen, ja sen on käytettävä aktiiviseen topologiaan sopivia parametreja. Aliverkkotilassa se on yksi osoite ja verkkomaski; net30-parin siirtäminen siksi, että se esiintyi vanhassa esimerkissä, on yleinen virhe.

Jakohistoria on vihje, ei auktoriteetti. Persist-tiedosto muistaa, millä asiakkaalla oli mikä osoite, joten uudelleen yhdistävät asiakkaat saavat yleensä saman, eikä se varaa osoitteita, vapauta niitä tai korvaa kiinteää määritystä. Jos tietyn laitteen on aina pidettävä tiettyä osoitetta, käytä kiinteää määritystä sen sijaan, että luotat persist-tiedostoon.

Tarkista sitten polut, jotka riippuvat osoitteista. Asiakkaille työnnetty reitti, aliverkon salliva palomuurisääntö tai tiettyä isäntää odottava valvontatarkistus voivat kaikki olettaa vanhan alueen. Poolin muuttaminen lukematta niitä siirtää vian paikkaan, joka näyttää liittymättömältä.

Ota käyttöön elinkaaren kautta ja varmista sitten

Ota muutos käyttöön niin kuin palvelu yleensä saa kokoonpanonsa — joko suora tiedosto ja uudelleenkäynnistys tai hallintakerros, joka luo tiedoston uudelleen. Käsin tehty muutos luotuun tiedostoon säilyy seuraavaan luontiin eikä pidempään. Kirjaa, mikä mekanismi omistaa tiedoston, koska seuraavan ylläpitäjän on tiedettävä, mihin sama muutos tehdään. Käynnistä sitten kerran uudelleen ja lue loki ennen kuin kutsut asiakkaan.

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

Yhdistä asiakas, joka ei ollut aiemmin yhteydessä, ja vahvista, että osoite osuu ilmoitetun alueen sisään ja varatun joukon ulkopuolelle. Vahvista sitten paluupolku: asiakkaan pitäisi tavoittaa se, minkä käytäntö sallii, eikä enempää. Osoite, joka sopii suunnitelmaan mutta jolla ei ole toimivaa reittiä, ei ole onnistunut muutos.

Yhdistä uudelleen asiakas, jolla oli osoite vanhalta alueelta. Sen pitäisi saada osoite uudelta alueelta, ja vanhaan osoitteeseen sidotun istuntotason tilan pitäisi olla poissa. Jos se pitää vanhan osoitteen, jokin muu määrittää sen eikä pool ole se omistaja, joksi luulet sitä.

Aluemuutoksen peruuttaminen

Säilytä edelliset kolme riviä muutoskirjauksessasi, älä vain edellistä tiedostoa. Niiden palauttaminen ja uudelleenkäynnistys palauttaa jaon vanhaan käyttäytymiseen, ja sen jälkeen uudelleen yhdistävät asiakkaat saavat osoitteita siitä.

Kaksi varoitusta kuuluu kirjaukseen. Asiakkaat, jotka ovat jo yhteydessä peruuttaessasi, pitävät nykyiset osoitteensa, kunnes yhdistävät uudelleen, joten peruutus ei ole välitön koko laivastossa. Ja jos vanha alue meni päällekkäin kiinteän määrityksen kanssa, sen palauttaminen palauttaa myös törmäyksen; juuri tuo päällekkäisyys oli muutoksen syy, ja se vaatii erilaisen korjauksen kuin peruutus.

Poolin muutos on valmis, kun tuore asiakas saa alueen sisäisen osoitteen, varattua osoitetta ei koskaan jaeta ja noita osoitteita käyttävät reitit ja säännöt käyttäytyvät edelleen tarkoitetusti. Kaikki vähemmän jättää seuraavalle henkilölle selvitettäväksi, mikä kolmesta ei pidä paikkaansa.