Hvorfor kopiering af OpenVPN-serverkonfigurationen til en filial mislykkes

At kopiere den fungerende serverkonfiguration, bytte et par adresser og kalde det en filialprofil giver normalt en forbindelse. Det er det værste udfald, fordi filialen derefter kører med den forkerte rolle, blotlægger materiale, som ikke burde forlade hubben, og efterlader en rutetilknytning, som ingen husker at have lavet. Forbindelsen skjuler tre problemer på én gang, og tunnelen kommer op, før nogen kontrollerer dem.

At behandle filialen som en peer med sin egen identitet og netværksrolle er det, der gør profilen korrekt. Rettelsen er ikke en bedre kopi, og resten af denne side handler om, hvad en klient egentlig bør have.

To roller, der ligner én fil

I TLS-tilstand har de to parter komplementære opgaver. Den ene side lytter, har servercertifikatet og nøglen og afgør, hvilke klienter der må forbinde. Den anden side starter, verificerer lytteren og fremviser sin egen identitet.

En serverfil indeholder direktiver, som ikke giver mening på en klient: en bind-adresse og port at lytte på, en pulje af adresser at dele ud og ofte en push-liste til indstillinger, som klienterne bør modtage. At kopiere dem til en filial giver en enhed, der forsøger at være lytter og klient på samme tid.

Den private nøgle er den del, der betyder mest. En klient må aldrig bære serverens private nøgle, og den har heller ikke brug for CA'ens signeringsnøgle. Et CA-certifikat er offentligt tillidsmateriale; signeringsnøglen hører til der, hvor certifikater udstedes.

Hvad en filialprofil skal indeholde

En filialprofil skal bruge det eksterne endepunkt og transporten, den betroede serveridentitet, filialens eget certifikat og nøgle samt de ruter og DNS-indstillinger, som filialen faktisk kræver. Intet andet er obligatorisk.

Hold filialens identitet adskilt pr. lokalitet. To filialer, der deler ét certifikat, betyder, at tilbagekaldelse af den ene slår den anden ud, og hubbens logfiler kan ikke skelne dem. En identitet pr. lokalitet er det, der får både revisionssporet og tilbagekaldelseshistorien til at fungere.

Vær forsigtig med appliance-arbejdsgange. pfSense's Client Export-pakke laver profiler til kvalificerede Remote Access-kontekster, og dens serverliste indeholder kun servere, der er konfigureret i en Remote Access-tilstand. En site-til-site-server i en anden tilstand vises ikke, og den fraværenhed er information, ikke en invitation til at kopiere serverens hemmeligheder.

Hvis applikationen ikke eksporterer den profil, du har brug for, så brug dens dokumenterede site-til-site-klientarbejdsgang eller byg profilen ud fra den installerede udgaves understøttede eksempel. Eksporter kun en serverbackup til filialen, hvis planen er at gendanne en server, og det er den ikke. En backup bærer også hubbens private materiale, så at flytte en til en filial er en nøglehåndteringsbeslutning, ikke en filoverførsel. Hold den på hubben, og generér klientidentiteten der, hvor certifikater udstedes.

Tilknytningen mellem peer og netværk er separat

En filialklient, der forbinder med succes, kan stadig ikke sende trafik for sit LAN, før hubben ved, at denne peer ejer det præfiks. Den tilknytning ligger på hubben, knyttet til klientens identitet, og den er adskilt fra filialens egen rute mod de eksterne netværk. Uden den ser filialens værter tilgængelige ud i tunnelens statistik og er utilgængelige i praksis. Hubbens log er stedet, hvor man bekræfter, om tilknytningen blev anvendt.

At tilføje en rute i hubbens styresystem er ikke det samme som at fortælle OpenVPN, hvilken klient der ejer præfikset. Uden tilknytningen pr. klient når pakken tunnelinterfacet og droppes, fordi ingen peer gør krav på destinationen.

På filialssiden er det tilsvarende behov en rute mod de netværk, den skal nå, plus en LAN-router, der ved, hvordan trafik returneres til filialen. Ejerskab på serversiden og destinationsruter på klientsiden er forskellige objekter, og en fungerende tunnel beviser kun det første hop. Skriv begge ned i filialens overdragelsesnoter, fordi den næste ingeniør kun finder én af dem.

At bevise, at filialen er den peer, du tror

Verificer identitet, før du verificerer trafik. Hubbens log bør vise filialens certifikats common name, og den adresse, klienten fik, bør passe til den pulje eller faste tildeling, du havde tænkt. Hvis loggen viser et andet navn, bærer profilen en andens identitet.

Verificer derefter tilknytningen ved at sende én anmodning fra en vært i filialen til en ressource på hubbens side og bekræfte, at den lykkes med den forventede kildeaddress. Test en destination, som filialen ikke må nå, og bekræft, at den fejler, fordi en eftergivende rute, der tilfældigvis virker, ikke er det samme som en korrekt politik.

Til sidst tilbagekald filialens identitet, og bekræft at forbindelsen fejler, mens hubbens eget certifikat og andre lokaliteter fortsat virker. Hvis tilbagekaldelsen ødelægger hubben, blev roller og identiteter delt et sted, og det er den pointe, der er værd at tage tilbage til designet.

En færdig filial er en med dokumenteret identitet, en profil kun til klient, en tilknytning mellem peer og netværk på hubben og en testet returvej. At vende teksten i en serverfil giver dig ingen af dem.