Tunnelblick data-ciphers niet herkend: welke engine liep er?

Tunnelblick meldt een onbekende data-ciphers-optie, noemt OpenVPN 2.4 in dezelfde adem, en de verbinding start nooit. Dit is een lokale parsefout en geen meningsverschil over de cipher, omdat de engine het profiel weigerde voordat er enige onderhandeling met de gateway plaatsvond. Het gebruikelijke advies over het cipherbeleid van de server kan hier niet helpen; de parser moet eerst het bestand begrijpen. Zoek de engine die deze ene configuratie daadwerkelijk startte, en de rest volgt.

Lees de logregel voordat je het profiel aanraakt

Open de mislukkende verbinding in het detailvenster van Tunnelblick en lees de log van bovenaf. De eerste regels noemen de engineversie en het profiel dat eraan wordt gegeven, gevolgd door de optie die het parsen stopte. Alles daarna is ruis, omdat het proces is afgesloten.

Noteer drie feiten uit dat log: de engineversie, de configuratienaam en het exacte bericht. Die drie zijn de hele diagnose. Ze zijn ook wat je nodig hebt als de oplossing blijkt te vereisen dat de geïnstalleerde toepassing verandert. Maak een schermafbeelding van de regels in plaats van ze te parafraseren, want optienamen worden snel verkeerd getypt als je ze uit je geheugen herhaalt.

Bevestig welke engine die configuratie uitvoert

Tunnelblick is een toepassing rond een OpenVPN-engine, en verschillende configuraties kunnen verschillende engines uitvoeren. Controleer de versie die voor deze configuratie is gekozen in het detailvenster in plaats van de toepassingsversie te lezen, en vervang die niet door de uitvoer van een terminal-openvpn-binair bestand dat de configuratie nooit gebruikt. De gids voor OpenVPN-versies van Tunnelblick beschrijft hoe die selectie werkt en waar de keuze wordt opgeslagen.

Het onderscheid is belangrijk omdat een machine een modern binair bestand in het PATH kan hebben en een meegeleverde 2.4-engine achter de verbinding die mislukte. Het profiel wordt door de tweede beoordeeld.

openvpn --version
ls /Applications/Tunnelblick.app/Contents/Resources/openvpn/

Deze twee opdrachten laten zien wat een terminal zou uitvoeren en welke enginemappen de geïnstalleerde toepassing bevat. Geen van beide bewijst wat de mislukte configuratie gebruikte, omdat de log je dat al heeft verteld, en de paden verschillen tussen Tunnelblick-versies.

Waarom de naam van de richtlijn veranderde

OpenVPN introduceerde data-ciphers in 2.5 als de onderhandelingslijst en verving de eerdere ncp-ciphers-spelling die in die versie verouderd raakte. Een 2.4-engine kent die optie niet en stopt bij het eerste token dat hij niet kent. Ook de enkele cipher-optie is geen ouder alias voor de lijst; ze benoemt één cipher in plaats van een onderhandelingsset.

Daarom levert tekstvervanging tussen versies profielen op die parsen en zich daarna onverwacht gedragen, en daarom is het kopiëren van een fragment uit een forumbericht geen versiecontrole. De optienamen verschoven mee met de terugvalafhandeling en de standaardwaarden, en een bestand dat is samengesteld door één richtlijn te hernoemen is niet gelijkwaardig aan een bestand dat voor de engine is geschreven.

Repareer de engine of het profiel, niet het symptoom

Voor een ondersteunde uitrol is de duurzame reparatie een ondersteunde combinatie van Tunnelblick en engine die het profiel van de operator accepteert, geregeld via degene die de installatie van de toepassing bezit. Als een oudere installatie een tijdje moet blijven, vraag dan een profiel dat voor die engine is geschreven en voor de ciphers die de gateway werkelijk accepteert.

Het verwijderen van data-ciphers en data-ciphers-fallback wist deze specifieke parsefout inderdaad, en dat is precies waarom het verleidelijk is. Het verandert ook stilzwijgend welke ciphers worden onderhandeld, in een beveiligingsconfiguratie die je niet van plan was te bewerken. Bewaar het oorspronkelijke profiel en vergelijk in plaats daarvan de ondersteunde instellingen bewust.

Probeer opnieuw en lees de volgende fase

Probeer na de correctie de verbinding opnieuw en lees de nieuwe log vanaf het begin in plaats van succes aan te nemen. Een profiel dat nu parset kan nog steeds stoppen bij de cipher-onderhandeling, bij de certificaatverificatie, bij de authenticatie of bij de routering, en elk van die fouten heeft zijn eigen bewijs.

Als de onderhandeling mislukt, vergelijk dan de ciphers die beide partijen ondersteunen met die welke elk mag gebruiken. Als de authenticatie mislukt, werken het profiel en de engine nu goed genoeg om de gateway te hebben bereikt, wat vooruitgang is die het noteren waard is. Die keten stoppen bij de eerste stille log is hoe een beveiligingsinstelling om de verkeerde reden wordt verwijderd.