Waarom het kopiëren van de OpenVPN-serverconfiguratie naar een filiaal mislukt

De werkende serverconfiguratie kopiëren, een paar adressen verwisselen en het dan een filiaalprofiel noemen levert meestal een verbinding op. Dat is de slechtste uitkomst, want het filiaal draait dan met de verkeerde rol, legt materiaal bloot dat de hub niet zou mogen verlaten, en laat een routekoppeling achter die niemand zich herinnert te hebben gemaakt. De verbinding verbergt drie problemen tegelijk, en de tunnel komt op voordat iemand ze controleert.

Het filiaal behandelen als een peer met een eigen identiteit en netwerkrol is wat het profiel correct maakt. De oplossing is geen betere kopie, en de rest van deze pagina gaat over wat een client werkelijk zou moeten houden.

Twee rollen die op één bestand lijken

In TLS-modus hebben de twee kanten elkaar aanvullende taken. De ene kant luistert, houdt het servercertificaat en de sleutel en bepaalt welke clients mogen verbinden. De andere kant start, verifieert de luisteraar en presenteert zijn eigen identiteit.

Een serverbestand bevat richtlijnen die op een client nergens op slaan: een bindadres en poort om op te luisteren, een pool adressen om uit te delen en vaak een pushlijst voor instellingen die de clients moeten ontvangen. Die naar een filiaal kopiëren levert een apparaat op dat tegelijk luisteraar en client probeert te zijn.

De privésleutel is het onderdeel dat het meest telt. Een client mag nooit de privésleutel van de server dragen, en heeft ook de ondertekeningssleutel van de CA niet nodig. Een CA-certificaat is openbaar vertrouwensmateriaal; de ondertekeningssleutel hoort waar certificaten worden uitgegeven.

Wat een filiaalprofiel moet bevatten

Een filiaalprofiel heeft het externe eindpunt en het transport nodig, de vertrouwde serveridentiteit, het eigen certificaat en de sleutel van het filiaal, en de routes en DNS-instellingen die het filiaal echt nodig heeft. Niets anders is verplicht.

Houd de identiteit van het filiaal per locatie gescheiden. Twee filialen die één certificaat delen betekent dat het intrekken van de een de ander uitschakelt, en de logs van de hub kunnen ze niet onderscheiden. Een identiteit per locatie is wat zowel het auditspoor als het intrekkingsverhaal laat werken.

Wees voorzichtig met apparaatworkflows. Het Client Export-pakket van pfSense maakt profielen voor geschikte Remote Access-contexten, en de serverlijst bevat alleen servers die in een Remote Access-modus zijn geconfigureerd. Een site-naar-site-server van een andere modus verschijnt niet, en die afwezigheid is informatie, geen uitnodiging om de geheimen van de server te kopiëren.

Als het apparaat het profiel dat u nodig hebt niet exporteert, gebruik dan de gedocumenteerde site-naar-site-clientworkflow of bouw het profiel uit het ondersteunde voorbeeld van de geïnstalleerde release. Exporteer alleen een serverback-up naar het filiaal als het plan is een server te herstellen, wat het niet is. Een back-up draagt ook het privémateriaal van de hub, dus er een naar een filiaal verplaatsen is een sleutelbeheerbeslissing, geen bestandsoverdracht. Houd hem op de hub en genereer de clientidentiteit waar certificaten worden uitgegeven.

De koppeling tussen peer en netwerk staat apart

Een filiaalclient die met succes verbindt, kan nog steeds geen verkeer voor zijn LAN doorlaten totdat de hub weet dat deze peer dat prefix bezit. Die koppeling staat op de hub, gekoppeld aan de identiteit van de client, en staat apart van de eigen route van het filiaal naar de externe netwerken. Zonder die koppeling lijken de hosts van het filiaal bereikbaar in de statistieken van de tunnel en zijn ze dat in de praktijk niet. Het log van de hub is de plek om te bevestigen of de koppeling is toegepast.

Een route toevoegen in het besturingssysteem van de hub is niet hetzelfde als OpenVPN vertellen welke client het prefix bezit. Zonder de koppeling per client bereikt het pakket de tunnelinterface en wordt het weggegooid omdat geen peer de bestemming opeist.

Aan de filiaalkant is de overeenkomstige behoefte een route naar de netwerken die het moet bereiken, plus een LAN-router die weet hoe verkeer naar het filiaal teruggaat. Eigendom aan de serverkant en bestemmingsroutes aan de clientkant zijn verschillende objecten, en een werkende tunnel bewijst alleen de eerste sprong. Schrijf beide op in de overdrachtsnotities van het filiaal, want de volgende ingenieur vindt er maar één van.

Bewijzen dat het filiaal de peer is die u denkt

Verifieer de identiteit voordat u het verkeer verifieert. Het log van de hub hoort de common name van het certificaat van het filiaal te tonen, en het adres dat de client kreeg hoort te passen bij de pool of vaste toewijzing die u bedoelde. Als het log een andere naam toont, draagt het profiel de identiteit van iemand anders.

Verifieer daarna de koppeling door één verzoek van een host in het filiaal naar een resource aan de hubkant te sturen en te bevestigen dat het slaagt met het verwachte bronadres. Test een bestemming die het filiaal niet mag bereiken en bevestig dat het mislukt, want een toegeeflijke route die toevallig werkt is niet hetzelfde als een correct beleid.

Trek ten slotte de identiteit van het filiaal in en bevestig dat de verbinding mislukt terwijl het eigen certificaat van de hub en andere locaties blijven werken. Als het intrekken de hub breekt, zijn rollen en identiteiten ergens gedeeld, en dat is de bevinding die het waard is terug te nemen naar het ontwerp.

Een afgerond filiaal is er een met een gedocumenteerde identiteit, een profiel alleen voor de client, een koppeling tussen peer en netwerk op de hub en een geteste terugweg. Tekst in een serverbestand omdraaien levert u daar niets van op.