0x или 0s? Читање на PSK форматот во ipsec.secrets

Еден клиент се автентикува со споделениот клуч, а друг го одбива, иако знаците што ги залепивте изгледаат исти од двете страни. Веројатно се истите знаци; разликата е кое правило за декодирање го применува датотеката врз нив. Низата во наводници се зема буквално, токен што почнува со 0x се чита како хексадецимален, а токен што почнува со 0s се чита како Base64. Само еден од тие три начина на пишување значи она што го мислевте, затоа поправката обично е претворање, а не подобра лозинка.

Симптомот укажува на кодирање, не на шифри

Кога двата краја држат различни бајти, преговорите сè уште успеваат, а доказот потфрла потоа. Тогаш дневникот пријавува неуспех на интегритет или HMAC наместо несовпаѓање на алгоритам, зашто предлогот е избран, а чекорот за автентикација не се совпадна. Таа линија никогаш не ја споменува формата на тајната.

Фазата е трагата. Неуспех што доаѓа по избран предлог значи дека двете страни се согласиле за сè освен за клучниот материјал, додека „нема избран предлог“ припаѓа на политиката или на шифрените множества. Проверката на интегритет што потфрла додека лозинката изгледа точна е видливото лице на несовпаѓање во кодирањето.

Една тајна, три начини на кои датотеката може да ја прочита

За вредноста од четири бајти key1 хексадецималното и Base64 се две прекодирања на истите бајти, и само водечките знаци му кажуваат на парсерот кое од двете го држи. swanctl-акредитивите ја следат истата конвенција, затоа вредноста преместена меѓу двата интерфејса го задржува значењето само ако нејзиниот префикс патува со неа.

10.20.0.5 %any : PSK "key1"
10.20.0.5 %any : PSK 0x6b657931
10.20.0.5 %any : PSK 0sa2V5MQ==

Два детали во тој блок одземаат најмногу време. Хексадецималните цифри ги прифаќаат двата регистри, затоа 0x6b657931 и 0x6B657931 се истата вредност, но непарен број знаци се чита тивко погрешно наместо да се одбие, што го поместува секој бајт по сечењето. Base64-поставувањето припаѓа на вредноста, затоа низата залепена без нејзините завршни = знаци се декодира во други бајти наместо гласно да потфрли.

Профилот што ја декодирал вредноста еднаш веќе ја претворил, затоа повторното декодирање дава други бајти и неуспех во автентикацијата што се чита како погрешна лозинка. Наводниците се безбедна насока за сè двосмислено, зашто содржината е буквална и кога почнува со ознака за кодирање.

Од каде доаѓа Base64-текстот

Извозот на профили и порталите на добавувачите често го предаваат клучот веќе кодиран, обично во поле со податоци што никогаш не било наменето за рачно пишување. Или отпакувајте ја таа вредност и чувајте го декодираниот текст во наводници, или оставете ја кодирана со ознаката напред. Правењето половина од секое е она што го расипува. Двата пата работат само ако целата вредност го преживее копирањето.

Двете насоки се по една команда, и вреди да се задржат во тикетот како точната операција што ја создала зачуваната вредност. Извршете ги по овој редослед:

printf '%s' 'a2V5MQ==' | base64 -d
printf '%s' 'key1' | base64

Лепењето кодиран текст како да е обичен е скапата грешка. Датотеката ги хешира знаците точно како што се напишани, изведениот клуч излегува приближно една третина подолг од оној што го пресметал партнерот, и секој обид потфрла на ист начин без предупредување, зашто парсерот го следел правилото што му било дадено.

Потврдете кои бајти всушност ги користи секој партнер

Прво прочитајте го погледот на демонот врз врската, а потоа резултатот од автентикацијата, наместо да погодувате причина од низата на грешката. Споредувањето на зачуваната должина е брза проверка на разумноста, зашто кодираниот текст е подолг од бајтите што ги претставува. Потоа потврдете кој ред на идентитет се совпаднал, зашто точна тајна сместена под погрешен партнер потфрла исто како погрешна. Редоследот на редовите го решава тоа: првото совпаѓање победува, затоа широк %any ред близу врвот тивко го заменува конкретниот ред што штотуку го уредовте.

Вчитајте повторно наместо да рестартирате кога датотеката е точна. ipsec rereadsecrets ја освежува копијата на IKE-демонот, а swanctl-поставувањето ги вчитува акредитивите преку своја сопствена команда. Рестартирањето ја отфрла секоја воспоставена асоцијација и ја уништува споредбата што се обидовте да ја направите.

Ниту една од овие проверки не бара откривање на тајната. Должина, избирач на идентитет и позиција на ред објаснуваат повеќето вакви неуспеси пред некому да му треба хексадецимален испис.

Сменете ја датотеката без да го скриете резултатот

Ограничете ја датотеката на сметката на демонот и држете ги живите тајни надвор од тикети, чет и екрански слики, зашто залепен клуч е истекување, а не дијагностика. Тој ја надживува и случката што го создала.

Тестирајте од клиент чија конфигурација ја контролирате, потврдете дека автентикацијата успева, а потоа потврдете дека тунелот пренесува сообраќај. Вчитување што ја поправа ракувањето додека рутирањето останува скршено е друг проблем и станува видливо штом тајната престане да се движи.