0x ili 0s? Kako se čita format PSK u ipsec.secrets
Isti zajednički tajni ključ može se zapisati kao literal u navodnicima, kao heksadecimalni kod nakon 0x ili kao Base64 nakon 0s. Pogrešan prefiks ruši autentifikaciju, a ne pregovaranje.
Jedan se klijent autentificira zajedničkim ključem, a drugi ga odbija, iako znakovi koje ste zalijepili izgledaju jednako na obje strane. Vjerojatno su to isti znakovi; razlika je u tome koje pravilo dekodiranja datoteka na njih primjenjuje. Niz u navodnicima uzima se doslovno, a token koji počinje s 0x čita se kao heksadecimalni, dok se token koji počinje s 0s čita kao Base64. Samo jedan od tih triju zapisa znači ono što ste namjeravali, pa je popravak obično pretvorba, a ne bolja zaporka.
Simptom upućuje na kodiranje, a ne na šifre
Kada dva kraja drže različite bajtove, pregovaranje ipak uspijeva, a dokaz zatim pada. Zapis tada prijavljuje kvar integriteta ili HMAC-a, a ne neslaganje algoritma, jer je prijedlog odabran, a korak autentifikacije nije odgovarao. Taj redak nikada ne spominje oblik tajnog ključa.
Faza je trag. Kvar koji stigne nakon odabranog prijedloga znači da su se obje strane dogovorile o svemu osim o ključnom materijalu, dok „nije odabran nijedan prijedlog“ pripada politici ili skupovima šifri. Provjera integriteta koja pada dok zaporka izgleda ispravno vidljivo je lice neslaganja u kodiranju.
Jedan tajni ključ, tri načina na koja ga datoteka može pročitati
Za vrijednost od četiri bajta key1 heksadecimalni zapis i Base64 dva su ponovna kodiranja istih bajtova, a samo vodeći znakovi kažu parseru koje od njih drži. swanctl vjerodajnice slijede istu konvenciju, pa vrijednost premještena između dvaju sučelja zadržava značenje samo ako njezin prefiks putuje s njom.
10.20.0.5 %any : PSK "key1"
10.20.0.5 %any : PSK 0x6b657931
10.20.0.5 %any : PSK 0sa2V5MQ==
Dva detalja u tom bloku oduzimaju najviše vremena. Heksadecimalne znamenke prihvaćaju oba slova, pa su 0x6b657931 i 0x6B657931 ista vrijednost, ali neparan broj znakova tiho se pogrešno čita umjesto da bude odbijen, što pomiče svaki bajt nakon mjesta reza. Base64 podstava pripada vrijednosti, pa se niz zalijepljen bez svojih završnih znakova = dekodira u druge bajtove umjesto da glasno padne.
Profil koji je vrijednost jednom dekodirao već ju je pretvorio, pa ponovno dekodiranje daje druge bajtove i kvar autentifikacije koji se čita kao pogrešna zaporka. Navodnici su siguran smjer za sve dvosmisleno jer je sadržaj doslovan čak i kada počinje oznakom kodiranja.
Odakle dolazi tekst Base64
Izvoz profila i dobavljački portali često predaju ključ već kodiran, obično u podatkovnom polju koje nikada nije bilo namijenjeno ručnom upisu. Ili razmotajte tu vrijednost i pohranite dekodirani tekst u navodnicima, ili je ostavite kodiranu s oznakom sprijeda. Raditi pola jednoga i pola drugoga jest ono što kvari. Svaki put djeluje samo ako cijela vrijednost preživi kopiranje.
Oba su smjera po jedna naredba i vrijedi ih zadržati u ticketu kao točnu radnju koja je proizvela pohranjenu vrijednost. Pokrenite ih ovim redom:
printf '%s' 'a2V5MQ==' | base64 -d
printf '%s' 'key1' | base64
Lijepljenje kodiranog teksta kao da je običan skupa je pogreška. Datoteka hashira znakove točno kako su napisani, izvedeni ključ izlazi otprilike trećinu dulji od onoga koji je kolega izračunao, a svaki pokušaj pada na isti način bez upozorenja jer je parser slijedio pravilo koje mu je dano.
Potvrdite koje bajtove svaki kolega zapravo koristi
Prvo pročitajte kako daemon vidi vezu, a zatim rezultat autentifikacije, umjesto da uzrok nagađate iz niza pogreške. Usporedba pohranjene duljine brza je provjera razumnosti jer je kodirani tekst dulji od bajtova koje predstavlja. Zatim potvrdite koji se redak identiteta podudario, jer ispravan tajni ključ pod pogrešnim kolegom pada jednako kao pogrešan. Redoslijed redaka to odlučuje: prvo podudaranje pobjeđuje, pa širok redak %any pri vrhu tiho zamjenjuje određeni redak koji ste upravo uredili.
Ponovno učitajte umjesto ponovnog pokretanja kad datoteka bude ispravna. ipsec rereadsecrets osvježava kopiju IKE daemona, a swanctl postava učitava vjerodajnice vlastitom naredbom. Ponovno pokretanje odbacuje svaku uspostavljenu asocijaciju i uništava usporedbu koju ste pokušavali napraviti.
Nijedna od tih provjera ne zahtijeva otkrivanje tajnog ključa. Duljina, selektor identiteta i položaj retka objašnjavaju većinu takvih kvarova prije nego ikome zatreba heksadecimalni ispis.
Promijenite datoteku bez skrivanja rezultata
Ograničite datoteku na račun daemona i držite žive tajne ključeve izvan ticketa, chata i snimki zaslona jer je zalijepljen ključ curenje, a ne dijagnostika. On nadživljava i incident koji ga je proizveo.
Testirajte s klijenta čiju konfiguraciju kontrolirate, potvrdite da autentifikacija uspijeva, a zatim potvrdite da tunel prenosi promet. Ponovno učitavanje koje popravi rukovanje dok usmjeravanje ostane pokvareno drugi je problem i postaje vidljivo čim se tajni ključ prestane mijenjati.