Waarom het toevoegen van opt-verify je OpenVPN-cifferfout niet oplost

Je vindt een suggestie om opt-verify toe te voegen, voegt de regel toe, en de cifferfout blijft precies waar die was. Dat resultaat is voorspelbaar, want de optie heeft nooit een cijfer onderhandeld. Het was een consistentiecontrole van opties, verouderd in 2.6 en verwijderd in 2.7, en een profiel dat ermee nog steeds parseert, heeft daarmee niets afgedwongen.

Het helpt om te weten wat de regel vroeger deed voordat je concludeert dat het het ontbrekende stuk is. De geschiedenis verklaart ook waarom het nu niet kan helpen.

Wat de optie vroeger afdwong

De handleiding van 2.6 markeert opt-verify als verouderd en beschrijft het eerdere gedrag: de server gooit clients weg wier opgegeven opties niet overeenkomen met de zijne, waarbij hij dingen als apparaattype en MTU vergelijkt. Die controle hangt er ook van af dat de consistentiecontrole van opties aan blijft staan, dus een server die met disable-occ draait, heeft die nooit gehad. Let op waaruit de vergelijking is opgebouwd: tekst die de configuratie van de tegenpartij beschrijft. Die zegt niets over welk cijfer het datakanaal zal gebruiken.

Dat is de eerste reden waarom de vlag een cifferfout niet kan repareren. De cifferkeuze wordt bepaald door het data-ciphers-beleid en door wat beide partijen ondersteunen, en een tekstuele consistentiecontrole breidt die lijst niet uit en voert de onderhandeling niet uit. De tweede reden is de reikwijdte: de controle gaat erover of opgegeven opties compatibel lijken, niet over de kwaliteit van het pad dat eruit volgt.

Wat 2.7 doet wanneer het de regel ziet

In 2.7 is de optie weg. De parser herkent de naam nog, waardoor een oud profiel zonder syntaxisfout laadt, en hij meldt dat de optie is verwijderd in plaats van die stilzwijgend over te slaan. Een naam herkennen en gedrag afdwingen zijn verschillende dingen, en alleen het eerste gebeurt nog. De verwijderingsnotities geven de reden: zodra parameters onderhandelbaar zijn, kunnen twee partijen legitiem verschillende optiestrings hebben terwijl ze het over de verbinding eens zijn.

Een profiel dat parseert is dus geen bewijs dat er een toegangscontrole is uitgevoerd. Als je enige signaal is dat de client verbonden is, heb je geleerd dat de syntaxis is geaccepteerd.

Waar de fout werkelijk zit

Bewaar de eerste concrete fout voordat je iets verandert, want latere meldingen zijn meestal de gevolgen ervan. Een onderhandelingsfout van het datakanaal hoort bij het goedgekeurde cifferbeleid en bij de mogelijkheden die beide partijen werkelijk adverteren. Een fout in TLS-versie of -suite hoort bij het controlekanaal. Een certificaatweigering vraagt om de identiteit en de vertrouwensketen, niet om een compatibiliteitsvlag.

Identificeer ook de engine aan beide kanten. Een desktopapplicatie kan een andere build meebrengen dan het opdrachtregelprogramma waarmee je hebt getest, en de optieondersteuning verschilt tussen beide. Raadpleeg de documentatie van die engine in plaats van aan te nemen dat elk programma dat een profiel importeert zich hetzelfde gedraagt.

Vervang de bedoeling, niet alleen de regel

Als een oudere beheerde server echt op de consistentiecontrole leunde, noteer dan welke beperking die vóór de upgrade afdwong. Een genegeerde optie in een nieuwer profiel behouden kan dat beleid niet bewaren, en regels willekeurig verwijderen ook niet.

Reageer niet op een oude suggestie dat alle cijfers zijn uitgeschakeld door elk historisch algoritme in te schakelen.

Controleer na een goedgekeurde correctie de onderhandelde resultaten op een nieuwe verbinding en test de applicatie die de gebruiker echt nodig heeft. Houd de serverversie en het effectieve beleid naast dat resultaat, zodat de volgende persoon ziet wat is afgesproken in plaats van wat alleen is geaccepteerd.

Het doel is een ondersteunde beperking en een werkend geauthenticeerd pad, geen oude vlag die nog steeds parseert.