Twee reparaties lijken even snel wanneer een oude vpnc-verbinding niet opkomt: de oude zwakke-versleutelingsvlag doorgeven, of een wrapperscript plaatsen dat hem voor u toevoegt. Ze zijn niet gelijkwaardig, want de ene wijzigt het beleid van één profiel en de andere het gedrag van elk programma dat dat pad aanroept. De eerste vraag is of de gateway nog een zwak voorstel biedt, en de tweede wie het mag accepteren. Al het andere volgt uit die twee antwoorden.

Twee reparaties met heel verschillende impact

Een wijziging op profielniveau raakt één verbinding, één eigenaar en één vervaldatum. Het vervangen van de geïnstalleerde binary raakt elke frontend op de machine, inclusief de desktopapplet die een collega voor een heel ander gatewayprofiel gebruikt. De wrapper verbergt de wijziging ook voor iedereen die de host een half jaar later debugt.

Pakketverificatie is het eerste slachtoffer: een bestand op /usr/sbin/vpnc dat niet meer bij zijn pakket past, verandert een routinematige beveiligingsupdate in een onderzoek. Upgrades overschrijven de wrapper dan stil of weigeren te worden toegepast, afhankelijk van hoe de pakketbeheerder gewijzigde bestanden behandelt. Geen van beide uitkomsten verschijnt in het verbindingslog, waardoor de wrapperaanpak aantrekkelijk blijft tot het eerste incident. Eén regel in een profiel is veel gemakkelijker te vinden en te verwijderen dan een binary waarvan niemand zich herinnert hem te hebben vervangen.

Wat de verouderde schakelaar werkelijk doet

De vpnc-handleiding markeert de single-DES-optie als verouderd ten gunste van een instelling voor zwakke versleuteling, en documenteert een aparte optie die helemaal geen versleuteling van dataverkeer toestaat. Dat zijn verschillende concessies met verschillende gevolgen. Geen van beide dwingt een moderne gateway te onderhandelen over iets wat hij niet meer biedt.

Lees de faalfase voordat u een reparatie kiest. Een afgewezen voorstel en een afgewezen wachtwoord geven vergelijkbare frontendmeldingen maar volledig verschillend bewijs.

Waar een beperkte uitzondering hoort

Als een organisatie bewust een oude peer voor een beperkte periode accepteert, hoort de uitzondering in het profiel van die peer, met een eigenaar, een herzieningsdatum en een migratiepad naar een ondersteund protocol. Hem buiten het globale pad houden is precies de bedoeling van de term beperkt.

Laat de gateway-eigenaar bevestigen welke algoritmen de peer nog voorstelt en wat hem vervangt. Een clientvlag kan geen voorstel repareren dat de server niet meer stuurt, en een servermigratie die niemand heeft gepland, overleeft de tijdelijke oplossing. Zet de herzieningsdatum in dezelfde ticket als de uitzondering, zodat de concessie verloopt in plaats van permanent te worden.

Controleer de onderhandeling, niet alleen het groene pictogram

Verzamel bewijs dat de fase identificeert in plaats van de stemming van de dialoog. De onderstaande opdrachten zijn alleen-lezen, en de eerste twee laten zien welke configuratie en versie werkelijk in het spel zijn.

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

De derde opdracht meldt bestanden die niet meer bij het pakket passen, en zo kondigt een vergeten wrapper zich aan. De vierde toont de concessies die het profiel draagt, zodat een uitzondering zich niet stil via een gekopieerd bestand naar een tweede profiel kan verspreiden. Voer beide voor en na een wijziging uit, en bewaar de uitvoer bij het verbindingsprofiel in plaats van in een chatvenster.

Houd debug-uitvoer buiten tickets tot iemand die heeft gelezen, want de handleiding waarschuwt dat het hoogste debug-niveau authenticatiegegevens inclusief wachtwoorden dumpt. Het acceptatiecriterium is een geautoriseerde, ondersteunde overeenkomst tussen client en gateway, geen menu-item dat eindelijk groen wordt. Als de peer alleen een kapot algoritme biedt, is de eerlijke uitkomst een uitzondering met einddatum of een vervangend protocol, en die beslissing hoort bij wie de gateway bezit. De beslissing vastleggen is het verschil tussen een beheerde uitzondering en een toevallige beleidswijziging.

Gerelateerde artikelen