vpnc-feil med svak kryptering: gateway-policy eller skrivebordsreparasjon?

To reparasjoner virker like raske når en gammel vpnc-tilkobling nekter å komme opp: sende det gamle svak-kryptering-flagget, eller legge inn et innpakningsskript som legger det til for deg. De er ikke likeverdige, fordi den ene endrer policyen til én profil og den andre endrer oppførselen til hvert program som kaller den banen. Det første spørsmålet er om gatewayen fortsatt tilbyr et svakt forslag, og det andre er hvem som har lov til å godta det. Alt annet følger av de to svarene.

To reparasjoner med svært ulik rekkevidde

En endring på profilsnivå berører én tilkobling, én eier og én utløpsdato. Å erstatte den installerte binærfila berører hver frontend på maskinen, inkludert skrivebordsappletten en kollega bruker for en helt annen gatewayprofil. Innpakningen skjuler også endringen for alle som feilsøker verten et halvt år senere.

Pakkevurdering er det første offeret: en fil på /usr/sbin/vpnc som ikke lenger samsvarer med pakken sin, gjør en rutinemessig sikkerhetsoppdatering til en etterforskning. Oppgraderinger overskriver da enten innpakningen stille eller nekter å bli brukt, avhengig av hvordan pakkebehandleren håndterer endrede filer. Ingen av utfallene vises i tilkoblingsloggen, og derfor forblir innpakningsmetoden attraktiv helt til den første hendelsen. Én linje i en profil er langt lettere å finne og fjerne enn en binærfil som ingen husker å ha erstattet.

Hva den utdaterte bryteren faktisk gjør

vpnc-håndboken markerer enkelt-DES-alternativet som utdatert til fordel for en innstilling for svak kryptering, og dokumenterer et eget alternativ som tillater ingen kryptering av datatrafikk i det hele tatt. Det er forskjellige innrømmelser med forskjellige konsekvenser. Ingen av dem får en moderne gateway til å forhandle om noe den ikke lenger tilbyr.

Les feilfasen før du velger en reparasjon. Et avvist forslag og et avvist passord gir lignende frontend-meldinger, men helt forskjellige bevis.

Hvor et avgrenset unntak hører hjemme

Hvis en organisasjon bevisst godtar en gammel peer i en begrenset periode, hører unntaket hjemme i den peerens profil, med en eier, en revisjonsdato og en migreringsvei til en støttet protokoll. Å holde det utenfor den globale banen er hele poenget med å kalle det avgrenset.

Be gateway-eieren bekrefte hvilke algoritmer peeren fortsatt foreslår, og hva som erstatter den. Et klientflagg kan ikke reparere et forslag serveren ikke lenger sender, og en servermigrering ingen har planlagt, vil overleve midlertidig løsning. Sett revisjonsdatoen i samme sak som unntaket, slik at innrømmelsen utløper i stedet for å bli permanent.

Kontroller forhandlingen, ikke bare det grønne ikonet

Samle bevis som identifiserer fasen i stedet for stemningen i dialogen. Kommandoene nedenfor er bare lesing, og de to første viser hvilken konfigurasjon og versjon som faktisk er i spill.

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

Den tredje kommandoen rapporterer filer som ikke lenger samsvarer med pakken, og slik melder en glemt innpakning seg. Den fjerde viser innrømmelsene profilen bærer, slik at et unntak ikke stille kan spre seg til en annen profil via en kopiert fil. Kjør begge før og etter en endring, og oppbevar utdataene sammen med tilkoblingsprofilen i stedet for i et chatvindu.

Hold feilsøkingsutdata utenfor saker til noen har lest det, fordi håndboken advarer om at det høyeste feilsøkingsnivået dumper autentiseringsdata inkludert passord. Akseptkriteriet er en autorisert, støttet avtale mellom klient og gateway, ikke et menyelement som endelig blir grønt. Hvis peeren bare tilbyr en ødelagt algoritme, er det ærlige resultatet et unntak med sluttdato eller en erstatningsprotokoll, og den avgjørelsen tilhører den som eier gatewayen. Å registrere avgjørelsen er forskjellen mellom et styrt unntak og en utilsiktet policyendring.