vpnc-grupphemlighet eller din inloggning: vilket fält tar vad?

Första gången någon ger dig en vpnc-profil frågar inloggningsdialogen efter fyra saker och läses som om den vill ha ett enda lösenord. Det vill den inte: en i förväg delad grupphemlighet och en individuell XAuth-inloggning är separata värden med separata ägare, och att sätta kontolösenordet i gruppfältet ger ett fel som ser ut som ett dåligt lösenord snarare än ett fel fält. Att få kopplingen rätt är hela uppgiften här. Protokollet under är någon annans migreringsprojekt, och därför är inget av detta ett argument för att bygga nya IKEv1-tunnlar.

Två hemligheter, två ägare, en dialog

En grupphemlighet tillhör gatewayprofilen. Alla som ansluter genom den profilen använder samma värde, och just därför kan den inte identifiera en person och kan inte dras tillbaka från en bärbar dator utan att ändras för alla andra användare av profilen. XAuth-användarnamnet och lösenordet tillhör i stället människan, och gatewayen utvärderar dem i en andra fas när IPsec-associationen redan är uppe.

Det är den här tvåfasformen folk missar. Tunnelupprättande och användarautentisering är olika utbyten med olika indata, så en klient som aldrig når inloggningsfrågan har inte misslyckats med inloggningen alls. Läs dialogen som två kolumner i stället för en: profilvida värden till vänster, personliga värden till höger. När en anslutning misslyckas är kolumnen du fyllde i sist inte automatiskt den skyldiga.

Koppla fälten efter roll, inte efter etikett

vpnc namnger sina direktiv i projektdokumentationen, och varje grafiskt gränssnitt byter namn på dem. Översätt rollen för varje värde, så spelar etiketterna ingen roll längre:

Ett gränssnitt som visar »Användarnamn« och »Lösenord« bredvid ett gruppfält är inte fel — det är samma tre värden under olika namn. Det som går sönder är att fylla i ett fält för att ett värde passar i det. En grupphemlighet inklistrad som användarlösenord autentiserar profilen och misslyckas sedan i användarfasen; ett kontolösenord inklistrat som grupphemlighet misslyckas tidigare, före någon fråga, och skickar folk att leta efter problemet i brandväggar medan det bor i ett textfält.

Vad en gruppidentifierare inte är

Ordet grupp inbjuder till en felaktig läsning. En gruppidentifierare här är en väljare som talar om för gatewayen vilken profilkonfiguration som ska användas; den säger ingenting om katalogmedlemskap, och ett matchande namn på båda sidor är en slump tills operatören bekräftar det. Autorisering sker efter att XAuth lyckats, avgjord av vad gatewayen är konfigurerad att rådfråga, och inget av det syns i klientdialogen.

Samma försiktighet gäller grupphemligheten. Att känna till den är ingen identitet, och att cirkulera en enda hemlighet i ett team är ett driftbeslut med konsekvenser som klienten inte kan visa dig.

Rensa den tvetydiga instruktionen innan du ansluter

Överlämningsanteckningar från arvet innehåller ofta en rad som »använd den dedikerade offentliga IP-adressen«. Den formuleringen kan betyda den adress som en tillåtelselista på andra sidan förväntar sig att din trafik kommer från, det är en utgångsegenskap hos operatörens nätverk och har ingenting att göra med den slutpunkt du skriver i gatewayfältet. Fråga vilken av de två som avses innan värdet går någonstans. Ifyllt bakvänt skickar det varje paket till en adress som aldrig svarar, och tidsgränsen som följer läses som en blockerad port.

Be om fyra saker genom organisationens verifierade kanal: vilken klient och protokoll som stöds, vilken slutpunkt som ska användas, vilken identitet gatewayen kommer att presentera och hur inloggningsuppgifter lämnas över. Håll riktiga hemligheter utanför skärmbilder, ärenden och delade felsökningsanteckningar. Inaktivera inte certifikatkontroller och klistra inte in en gammal chifferlista för att få en annorlunda konfigurerad tjänst att verka kompatibel, för en anslutning som bara fungerar genom att försvaga verifieringen är inte den anslutning du blev ombedd att bygga.

Håll den gamla profilen ärlig

IKEv1 är föråldrat, och RFC 9395 är dokumentet att citera när migreringsfrågan dyker upp. En lyckad fältkoppling är inte bevis för att protokollet hör hemma i en ny design; det den köper är en fungerande anslutning medan utbytet planeras, plus en skriftlig omfattning och en ägare för den migreringen.

Verifiera sedan mot kravet i stället för mot dialogen. Efter anslutning, bekräfta att tunnelgränssnittet har den förväntade adressen och att en intern destination dirigeras genom det; om det ursprungliga kravet nämnde en utgångsadress för en tillåtelselista, bekräfta den adressen också, för det är ett annat faktum än att tunneln är uppe. En profil som autentiserar korrekt och inte dirigerar något har ändå misslyckats med uppgiften den skapades för.