Twee OpenVPN-profielen vergelijken zonder sleutels te lekken

Twee profielen, het ene verbindt en het andere niet, en de snelle manier om te zien waarom is een diff. Het probleem is dat dezelfde diff de inline privésleutel, de statische sleutel en elk credential-blok dat het bestand bevat afdrukt, en mensen plakken de uitvoer in een chat voordat ze het merken. Bepalen wat je vergelijkt komt vóór het uitvoeren van de opdracht. Vergelijk structuur en rollen op beschermde kopieën, en bouw een apart geredigeerd bestand als iemand anders het moet zien.

Wat een .ovpn-bestand werkelijk bevat

Een .ovpn-bestand is een configuratie met optionele inline blokken. Het kan een CA-certificaat, een cliëntcertificaat, een privésleutel, een tls-auth of tls-crypt-sleutel bevatten, en richtlijnen die naar externe bestanden wijzen of om inloggegevens vragen. Twee bestanden kunnen er bijna identiek uitzien en alleen binnen een blok verschillen, of in één richtlijn die het transport volledig verandert. Het aantal regels zegt je niets over wat daarvan is gebeurd.

Een verschil binnen een sleutelblok is geen openbaar bewijs van iets. Een opnieuw uitgegeven certificaat en een met een nieuwe sleutel kunnen dezelfde vorm van wijziging geven, dus het blokverschil zegt dat het materiaal anders is, niet welke beslissing het heeft veroorzaakt. Behandel het als een signaal om velden te vergelijken, niet als een bevinding.

Vergelijk op rol, niet op regel

Volg de eigen volgorde van de verbinding: eerst eindpunt en transport, dan vertrouwen en verwachte identiteit, dan gebruikersauthenticatie, dan routes, DNS en script-hooks. Die volgorde komt overeen met wat de cliënt doet, dus het eerste verschil dat je tegenkomt is het eerste dat de verbinding had kunnen breken. Alfabetisch vergelijken verspreidt verwante instellingen juist over de hele uitvoer.

Een veldbewuste doorgang bekijkt deze items, in die volgorde. Alles wat de cliënt interactief vraagt hoort bij de authenticatieregel, niet bij de vertrouwensregels.

• remote, proto en poort, inclusief elk verbindingsblok.
• ca en cert: uitgever, onderwerp en vervaldatum.
• Of er überhaupt een privésleutel is, nooit wat die bevat.
• tls-auth of tls-crypt-aanwezigheid en sleutelrichting.
• Authenticatierichtlijnen, inclusief elke verwijzing naar een credential-bestand.
• Routes, DNS-opties en script-hooks die draaien bij verbinden.

Als een bestand meerdere verbindingsblokken bevat, houd elke optie bij het bijbehorende eindpunt. Alleen de eerste remote-regel vergelijken kan het alternatief missen dat de cliënt op dit netwerk echt kiest.

Waarom een gewone diff het verkeerde gereedschap is

Een gewone diff is gebouwd voor tekst, niet voor geheimen. Hij print met plezier een privésleutel in de scrollback, en hij vertelt je niet dat de richtlijn waar je naar staart irrelevant is voor de storing. Veld-extracties zijn zowel veiliger als leesbaarder, omdat certificaatmateriaal als metadata kan worden vergeleken in plaats van als bytes.

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 eerste twee opdrachten printen identiteit en geldigheid zonder de sleutel aan te raken, dus hun uitvoer is veilig om te plakken. De grep print richtlijnnamen en waarden maar nooit de blokinhoud, wat hem de juiste eerste doorgang maakt als je een transport- of routingverschil vermoedt. Als een blok zelf vergeleken moet worden, vergelijk dan zijn hash in plaats van de inhoud.

Bouw een geredigeerde kopie voor het ticket

Verwijder echte geheimen en onnodige identificatoren terwijl je veldnamen en genoeg structuur houdt om het verschil uit te leggen. Een markering van dezelfde vorm verraadt nog steeds waar het materiaal staat en hoe lang het was, dus beslis of zelfs dat acceptabel is. Controleer de uiteindelijke bijlage zelf in plaats van de opdracht te vertrouwen die je je herinnert te hebben uitgevoerd. Bewerk het werkende origineel niet alleen om een voorbeeld te maken, want een geredigeerd profiel is niet noodzakelijk uitvoerbaar en mag nooit opnieuw worden geïmporteerd.

Houd de originelen herkenbaar aan bestandsnaam en hash in plaats van ze naar drie mappen met vergelijkbare namen te kopiëren. Een hash-string is genoeg om te bewijzen welk bestand is beoordeeld en kost niets als hij lekt. Snoei de kopieën nadat de wijziging is gesloten, zodat de volgende persoon één gezaghebbend bestand erft.

Houd de vergelijking aan een storing gebonden

Een vergelijking verdient zijn kosten als hij een vraag over één import of één verbindingsstoring beantwoordt. Benoem eerst de stap die faalt en vergelijk daarna alleen de velden waarvan die stap afhangt; alle inloggegevens van de cliënt in één map verzamelen maakt het volgende lek waarschijnlijker en de volgende diagnose langzamer. Hoe smaller de vraag, hoe korter de lijst velden die hem kunnen beantwoorden.

Als een nieuw bestand van de operator kwam, bevestig dan het distributiepad voordat je vertrouwensmateriaal vervangt. Inspecteer na de wijziging de geïmporteerde kopie die de cliënt werkelijk koos en het onderhandelde resultaat, want een richtlijn kan door een andere cliëntversie worden genegeerd of anders gelezen. Het bestand op schijf is geen bewijs van de verbinding die liep. De semantiek van de richtlijnen staat in de OpenVPN 2.6-handleiding.