Toimintaohje: kahden OpenVPN-asiakkaan erillinen käyttöönotto

Kaksi asiakasta yhdellä isännällä kuulostaa vielä yhdeltä palvelinlohkolta ja toiselta portilta. Siitä tulee eri projekti, kun luettelet kaiken, mitä asiakas todella omistaa: kuuntelija, tunnelipooli, identiteetti, luottamustiedostot, reitit ja mitätöintiaikataulu. Jätä yksi pois, niin toinen asiakas perii hiljaa palan ensimmäisestä. Rakenna kortti asiakasta kohden ja täytä se ennen kuin ensimmäinen asiakas yhdistää.

Anna jokaiselle asiakkaalle täydellinen resurssikortti

Varaa koko joukko yhdessä: julkinen portti, tunnelin aliverkko, kokoonpanopolku, lokien kohde, palveluinstanssin nimi ja laite. Niiden nimeäminen ryhmäksi estää klassisen kopion toimivasta tiedostosta, joka sisältää yhä ensimmäisen asiakkaan poolin tai liittymän. Arvot ovat esimerkkejä, eivät varattuja portteja, joten tarkista, mitä isäntä jo käyttää. Käynnistyvä palvelu ei ole sama asia kuin valmis asiakas.

Pidä kortti kokoonpanon vieressä ja päivitä se aina, kun arvo muuttuu. Todellisuudesta ajautuva dokumentaatio on huonompi kuin ei mitään.

Pidä luottamusmateriaali kunkin asiakkaan sisällä

Erillinen myöntävä viranomainen asiakasta kohden tekee rajasta helpon perustella ja pitää allekirjoitusavaimen poissa internetiin näkyvältä isännältä. Jaettu juuri voi myös toimia, mutta yhteinen ankkuri ei tee kahdesta palvelusta yhtä jäsenyysverkkotunnusta. Päätä, mitkä ketjut kukin kuuntelija hyväksyy ja mitkä asiakasidentiteetit se valtuuttaa, ja kirjaa molemmat. Älä riivi varmenteita ketjusta yrityksen ja erehdyksen kautta, kunnes jokin yhdistyy.

Palvelimen oma yksityinen avain kuuluu asiakaskohtaiseen suojattuun tiedostoon, ei mallihakemistoon, joka replikoidaan kokoonpanon mukana.

Erota verkot samoin kuin prosessit

Kaksi prosessia kahdella portilla jakaa yhä isännän ja reititystaulukon, ellet erota niitä. Vahvista, mikä kuuntelee, ennen kuin luotat suunnitelmaan.

ss -lunp | grep -E '1194|1195'
openssl verify -CAfile customer-a/ca.crt customer-a/client.pem

Kuuntelijatarkistus näyttää, mikä prosessi omistaa kunkin julkisen portin, ja varmennus näyttää, ketjuttuuko asiakasvarmenne aiottuun ankkuriin. Kumpikaan tuloste ei todista, ettei A:n asiakas voi tavoittaa B:n aliverkkoa, joten määrittele lähde- ja kohdekäytäntö, paluureitit ja mahdollinen tarkoituksella jaettu palvelu. Verkkonimiavaruudet tai kontit erottavat reitityskontekstit ja vähentävät tahatonta sekoittumista, mutta ne eivät ole täydellinen vuokralaisen raja itsessään. Valitse vahvempi eristysmekanismi, kun uhkamalli sitä vaatii.

Toimita mitätöinti ennen luovutusta

Varmenteen käyttöönotto ei ole valmis, ennen kuin mitätöinnillä on toimitustie. Tarkista CRL:n myöntäjä ja voimassaoloikkuna osana käyttöönottoa.

openssl crl -in customer-a/crl.pem -noout -lastupdate -nextupdate
systemctl status openvpn@customer-a

CRL-tarkistus raportoi, milloin luettelo myönnettiin ja milloin se vanhenee, ja palvelun tila vahvistaa, että sitä lukeva instanssi on käynnissä. Päivitä luettelo myöntökäytännön aikataulun mukaan, vaikka mitään uutta ei olisi mitätöity, koska vanhentunut CRL voi hylätä jokaisen asiakkaan. Julkaise täydellinen tiedosto sen sijaan, että lukijat kohtaavat osittaisen kirjoituksen, ja validoi allekirjoitus ennen käyttöönottoa. Kirjaa, kuka omistaa myöntämisen, päätepisteen toiminnan ja käytöstä poiston, jotta asiakkaan A sammuttaminen ei häiritse B:tä.

Aja sitten hyväksymispari: sallittu asiakas tavoittaa oman palvelunsa, ja A:n tunnus hylätään B:n kuuntelijan toimesta. Se on raja testinä ilmaistuna.