Споредете два 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 прирачникот.

Поврзани статии