Varför kopiering av OpenVPN-serverkonfigurationen till en filial misslyckas

Att kopiera den fungerande serverkonfigurationen, byta ett par adresser och kalla det en filialprofil ger vanligtvis en anslutning. Det är det sämsta utfallet, eftersom filialen då kör med fel roll, exponerar material som inte borde lämna navet och lämnar en ruttassociation som ingen minns att den skapade. Anslutningen döljer tre problem på en gång, och tunneln kommer upp innan någon kontrollerar dem.

Att behandla filialen som en peer med egen identitet och nätverksroll är det som gör profilen korrekt. Rättelsen är inte en bättre kopia, och resten av den här sidan handlar om vad en klient egentligen bör hålla.

Två roller som ser ut som en enda fil

I TLS-läge har de två sidorna kompletterande uppgifter. Ena sidan lyssnar, håller serverns certifikat och nyckel och avgör vilka klienter som får ansluta. Andra sidan initierar, verifierar lyssnaren och presenterar sin egen identitet.

En serverfil innehåller direktiv som inte är meningsfulla på en klient: en bindadress och port att lyssna på, en pool av adresser att dela ut och ofta en push-lista för inställningar som klienterna ska få. Att kopiera dem till en filial ger en enhet som försöker vara lyssnare och klient samtidigt.

Den privata nyckeln är den del som betyder mest. En klient får aldrig bära serverns privata nyckel, och den behöver inte heller CA:ns signeringsnyckel. Ett CA-certifikat är offentligt förtroendematerial; signeringsnyckeln hör hemma där certifikat utfärdas.

Vad en filialprofil måste innehålla

En filialprofil behöver den externa slutpunkten och transporten, den betrodda serveridentiteten, filialens eget certifikat och nyckel, samt de rutter och DNS-inställningar som filialen faktiskt kräver. Inget annat är obligatoriskt.

Håll filialens identitet åtskild per plats. Två filialer som delar ett certifikat innebär att återkallning av den ena slår ut den andra, och navets loggar kan inte skilja dem åt. En identitet per plats är det som får både granskningsspåret och återkallningshistorien att fungera.

Var försiktig med apparaternas arbetsflöden. pfSens Client Export-paket skapar profiler för kvalificerade Remote Access-kontexter, och dess serverlista innehåller bara servrar som konfigurerats i ett Remote Access-läge. En site-till-site-server i ett annat läge visas inte, och den frånvaron är information, inte en inbjudan att kopiera serverns hemligheter.

Om apparaten inte exporterar profilen du behöver, använd dess dokumenterade site-till-site-klientarbetsflöde eller bygg profilen från det stödda exemplet i den installerade versionen. Exportera bara en serversäkerhetskopia till filialen om planen är att återställa en server, vilket den inte är. En säkerhetskopia bär också navets privata material, så att flytta en till en filial är ett beslut om nyckelhantering, inte en filöverföring. Håll den på navet och generera klientidentiteten där certifikat utfärdas.

Associationen mellan peer och nätverk är separat

En filialklient som ansluter framgångsrikt kan fortfarande inte släppa igenom trafik för sitt LAN förrän navet vet att den här peeren äger det prefixet. Den associationen ligger på navet, knuten till klientens identitet, och den är åtskild från filialens egen rutt mot de externa nätverken. Utan den ser filialens värdar nåbara ut i tunnelns statistik och är det inte i praktiken. Navets logg är platsen där man bekräftar om associationen tillämpades.

Att lägga till en rutt i navets operativsystem är inte samma sak som att berätta för OpenVPN vilken klient som äger prefixet. Utan associationen per klient når paketet tunnelgränssnittet och släpps eftersom ingen peer gör anspråk på målet.

På filialsidan är motsvarande behov en rutt mot de nätverk den ska nå, plus en LAN-router som vet hur trafik returneras till filialen. Ägande på serversidan och målrutter på klientsidan är olika objekt, och en fungerande tunnel bevisar bara första hoppet. Skriv ned båda i filialens överlämningsanteckningar, eftersom nästa ingenjör bara hittar en av dem.

Att bevisa att filialen är den peer du tror

Verifiera identiteten innan du verifierar trafiken. Navets logg bör visa filialens certifikats common name, och adressen klienten fick bör stämma med den pool eller fasta tilldelning du avsåg. Om loggen visar ett annat namn bär profilen någon annans identitet.

Verifiera sedan associationen genom att skicka en förfrågan från en värd i filialen till en resurs på navets sida och bekräfta att den lyckas med den förväntade källadressen. Testa ett mål som filialen inte får nå och bekräfta att det misslyckas, eftersom en eftergivlig rutt som råkar fungera inte är samma sak som en korrekt policy.

Till sist återkalla filialens identitet och bekräfta att anslutningen misslyckas medan navets eget certifikat och andra platser fortsätter att fungera. Om återkallningen bryter navet delades roller och identiteter någonstans, och det är fyndet som är värt att ta tillbaka till designen.

En färdig filial är en med dokumenterad identitet, en profil enbart för klient, en association mellan peer och nätverk på navet och en testad returväg. Att vända texten i en serverfil ger dig ingen av dem.