vpnc-fel med svag kryptering: gatewaypolicy eller skrivbordsreparation?

Två reparationer verkar lika snabba när en gammal vpnc-anslutning vägrar komma upp: skicka den gamla svag-kryptering-flaggan, eller lägga in ett omslagsskript som lägger till den åt dig. De är inte likvärdiga, eftersom den ena ändrar policyn för en enda profil och den andra beteendet för varje program som anropar den vägen. Den första frågan är om gatewayen fortfarande erbjuder ett svagt förslag, och den andra är vem som får acceptera det. Allt annat följer av de två svaren.

Två reparationer med mycket olika räckvidd

En ändring på profilnivå berör en anslutning, en ägare och ett utgångsdatum. Att byta ut den installerade binärfilen berör varje frontend på maskinen, inklusive skrivbordsappletten som en kollega använder för en helt annan gatewayprofil. Omslaget döljer också ändringen för alla som felsöker värden ett halvår senare.

Paketverifieringen är det första offret: en fil på /usr/sbin/vpnc som inte längre matchar sitt paket förvandlar en rutinmässig säkerhetsuppdatering till en utredning. Uppgraderingar skriver då antingen tyst över omslaget eller vägrar att tillämpas, beroende på hur pakethanteraren behandlar ändrade filer. Ingen av utgångarna syns i anslutningsloggen, och därför förblir omslagsmetoden lockande ända till den första incidenten. En enda rad i en profil är mycket lättare att hitta och ta bort än en binärfil som ingen minns att de bytt ut.

Vad den föråldrade strömbrytaren faktiskt gör

vpnc-handboken markerar enkel-DES-alternativet som föråldrat till förmån för en inställning för svag kryptering, och dokumenterar ett separat alternativ som tillåter ingen kryptering alls av datatrafik. Det är olika medgivanden med olika konsekvenser. Ingen av dem får en modern gateway att förhandla om något den inte längre erbjuder.

Läs felsteget innan du väljer en reparation. Ett avvisat förslag och ett avvisat lösenord ger liknande frontend-meddelanden men helt olika bevis.

Var ett begränsat undantag hör hemma

Om en organisation medvetet accepterar en gammal peer under en begränsad period, hör undantaget hemma i den peerens profil, med en ägare, ett granskningsdatum och en migreringsväg till en protokoll som stöds. Att hålla det utanför den globala vägen är hela poängen med att kalla det begränsat.

Låt gatewayägaren bekräfta vilka algoritmer peeren fortfarande föreslår och vad som ersätter den. En klientflagga kan inte reparera ett förslag som servern inte längre skickar, och en servermigrering som ingen har planerat kommer att överleva temporärlösningen. Sätt granskningsdatumet i samma ärende som undantaget, så att medgivandet löper ut i stället för att bli permanent.

Kontrollera förhandlingen, inte bara den gröna ikonen

Samla bevis som identifierar steget i stället för stämningen i dialogen. Kommandona nedan är endast för läsning, och de två första visar vilken konfiguration och version som faktiskt är i spel.

vpnc --version
vpnc --print-config /etc/vpnc/legacy.conf
dpkg -V vpnc
grep -n -E 'weak|1des|no-encryption' /etc/vpnc/legacy.conf

Det tredje kommandot rapporterar filer som inte längre matchar paketet, och så avslöjar sig ett bortglömt omslag. Det fjärde visar de medgivanden som profilen bär, så att ett undantag inte tyst kan spridas till en andra profil via en kopierad fil. Kör båda före och efter en ändring, och förvara utdata tillsammans med anslutningsprofilen i stället för i ett chattfönster.

Håll felsökningsutdata utanför ärenden tills någon har läst det, eftersom handboken varnar för att den högsta felsökningsnivån dumpar autentiseringsdata inklusive lösenord. Acceptanskriteriet är en auktoriserad, stödd överenskommelse mellan klient och gateway, inte en menyrad som äntligen blir grön. Om peeren bara erbjuder en trasig algoritm är det ärliga resultatet ett undantag med slutdatum eller ett ersättningsprotokoll, och det beslutet tillhör den som äger gatewayen. Att registrera beslutet är skillnaden mellan ett hanterat undantag och en oavsiktlig policyändring.