Jämför två OpenVPN-profiler utan att läcka nycklar

Två profiler, en ansluter och en gör det inte, och det snabba sättet att se varför är en diff. Problemet är att samma diff skriver ut den inbäddade privata nyckeln, den statiska nyckeln och varje autentiseringsblock som filen bär, och folk klistrar in utdata i en chatt innan de märker det. Att bestämma vad du jämför kommer före kommandot. Jämför struktur och roller på skyddade kopior, och bygg en separat redigerad fil när någon annan behöver se den.

Vad en .ovpn-fil faktiskt innehåller

En .ovpn-fil är en konfiguration med valfria inbäddade block. Den kan hålla ett CA-certifikat, ett klientcertifikat, en privat nyckel, en tls-auth eller tls-crypt-nyckel och direktiv som pekar på externa filer eller frågar efter autentiseringsuppgifter. Två filer kan se nästan identiska ut och bara skilja sig inne i ett block, eller i ett enda direktiv som ändrar transporten helt. Antalet rader säger ingenting om vilket av detta som hände.

En skillnad inne i ett nyckelblock är inte offentligt bevis på något. Ett återutfärdat certifikat och ett med ny nyckel kan ge samma form av ändring, så blockavvikelsen säger att materialet är annorlunda, inte vilket beslut som skapade det. Behandla det som en signal att jämföra fält, inte som en slutsats.

Jämför efter roll, inte efter rad

Följ anslutningens egen ordning: först slutpunkt och transport, sedan förtroende och förväntad identitet, sedan användarautentisering, sedan rutter, DNS och skripthakar. Den ordningen motsvarar vad klienten gör, så den första skillnaden du möter är det första som kunde ha brutit anslutningen. Alfabetisk jämförelse sprider i stället relaterade inställningar över hela utdata.

En fältmedveten genomgång tittar på dessa poster, i den ordningen. Allt klienten frågar om interaktivt hör till autentiseringsraden, inte till förtroenderaderna.

• remote, proto och port, inklusive varje anslutningsblock.
• ca och cert: utfärdare, ämne och utgångsdatum.
• Om det över huvud taget finns en privat nyckel, aldrig vad den innehåller.
• tls-auth eller tls-crypt-närvaro och nyckelriktning.
• Autentiseringsdirektiv, inklusive varje referens till en autentiseringsfil.
• Rutter, DNS-alternativ och skripthakar som körs vid anslutning.

När en fil innehåller flera anslutningsblock, håll varje alternativ vid sin slutpunkt. Att bara jämföra den första remote-raden kan missa det alternativ som klienten faktiskt väljer i det här nätet.

Varför en vanlig diff är fel verktyg

En vanlig diff är byggd för text, inte för hemligheter. Den skriver gärna ut en privat nyckel i rullningshistoriken, och den säger inte att direktivet du stirrar på är irrelevant för felet. Fältutdrag är både säkrare och mer läsbara, eftersom certifikatmaterial kan jämföras som metadata i stället för byte.

openssl x509 -in ca.crt -noout -subject -issuer -enddate
openssl x509 -in client.crt -noout -subject -issuer -enddate
grep -E '^(remote|proto|port|tls-auth|tls-crypt|route|dhcp-option)' profile.ovpn

De två första kommandona skriver ut identitet och giltighet utan att röra nyckeln, så deras utdata är säkra att klistra in. grep skriver ut direktivnamn och värden men aldrig blockens innehåll, vilket gör det till rätt första genomgång när du misstänker en transport- eller rutskillnad. Om ett block självt måste jämföras, jämför dess hash i stället för innehållet.

Bygg en redigerad kopia för ärendet

Ta bort riktiga hemligheter och onödiga identifierare medan du behåller fältnamn och tillräckligt med struktur för att förklara skillnaden. En markör av samma form avslöjar fortfarande var materialet sitter och hur långt det var, så avgör om ens det är acceptabelt. Kontrollera den slutliga bilagan själv i stället för att lita på kommandot du minns att du körde. Redigera inte det fungerande originalet bara för att skapa ett exempel, eftersom en redigerad profil inte nödvändigtvis är körbar och aldrig bör importeras igen.

Håll originalen identifierbara med filnamn och hash i stället för att kopiera dem till tre kataloger med liknande namn. En hash-sträng räcker för att bevisa vilken fil som granskades och kostar ingenting om den läcker. Beskär kopiorna när ändringen är stängd, så att nästa person ärver en enda auktoritativ fil.

Håll jämförelsen knuten till ett fel

En jämförelse är värd sitt pris när den svarar på en fråga om en import eller ett anslutningsfel. Namnge först steget som misslyckas och jämför sedan bara de fält som steget beror på; att samla alla klientens autentiseringsuppgifter i en katalog gör nästa läcka mer sannolik och nästa diagnos långsammare. Ju snävare frågan är, desto kortare är listan över fält som kan besvara den.

Om en ny fil kom från operatören, bekräfta dess distributionsväg innan du ersätter förtroendematerial. Efter ändringen, granska den importerade kopia som klienten faktiskt valde och det förhandlade resultatet, eftersom ett direktiv kan ignoreras eller läsas annorlunda av en annan klientversion. Filen på disken är inte bevis på anslutningen som körde. Direktivens semantik finns i OpenVPN 2.6-handboken.