Kvifor kopiering av OpenVPN-serverkonfigurasjonen til ei filial mislukkast

Å kopiere den fungerande serverkonfigurasjonen, bytte eit par adresser og kalle det ein filialprofil gjev vanlegvis ei tilkopling. Det er det verste utfallet, fordi filiala då køyrer med feil rolle, eksponerer materiale som ikkje burde forlate navet, og lèt etter seg ein ruteassosiasjon som ingen hugsar å ha laga. Tilkoplinga løyner tre problem på ein gong, og tunnelen kjem opp før nokon kontrollerer dei.

Å handsame filiala som ein peer med eigen identitet og nettverksrolle er det som gjer profilen riktig. Rettinga er ikkje ei betre kopi, og resten av denne sida handlar om kva ein klient eigentleg bør halde.

To roller som ser ut som éi fil

I TLS-modus har dei to sidene komplementære oppgåver. Den eine sida lyttar, held sertifikatet og nøkkelen til serveren og avgjer kva klientar som får kople til. Den andre sida startar, verifiserer lyttaren og presenterer sin eigen identitet.

Ei serverfil inneheld direktiv som ikkje gjev meining på ein klient: ei bind-adresse og ei port å lytte på, ein pool med adresser å dele ut og ofte ei push-liste for innstillingar klientane skal få. Å kopiere dei til ei filial gjev eit apparat som prøver å vere lyttar og klient samstundes.

Den private nøkkelen er delen som veg mest. Ein klient må aldri bere den private nøkkelen til serveren, og han treng heller ikkje signeringsnøkkelen til CA-en. Eit CA-sertifikat er offentleg tillitsmateriale; signeringsnøkkelen høyrer til der sertifikat blir gjevne ut.

Kva ein filialprofil må innehalde

Ein filialprofil treng det eksterne endepunktet og transporten, den betrudde serveridentiteten, filiala sitt eige sertifikat og nøkkel, og rutene og DNS-innstillingane filiala faktisk krev. Ingenting anna er obligatorisk.

Hald identiteten til filiala åtskild per stad. To filialer som deler eitt sertifikat tyder at tilbakekalling av den eine slår ut den andre, og loggane til navet kan ikkje skilje dei. Ein identitet per stad er det som får både revisjonssporet og tilbakekallingshistoria til å verke.

Ver varsam med apparat-arbeidsflytar. Client Export-pakken til pfSense lagar profilar for kvalifiserte Remote Access-kontekstar, og serverlista inneheld berre serverar som er konfigurerte i ein Remote Access-modus. Ein site-til-site-server i ein annan modus blir ikkje vist, og det fråværet er informasjon, ikkje ei innbyding til å kopiere løyndomane til serveren.

Viss apparatet ikkje eksporterer profilen du treng, bruk den dokumenterte site-til-site-klientarbeidsflyten eller bygg profilen frå det støtta dømet i den installerte versjonen. Eksporter berre ein serversikkerheitskopi til filiala viss planen er å gjenopprette ein server, noko han ikkje er. Ein sikkerheitskopi ber òg det private materialet til navet, så å flytte ein til ei filial er ei nøkkelhandsaming-savgjerd, ikkje ei filoverføring. Hald han på navet og generer klientidentiteten der sertifikat blir gjevne ut.

Assosiasjonen mellom peer og nettverk er åtskild

Ein filialklient som koplar til med hell kan framleis ikkje sleppe gjennom trafikk for LAN-et sitt før navet veit at denne peeren eig det prefikset. Den assosiasjonen ligg på navet, knytt til identiteten til klienten, og han er åtskild frå filiala si eiga rute mot dei eksterne netta. Utan han ser vertane i filiala ut til å vere tilgjengelege i statistikken til tunnelen og er det ikkje i praksis. Loggen til navet er staden der ein stadfester om assosiasjonen vart nytta.

Å leggje til ei rute i operativsystemet til navet er ikkje det same som å fortelje OpenVPN kva klient som eig prefikset. Utan assosiasjonen per klient når pakken tunnelgrensesnittet og blir sleppt fordi ingen peer gjer krav på målet.

På filialsida er det tilsvarande behovet ei rute mot netta ho skal nå, pluss ein LAN-rutar som veit korleis trafikk blir returnert til filiala. Eige på serversida og målruter på klientsida er ulike objekt, og ein fungerande tunnel beviser berre det første hoppet. Skriv ned båe i overleveringsnotata til filiala, fordi den neste ingeniøren finn berre éin av dei.

Å bevisa at filiala er den peeren du trur

Verifiser identiteten før du verifiserer trafikken. Loggen til navet bør vise det vanlege namnet på sertifikatet til filiala, og adressa klienten fekk bør stemme med poolen eller den faste tildelinga du meinte. Viss loggen viser eit anna namn, ber profilen identiteten til nokon andre.

Verifiser deretter assosiasjonen ved å sende éin førespurnad frå ein vert i filiala til ein ressurs på navets side og stadfest at han lukkast med den venta kjeldeadressa. Test eit mål filiala ikkje skal nå og stadfest at det mislukkast, fordi ei ettergjevande rute som tilfeldigvis verkar ikkje er det same som ein riktig policy.

Til slutt kallar du tilbake identiteten til filiala og stadfester at tilkoplinga mislukkast medan sertifikatet til navet sjølv og andre stader held fram med å verke. Viss tilbakekallinga øydelegg navet, vart roller og identitetar delte ein stad, og det er funnet som er verdt å ta med tilbake til designet.

Ei ferdig filial er ei med dokumentert identitet, ein profil berre for klient, ein assosiasjon mellom peer og nettverk på navet og ein testa returveg. Å snu teksten i ei serverfil gjev deg ingen av dei.