Statisk nyckel eller TLS för en OpenVPN-länk mellan två parter?

Två maskiner som bara talar med varandra kan behålla den topologin och ändå få förhandlade trafiknycklar. Nätets form och skyddsläget är oberoende val, och det är sammanblandningen av dem som får människor att försöka rotera en statisk hemlighet genom att byta ut en fil medan båda daemonerna fortsätter att köra. Att byta nyckelfilen under ett körande par roterar ingenting. Det statiska nyckelläget, som OpenVPN 2.6 markerar som föråldrat, håller en nyckel under hela tunnelns livstid, så filen på disken och nyckeln i minnet stämmer först igen efter att båda ändarna startats om. Om automatisk förnyelse är kravet måste skyddsläget ändras.

Vad det statiska nyckelläget inte kan

I hemligt läge delar båda parterna en fördelad nyckel som krypterar och autentiserar tunneln direkt. Det finns ingen handskakning, så det finns ingen mekanism för någon sida att föreslå nytt nyckelmaterial, bevisa en identitet eller återhämta sig från en avvikelse utan operatörens ingripande. Båda egenskaperna följer av att en kontrollkanal saknas och inte av ett saknat alternativ, och ingen konfigurationsflagga lägger till en i detta läge.

OpenVPN 2.6-handboken säger uttryckligen att nyckeln består tills en ny genereras. Det är godtagbart för en laboratorielänk eller ett fast par enheter med dokumenterad rotationsprocedur, och oacceptabelt där en långlivad hemlighet är en verklig risk. Ett filbyte skapar ingen ny nyckel för ett körande par; det skapar två parter som inte är överens. Att ersätta filen lägger därför till ett avbrott utan att lägga till rotation.

Det finns inte heller något begrepp om partens identitet utöver innehavet av filen. Den som har nyckeln är en part, och ingenting i tunneln registrerar vilken sida som är vilken, så återkallelse är allt eller inget.

Byt till TLS utan att göra om länken

TLS-läget lägger till en kontrollkanal och med den förmågan att förhandla nycklar för datakanalen. I en punkt-till-punkt-driftsättning tar den ena sidan serverrollen och den andra klientrollen, men topologin förblir en länk mellan två parter: varje sida känner till den andras slutpunkt, och ingen pool eller fleranvändartjänst dyker upp. Rollerna är en detalj i handskakningen, inte en ny arkitektur.

Ge varje maskin sin egen identitet. Varje sida behöver ett certifikat och en privat nyckel, det förtroendeankare som validerar den andra, och en partverifieringsregel som namnger vem som förväntas. Återanvänd inte den ena partens privata nyckel på den andra för att spara tid; det gör två identiteter till en och tar bort möjligheten att återkalla varje sida separat. Registreringen är platsen att göra detta rätt, eftersom att rätta det senare innebär att utfärda certifikat på nytt.

Håll nätverkskontraktet oförändrat medan skyddet ändras. Samma tunneladresser, rutter och tillåtna tjänster bör gälla före och efter, så att ett fel under migreringen är ett skyddsproblem och inte en förklädd routingöverraskning. Skriv ned adresserna och rutterna före ändringen; att jämföra dem efteråt är snabbare än att rekonstruera dem ur minnet.

Vissa driftsättningar skyddar också kontrollkanalen med sin egen statiska nyckel, som inte roterar med datakanalen. Den nyckeln bevakar handskakningen och inte nyttolasten, så en kompromiss av den blottar förhandlingen och inte trafiken. Förvara den åtskild från datakanalens material, och ge den ett utbytesdatum som en namngiven person äger. Att rotera den innebär att starta om båda parterna i ett samordnat fönster, och därför förtjänar den en kalenderpost och inte en minnesbild.

Vem förnyar vad, och när

I TLS-läge styrs förnyelsen av konfigurerade gränser: ett tidsintervall, ett byteantal eller ett paketantal. Den dokumenterade tidskontrollen är det de flesta driftsättningar förlitar sig på, och det lägre effektiva värdet över de två parterna kan starta utbytet, så att höja det bara på en sida håller inte tillbaka händelsen. Volymbaserade gränser finns eftersom en upptagen länk kan förbruka en nyckel långt innan klockan gör det. Ingen av gränserna är en hälsokontroll, och ingen av dem säger att en förnyelse lyckades.

Därför är det missvisande att diagnostisera en återkommande omskakning från en enda konfigurationsfil. Läs inställningarna på båda parterna och titta sedan på övergången i loggen i stället för att anta ett fel. En förnyelse som slutförs rent ser ut som en kort utblåsning av kontrollkanalstrafik, inte som en frånkoppling.

Håll objekten åtskilda i huvudet. Certifikatet bevisar långsiktig identitet och byts ut enligt ett schema du kontrollerar. Datakanalens nyckel uppdateras automatiskt, och ett separat autentiseringsutbyte, om driftsättningen kräver ett, följer kontopolicyn och kan behöva egna arrangemang för senare utbyten.

Att stänga av förnyelsen helt genom att sätta intervallet till noll är ingen lösning på en bullrig logg. Det förvandlar en sund livscykelhändelse till en permanent nyckel, vilket för dig tillbaka till egenskapen du försökte lämna.

Att acceptera ändringen

Bygg den nya konfigurationen från det stödda exemplet i den installerade utgåvan, inte från en gammal minimal bit vars algoritmer och filsökvägar ärvts från annat håll. Samordna bytet så att båda parterna ändras tillsammans, och håll en godkänd återställningsväg om en sida inte startar. Ta ned länken med avsikt i stället för att vänta på ett avbrott för att testa återrullningen. En återrullning du har övat är värd mer än en du har beskrivit.

Testa tre saker: den inledande identitetsverifieringen lyckas, det avsedda applikationsflödet fungerar, och en kontrollerad förnyelse sker utan att tappa trafik. Läs sedan övergången i loggen för vad den faktiskt bevisar: en ny nyckelidentifierare betyder att parterna slutförde ett utbyte, inte att tunneln återanslöts. Behandla det som bevis för ett steg, och kontrollera trafikräknarna innan du förklarar migreringen klar.

Det ett löfte om noll avbrott skulle dölja är felet du ännu inte har sett. En förnyelse som misslyckas, ett certifikat som löper ut eller ett sökvägsfel kan fortfarande störa länken, och ingen av dem utesluts av en ren testkörning. Egenskapen det är värt att designa för är snävare och mer användbar: rutinmässigt nyckelutbyte slutar vara ett manuellt filbyte.