Miksi OpenVPN-palvelimen kokoonpanon kopioiminen sivuliikkeeseen epäonnistuu

Toimivan palvelinkokoonpanon kopioiminen, parin osoitteen vaihtaminen ja sen kutsuminen sivuliikkeen profiiliksi tuottaa yleensä yhteyden. Se on huonoin lopputulos, koska sivuliike toimii silloin väärässä roolissa, paljastaa materiaalia, jonka ei pitäisi lähteä keskuksesta, ja jättää reittiliitoksen, jota kukaan ei muista tehneensä. Yhteys kätkee kolme ongelmaa kerralla, ja tunneli nousee ennen kuin kukaan tarkistaa ne.

Sivuliikkeen kohteleminen omana identiteettinään ja verkkoroolinaan omaavana vertaisena tekee profiilista oikean. Korjaus ei ole parempi kopio, ja tämän sivun loppu kertoo siitä, mitä asiakkaan pitäisi oikeastaan pitää.

Kaksi roolia, jotka näyttävät yhdeltä tiedostolta

TLS-tilassa kahdella puolella on toisiaan täydentävät tehtävät. Toinen puoli kuuntelee, pitää palvelimen varmennetta ja avainta ja päättää, mitkä asiakkaat saavat yhdistää. Toinen puoli aloittaa, vahvistaa kuuntelijan ja esittää oman identiteettinsä.

Palvelintiedosto sisältää direktiivejä, joissa ei ole asiakkaalla mitään järkeä: sidontaosoite ja portti kuuntelua varten, osoitepooli jaettavaksi ja usein push-luettelo asetuksista, jotka asiakkaiden pitäisi saada. Niiden kopioiminen sivuliikkeeseen tuottaa laitteen, joka yrittää olla samaan aikaan kuuntelija ja asiakas.

Yksityinen avain on osa, jolla on eniten merkitystä. Asiakas ei saa koskaan kantaa palvelimen yksityistä avainta, eikä se tarvitse myöskään CA:n allekirjoitusavainta. CA-varmenne on julkista luottamusmateriaalia; allekirjoitusavain kuuluu sinne, missä varmenteita myönnetään.

Mitä sivuliikkeen profiilissa täytyy olla

Sivuliikkeen profiili tarvitsee etäpäätepisteen ja kuljetuksen, luotetun palvelinidentiteetin, sivuliikkeen oman varmenteen ja avaimen sekä reitit ja DNS-asetukset, joita sivuliike todella vaatii. Mikään muu ei ole pakollista.

Pidä sivuliikkeen identiteetti erillisenä toimipaikkakohtaisesti. Kaksi sivuliikettä, jotka jakavat yhden varmenteen, tarkoittaa, että toisen peruuttaminen poistaa toisen käytöstä, eivätkä keskuksen lokit erota niitä. Toimipaikkakohtainen identiteetti on se, mikä saa sekä auditointijäljen että peruutustarinan toimimaan.

Ole varovainen laitteiden työnkulkujen kanssa. pfSensen Client Export -paketti tuottaa profiileja kelvollisille Remote Access -konteksteille, ja sen palvelinluettelo sisältää vain Remote Access -tilassa määritetyt palvelimet. Toisen tilan sivusto-sivustolle-palvelin ei näy, ja tämä puuttuminen on tietoa, ei kutsu kopioida palvelimen salaisuuksia.

Jos laite ei vie tarvitsemaasi profiilia, käytä sen dokumentoitua sivusto-sivustolle-asiakastyönkulkua tai rakenna profiili asennetun julkaisun tuetusta esimerkistä. Vie palvelimen varmuuskopio sivuliikkeeseen vain jos suunnitelma on palauttaa palvelin, mitä se ei ole. Varmuuskopio kantaa myös keskuksen yksityistä materiaalia, joten sen siirtäminen sivuliikkeeseen on avainten käsittelyn päätös, ei tiedostonsiirto. Pidä se keskuksessa ja luo asiakkaan identiteetti siellä, missä varmenteita myönnetään.

Vertaisen ja verkon välinen liitos on erillinen

Sivuliikkeen asiakas, joka yhdistää onnistuneesti, ei silti voi välittää liikennettä LAN-verkkoonsa ennen kuin keskus tietää, että tämä vertainen omistaa kyseisen etuliitteen. Tämä liitos elää keskuksessa, asiakkaan identiteettiin sidottuna, ja se on erillinen sivuliikkeen omasta reitistä kohti etäverkkoja. Ilman sitä sivuliikkeen isännät näyttävät tunnelin tilastoissa tavoitettavilta ja ovat käytännössä tavoittamattomia. Keskuksen loki on paikka, jossa vahvistetaan, sovellettiinko liitosta.

Reitin lisääminen keskuksen käyttöjärjestelmään ei ole sama asia kuin kertoa OpenVPN:lle, mikä asiakas omistaa etuliitteen. Ilman asiakaskohtaista liitosta paketti saavuttaa tunnelin rajapinnan ja pudotetaan, koska mikään vertainen ei vaadi kohdetta.

Sivuliikkeen puolella vastaava tarve on reitti verkkoihin, joihin sen pitää päästä, sekä LAN-reititin, joka osaa palauttaa liikenteen sivuliikkeeseen. Palvelinpuolen omistus ja asiakaspuolen kohdereitit ovat erillisiä objekteja, ja toimiva tunneli todistaa vain ensimmäisen hypyn. Kirjoita molemmat sivuliikkeen luovutusmuistiinpanoihin, koska seuraava insinööri löytää niistä vain toisen.

Sen todistaminen, että sivuliike on se vertainen, jota luulet

Vahvista identiteetti ennen liikenteen vahvistamista. Keskuksen lokin pitäisi näyttää sivuliikkeen varmenteen yleisnimi, ja asiakkaan saaman osoitteen pitäisi vastata poolia tai kiinteää määritystä, jonka tarkoitit. Jos loki näyttää toisen nimen, profiili kantaa jonkun muun identiteettiä.

Vahvista sitten liitos lähettämällä yksi pyyntö sivuliikkeen isännästä keskuksen puolella olevalle resurssille ja vahvista, että se onnistuu odotetulla lähdeosoitteella. Testaa kohde, johon sivuliike ei saa päästä, ja vahvista, että se epäonnistuu, koska sattumalta toimiva salliva reitti ei ole sama asia kuin oikea käytäntö.

Peruuta lopuksi sivuliikkeen identiteetti ja vahvista, että yhteys epäonnistuu samalla kun keskuksen oma varmenne ja muut toimipaikat toimivat edelleen. Jos peruuttaminen rikkoo keskuksen, rooleja ja identiteettejä jaettiin jossain, ja se on havainto, joka kannattaa viedä takaisin suunnitteluun.

Valmis sivuliike on sellainen, jolla on dokumentoitu identiteetti, vain asiakkaalle tarkoitettu profiili, vertaisen ja verkon välinen liitos keskuksessa ja testattu paluureitti. Tekstin kääntäminen palvelintiedostossa ei anna sinulle yhtäkään niistä.