Hvorfor kopiering av OpenVPN-serverkonfigurasjonen til en filial mislykkes

Å kopiere den fungerende serverkonfigurasjonen, bytte et par adresser og kalle det en filialprofil gir vanligvis en tilkobling. Det er det verste utfallet, fordi filialen da kjører med feil rolle, eksponerer materiale som ikke burde forlate navet, og etterlater en ruteassosiasjon som ingen husker å ha laget. Tilkoblingen skjuler tre problemer på én gang, og tunnelen kommer opp før noen kontrollerer dem.

Å behandle filialen som en peer med egen identitet og nettverksrolle er det som gjør profilen riktig. Rettelsen er ikke en bedre kopi, og resten av denne siden handler om hva en klient egentlig bør holde.

To roller som ser ut som én fil

I TLS-modus har de to sidene komplementære oppgaver. Den ene siden lytter, holder serverens sertifikat og nøkkel og avgjør hvilke klienter som får koble til. Den andre siden starter, verifiserer lytteren og presenterer sin egen identitet.

En serverfil inneholder direktiver som ikke gir mening på en klient: en bind-adresse og port å lytte på, en pool med adresser å dele ut og ofte en push-liste for innstillinger klientene skal motta. Å kopiere dem til en filial gir en enhet som prøver å være lytter og klient samtidig.

Den private nøkkelen er delen som betyr mest. En klient må aldri bære serverens private nøkkel, og den trenger heller ikke CA-ens signeringsnøkkel. Et CA-sertifikat er offentlig tillitsmateriale; signeringsnøkkelen hører hjemme der sertifikater utstedes.

Hva en filialprofil må inneholde

En filialprofil trenger det eksterne endepunktet og transporten, den betrodde serveridentiteten, filialens eget sertifikat og nøkkel, og rutene og DNS-innstillingene filialen faktisk krever. Ingenting annet er obligatorisk.

Hold filialens identitet atskilt per sted. To filialer som deler ett sertifikat betyr at tilbakekalling av den ene slår ut den andre, og navets logger kan ikke skille dem. En identitet per sted er det som får både revisjonssporet og tilbakekallingshistorien til å virke.

Vær forsiktig med apparat-arbeidsflyter. pfSens Client Export-pakke lager profiler for kvalifiserte Remote Access-kontekster, og serverlisten inneholder bare servere som er konfigurert i en Remote Access-modus. En site-til-site-server i en annen modus vises ikke, og det fraværet er informasjon, ikke en invitasjon til å kopiere serverens hemmeligheter.

Hvis apparatet ikke eksporterer profilen du trenger, bruk den dokumenterte site-til-site-klientarbeidsflyten eller bygg profilen fra det støttede eksempelet i den installerte versjonen. Eksporter bare en serversikkerhetskopi til filialen hvis planen er å gjenopprette en server, noe den ikke er. En sikkerhetskopi bærer også navets private materiale, så å flytte en til en filial er en nøkkelhåndteringsbeslutning, ikke en filoverføring. Hold den på navet og generer klientidentiteten der sertifikater utstedes.

Assosiasjonen mellom peer og nettverk er separat

En filialklient som kobler til med hell kan fortsatt ikke sende trafikk for LAN-et sitt før navet vet at denne peeren eier det prefikset. Den assosiasjonen ligger på navet, knyttet til klientens identitet, og den er atskilt fra filialens egen rute mot de eksterne nettene. Uten den ser filialens verter ut til å være tilgjengelige i tunnelens statistikk og er det ikke i praksis. Navets logg er stedet der man bekrefter om assosiasjonen ble brukt.

Å legge til en rute i navets operativsystem er ikke det samme som å fortelle OpenVPN hvilken klient som eier prefikset. Uten assosiasjonen per klient når pakken tunnelgrensesnittet og slippes fordi ingen peer gjør krav på målet.

På filialsiden er det tilsvarende behovet en rute mot nettene den skal nå, pluss en LAN-ruter som vet hvordan trafikk returneres til filialen. Eierskap på serversiden og målruter på klientsiden er ulike objekter, og en fungerende tunnel beviser bare det første hoppet. Skriv ned begge i filialens overleveringsnotater, fordi den neste ingeniøren bare finner én av dem.

Å bevise at filialen er peeren du tror

Verifiser identitet før du verifiserer trafikk. Navets logg bør vise filialens sertifikats common name, og adressen klienten fikk bør stemme med poolen eller den faste tildelingen du mente. Hvis loggen viser et annet navn, bærer profilen noen andres identitet.

Verifiser deretter assosiasjonen ved å sende én forespørsel fra en vert i filialen til en ressurs på navets side og bekreft at den lykkes med den forventede kildeadressen. Test et mål filialen ikke skal nå og bekreft at det feiler, fordi en ettergivende rute som tilfeldigvis virker ikke er det samme som en riktig policy.

Til slutt tilbakekaller du filialens identitet og bekrefter at tilkoblingen feiler mens navets eget sertifikat og andre steder fortsetter å virke. Hvis tilbakekallingen ødelegger navet, ble roller og identiteter delt et sted, og det er funnet som er verdt å ta med tilbake til designet.

En ferdig filial er en med dokumentert identitet, en profil kun for klient, en assosiasjon mellom peer og nettverk på navet og en testet returvei. Å snu teksten i en serverfil gir deg ingen av dem.