0x или 0s? Како читати PSK формат у ipsec.secrets
Иста заједничка тајна може се записати као литерал у наводницима, као хексадецимални код после 0x или као Base64 после 0s. Погрешан префикс обара аутентификацију, не преговоре.
Један клијент се аутентификује заједничким кључем, а други га одбија, иако знакови које сте залепили изгледају исто са обе стране. Вероватно су то исти знакови; разлика је у томе које правило декодовања датотека примењује на њих. Низ у наводницима узима се дословно, токен који почиње са 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 подешавање учитава акредитиве својом сопственом наредбом. Поновно покретање одбацује сваку успостављену асоцијацију и уништава поређење које сте покушавали да направите.
Ниједна од ових провера не захтева откривање тајне. Дужина, селектор идентитета и позиција реда објашњавају већину таквих отказа пре него што некоме затреба хексадецимални испис.
Измените датотеку без скривања резултата
Ограничите датотеку на налог демона и држите живе тајне изван тикета, чета и снимака екрана, јер је залепљен кључ цурење, а не дијагностика. Он такође надживљава инцидент који га је створио.
Тестирајте са клијента чију конфигурацију контролишете, потврдите да аутентификација успева, а затим потврдите да тунел преноси саобраћај. Поновно учитавање које поправља руковање док рутирање остаје покварено други је проблем и постаје видљиво чим тајна престане да се креће.