Параўнайце два профілі 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.

Падобныя артыкулы