Hoe OpenVPN data-ciphers de versleuteling van het datakanaal kiest

De tunnel komt op, de log toont een versleuteling en de profielbeoordeling gaat verder. Dan komt er een upgrade bij een peer en hetzelfde profiel faalt met een bericht over geen gedeelde versleuteling, wat mensen op zoek stuurt naar een richtlijn om te verwijderen. Het nuttige om te begrijpen is dat data-ciphers een onderhandeling beschrijft, geen instelling. De ene kant biedt een lijst aan, de andere kiest daaruit, en het resultaat is één algoritme dat beide ondersteunen. Het lezen van die uitwisseling verklaart de meeste van deze fouten voordat je een regel wijzigt.

Twee kanalen, twee configuraties

Een OpenVPN-sessie heeft een besturingskanaal en een datakanaal. Het besturingskanaal voert de TLS-handshake uit die de tegenpartijen authenticeert en sleutels onderhandelt. Het datakanaal versleutelt de pakketten die uw verkeer dragen.

data-ciphers configureert het tweede. Het besturingskanaal heeft eigen opties, en de identiteitscontroles van het profiel zijn een derde, aparte zaak. Een wijziging aan het ene herstelt het andere niet, waardoor een profiel correct kan lijken en toch op een bepaald stadium kan falen.

Houd de drie in hun eigen vakken wanneer u een configuratiebestand leest.

Lees de onderhandeling uit de log

De clientlog noemt beide resultaten wanneer de verbinding slaagt. Eén regel meldt het besturingskanaal en de TLS-details ervan, en een andere meldt de gekozen versleuteling van het datakanaal.

Lees beide, want ze beantwoorden verschillende vragen. Een storing in het besturingskanaal stopt de verbinding voordat een dataversleuteling ertoe doet. Een afwijking in het datakanaal verschijnt na een geslaagde handshake, met een bericht over geen gedeelde versleuteling.

Vergelijk dan de aangeboden lijsten aan beide kanten. Een naam die de versie van de ene tegenpartij of zijn crypto-achtergrond niet levert, kan niet worden gekozen, hoe vroeg hij ook in de lijst van de andere tegenpartij staat.

Hoe de selectie werkelijk gebeurt

De server duwt zijn data-ciphers-lijst tijdens de handshake naar de client, en de client selecteert de eerste vermelding in die lijst die hij ook ondersteunt. De volgorde hoort dus bij de configuratie van de server, niet bij die van de client.

Dat detail verklaart een klasse verwarrende resultaten. Het herordenen van de lijst van de client verandert niets zolang de lijst van de server beslist. Het toevoegen van een versleuteling die de client niet kan leveren verandert ook niets, omdat de client de vermelding die hij kiest moet kunnen gebruiken.

Nieuwere versies veranderden de standaardlijst en hernoemden de optie die hem vroeger bevatte, zodat twee tegenpartijen op verschillende versies het oneens kunnen zijn zonder dat iemand een profiel bewerkt. Controleer de versie aan elke kant voordat u een typefout vermoedt.

Een lijst is in het abstracte geen sterkterangschikking. Het is een verzameling kandidaten, en de gekozen is de eerste wederzijds ondersteunde vermelding in de volgorde van de server. Daarom kunnen twee lijsten die er anders uitzien dezelfde versleuteling onderhandelen. Daarom kunnen ook twee lijsten die er identiek uitzien falen.

Oudere tegenpartijen hebben een bewuste terugval nodig

Een tegenpartij die helemaal niet kan onderhandelen, omdat hij ouder is dan het mechanisme of het heeft uitgeschakeld, heeft een gedocumenteerde compatibiliteitsregeling nodig. De terugvaloptie bestaat precies voor dat geval en geldt voor tegenpartijen die niet aan de onderhandeling deelnemen.

Dat is niet hetzelfde als elke oude versleuteling inschakelen om een bericht te laten verdwijnen. Een brede lijst verzwakt de sessie voor elke tegenpartij, ook voor degenen die iets sterks zouden hebben onderhandeld.

Coördineer de twee kanten in plaats van niet-verwante algoritmenamen te bewerken. Als een serverupgrade een oude optie heeft verwijderd, hoort de correctie in het versieplan, niet in een gehaaste actie bij de client.

Houd de verificatie intact

Een afwijking in het datakanaal is geen reden om een niet-geverifieerde server te accepteren. Certificaatverificatie, de verwachte servernaam en de beveiligingsinstellingen van het besturingskanaal staan los van de versleutelingskeuze en zouden elke compatibiliteitswijziging moeten overleven.

Noteer de onderhandelde dataversleuteling, de clientversie en de serverversie samen, zodat de volgende vergelijking van feiten uitgaat en niet van het profielbestand.

Test na een ondersteunde correctie de eerste verbinding en een heronderhandeling, omdat een sessie die één keer tot stand komt nog steeds kan falen wanneer sleutels worden vernieuwd.

Als de tunnel tot stand komt en sites nog steeds falen, is de versleuteling niet langer de verdachte. Ga verder met routing en DNS. Werkvolgorde: lees beide logregels, vergelijk beide lijsten, controleer versies, voeg een terugval alleen toe voor een tegenpartij die er een nodig heeft, en test daarna het vernieuwingspad opnieuw.