0x eller 0s? Så läser du PSK-formatet i ipsec.secrets

En klient autentiserar med den delade nyckeln och en annan avvisar den, trots att tecknen du klistrade in ser likadana ut på båda sidor. De är förmodligen samma tecken; skillnaden är vilken avkodningsregel filen tillämpar på dem. En sträng inom citattecken tas bokstavligt, en token som börjar med 0x läses som hexadecimal, och en token som börjar med 0s läses som Base64. Bara ett av de tre skrivsätten betyder det du avsåg, så rättelsen är oftast en konvertering och inte ett bättre lösenord.

Symtomet pekar på kodning, inte på chiffer

När de två ändarna har olika byte, lyckas förhandlingen ändå och beviset misslyckas efteråt. Loggen rapporterar då ett integritets- eller HMAC-fel i stället för en algoritmavvikelse, eftersom ett förslag valdes och autentiseringssteget inte stämde. Den raden nämner aldrig hemlighetens form.

Steget är ledtråden. Ett fel som kommer efter ett valt förslag betyder att båda sidor var överens om allt utom nyckelmaterialet, medan «inget förslag valt» hör till policy eller chiffersviter. En integritetskontroll som misslyckas medan lösenordet ser rätt ut är den synliga sidan av en kodningsavvikelse.

En hemlighet, tre sätt som filen kan läsa den på

För värdet på fyra byte key1 är hexadecimal och Base64 två omkodningar av samma byte, och bara de inledande tecknen talar om för tolken vilken av dem den håller. swanctl-uppgifter följer samma konvention, så ett värde som flyttas mellan de två gränssnitten behåller sin betydelse bara om dess prefix följer med.

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

Två detaljer i det blocket tar mest tid. Hexadecimala siffror accepterar båda skrivsätten, så 0x6b657931 och 0x6B657931 är samma värde, men ett udda antal tecken läses tyst fel i stället för att avvisas, vilket förskjuter varje byte efter snittet. Base64-utfyllnad hör till värdet, så en sträng som klistras in utan sina avslutande = tecken avkodas till andra byte i stället för att misslyckas högljutt.

En profil som en gång har avkodat värdet har redan konverterat det, så ny avkodning ger andra byte och ett autentiseringsfel som läses som ett felaktigt lösenord. Citattecken är den säkra riktningen för allt tvetydigt, eftersom innehållet är bokstavligt även när det börjar med en kodningsmarkör.

Var Base64-texten kommer ifrån

Profilutdrag och leverantörsportaler lämnar ofta nyckeln redan kodad, vanligtvis i ett datafält som aldrig var avsett att skrivas för hand. Antingen packa upp det värdet och spara den avkodade texten inom citattecken, eller låt den vara kodad med markören framför. Att göra hälften av varje är det som förstör. Båda vägarna fungerar bara om hela värdet överlever kopieringen.

Båda riktningarna är ett kommando var, och de är värda att behålla i ärendet som den exakta operation som skapade det lagrade värdet. Kör dem i den här ordningen:

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

Att klistra in kodad text som om den vore vanlig är det dyra misstaget. Filen hashar tecknen exakt som de skrevs, den härledda nyckeln blir ungefär en tredjedel längre än den som motparten beräknade, och varje försök misslyckas på samma sätt utan varning, eftersom tolken följde regeln den fick.

Bekräfta vilka byte varje motpart faktiskt använder

Läs först daemonens syn på anslutningen och sedan autentiseringsresultatet, i stället för att gissa en orsak ur felsträngen. Att jämföra den lagrade längden är en snabb rimlighetskontroll, eftersom kodad text är längre än de byte den representerar. Bekräfta sedan vilken identitetsrad som matchade, eftersom en korrekt hemlighet placerad under fel motpart misslyckas precis som en felaktig. Radordningen avgör det: den första träffen vinner, så en bred %any rad nära toppen ersätter tyst den specifika rad du just redigerade.

Läs om i stället för att starta om när filen är korrekt. ipsec rereadsecrets uppdaterar kopian av IKE-daemonen, och en swanctl-konfiguration läser in uppgifterna med sitt eget kommando. En omstart släpper varje upprättad association och förstör den jämförelse du försökte göra.

Ingen av dessa kontroller kräver att hemligheten avslöjas. En längd, en identitetsväljare och en radposition förklarar de flesta sådana fel innan någon behöver en hexdump.

Ändra filen utan att dölja resultatet

Begränsa filen till daemonens konto och håll levande hemligheter utanför ärenden, chatt och skärmbilder, eftersom en inklistrad nyckel är en läcka och inte en diagnos. Den överlever också den incident som skapade den.

Testa från en klient vars konfiguration du kontrollerar, bekräfta att autentiseringen lyckas och bekräfta sedan att tunneln bär trafik. En omladdning som reparerar handskakningen medan routingen förblir trasig är ett annat problem, och det blir synligt så snart hemligheten slutar röra sig.