Сравнете два профила на OpenVPN, без да издавате ключове

Текстов diff може да разкрие вградените ключове също толкова лесно, колкото показва променена директива. Сравнявайте по роля върху защитени копия, после изгответе отделен редактиран диагностичен файл.

Два профила, единият се свързва, другият не, и бързият начин да видите защо е diff. Проблемът е, че същият diff отпечатва вградения личен ключ, статичния ключ и всеки блок с идентификационни данни, който файлът носи, а хората поставят изхода в чат, преди да забележат. Решението какво точно сравнявате идва преди пускането на командата. Сравнявайте структура и роли върху защитени копия и изградете отделен редактиран файл, когато някой друг трябва да го види.

Какво всъщност носи файлът .ovpn

Файлът .ovpn е конфигурация с незадължителни вградени блокове. Той може да съдържа CA сертификат, клиентски сертификат, личен ключ, ключ tls-auth или tls-crypt, както и директиви, които сочат към външни файлове или искат идентификационни данни. Два файла могат да изглеждат почти еднакво и да се различават само вътре в блок, или в една директива, която променя транспорта изцяло. Броят редове не ви казва нищо за това кое от тези се е случило.

Разлика вътре в блок с ключ не е публично доказателство за нищо. Преиздаден сертификат и такъв с нов ключ могат да дадат същата форма на промяна, така че несъответствието на блока ви казва, че материалът е различен, не кое решение го е създало. Отнасяйте се към него като сигнал да сравните полета, не като констатация.

Сравнявайте по роля, не по ред

Вървете по собствения ред на връзката: първо крайна точка и транспорт, после доверие и очаквана идентичност, после удостоверяване на потребителя, после маршрути, DNS и скриптови куки. Тази последователност съвпада с това, което клиентът прави, така че първата разлика, която срещнете, е първото нещо, което е могло да счупи връзката. Сравняването по азбучен ред вместо това разпръсква свързаните настройки из целия изход.

Проход, който отчита полетата, разглежда тези елементи в този ред. Всичко, което клиентът пита интерактивно, принадлежи към реда за удостоверяване, а не към редовете за доверие.

  • remote, proto и порт, включително всеки блок за връзка.
  • ca и cert: издател, субект и дата на изтичане.
  • Дали изобщо присъства личен ключ, а не какво съдържа.
  • tls-auth или tls-crypt наличие и посока на ключа.
  • Директиви за удостоверяване, включително всяка препратка към файл с идентификационни данни.
  • Маршрути, DNS опции и скриптови куки, които се изпълняват при свързване.

Когато файлът съдържа няколко блока за връзка, дръжте всяка опция с нейната крайна точка. Сравняването само на първия ред remote може да пропусне алтернативата, която клиентът действително избира в тази мрежа.

Защо обикновеният diff е грешен инструмент

Обикновеният diff е създаден за текст, не за тайни. Той с удоволствие ще отпечата личен ключ в историята на екрана и няма да ви каже, че директивата, в която се взирате, е без значение за отказа. Извличането на полета е едновременно по-безопасно и по-четимо, защото материалът на сертификата може да се сравнява като метаданни, а не като байтове.

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

Първите две команди отпечатват идентичност и валидност, без да докосват ключа, така че изходът им е безопасен за поставяне. grep отпечатва имената на директивите и стойностите им, но никога телата на блоковете, което го прави правилния първи проход, когато подозирате разлика в транспорта или маршрутизацията. Ако самият блок трябва да се сравни, сравнете хеша му, а не съдържанието.

Изградете редактирано копие за заявката

Премахнете истинските тайни и ненужните идентификатори, като запазите имената на полетата и достатъчно структура, за да обясните разликата. Маркер със същата форма пак разкрива къде стои материалът и колко дълъг е бил, затова решете дали дори това е приемливо. Проверете самия краен прикачен файл, вместо да се доверявате на командата, която помните, че сте пуснали. Не редактирайте работещия оригинал само за да създадете пример, защото редактираният профил не е непременно изпълним и никога не бива да се импортира отново.

Пазете оригиналите разпознаваеми по име на файл и хеш, вместо да ги копирате в три папки с подобни имена. Хеш низ е достатъчен да докаже кой файл е прегледан и не струва нищо, ако изтече. Подрежете копията, след като промяната приключи, за да наследи следващият човек един авторитетен файл.

Дръжте сравнението вързано към отказ

Сравнението заслужава цената си, когато отговаря на въпрос за един импорт или един отказ на връзка. Първо назовете стъпката, която се проваля, после сравнете само полетата, от които тя зависи; събирането на всички идентификационни данни на клиента в една папка прави следващото изтичане по-вероятно, а следващата диагностика по-бавна. Колкото по-тесен е въпросът, толкова по-кратък е списъкът с полета, които могат да отговорят.

Ако нов файл е дошъл от оператора, потвърдете пътя му на разпространение, преди да замените материала за доверие. След промяната прегледайте импортираното копие, което клиентът действително е избрал, и договорения резултат, защото една директива може да бъде пренебрегната или прочетена различно от друга версия на клиента. Файлът на диска не е доказателство за връзката, която е протекла. Семантиката на директивите е в ръководството на OpenVPN 2.6.

Подобни статии