tls-auth key-direction: 0 en 1 moeten verschillen, niet overeenkomen

De ene kant van de tunnel ondertekent het controlekanaal met een sleuf die de andere kant nooit controleert, en de verbinding sterft met een authenticatiefout voordat er één certificaat is uitgewisseld. Zo ziet een richtingsconflict bij tls-auth eruit, en het is deterministisch: dezelfde twee bestanden falen bij elke poging, vanaf elk netwerk. Niets in het log noemt de optie die u zoekt, daarom bouwen mensen sleutels opnieuw en geven certificaten opnieuw uit die nooit kapot waren. De oplossing is de twee kanten complementair maken of beide bidirectioneel laten, in plaats van de verificatie te verzwakken.

De fout treedt op vóór de certificaten

Bij tls-auth hebben beide peers dezelfde gedeelde sleutel en elk gebruikt een van de twee daarvan afgeleide sleuven: de ene sleuf ondertekent uitgaande controlepakketten, de andere verifieert inkomende. Richting 0 en richting 1 wijzen die rollen in omgekeerde volgorde toe, dus het paar moet complementair zijn zodat de HMAC-controles kloppen. Als de toewijzing aan één kant wordt omgedraaid, zoekt de ontvanger een handtekening in de verkeerde sleuf en verwerpt het pakket. De sessie eindigt daar, en daarom gaat de fout over pakketauthenticatie en niet over iets wat het certificaatarchief zou produceren.

Het determinisme is belangrijk voor diagnose, want een tijd- of padprobleem laat een ander spoor achter: onregelmatige onderbrekingen, één richting die faalt, of een sessie die alleen op een bepaald netwerk sterft. Een richtingsconflict faalt elke keer bij de eerste handdruk, en het faalt identiek op een andere machine met dezelfde twee bestanden. Lees het log bij --verb 4 en zoek het eerste verworpen pakket in plaats van de laatste regel. Als die verwerping vóór enige certificaatuitwisseling plaatsvindt, zijn de gedeelde sleutel en zijn richting de twee dingen die het controleren waard zijn.

Waar het nummer woont

De handleiding van OpenVPN 2.6 documenteert twee plaatsen voor de richting: het tweede argument van tls-auth wanneer de sleutel in een eigen bestand staat, en een zelfstandige key-direction-regel wanneer de sleutel in het profiel is ingebed. Beide zetten dezelfde waarde, dus een profiel moet de ene of de andere vorm gebruiken, nooit beide. Weglaten is ook een keuze, en het zet beide peers in een bidirectionele opstelling die werkt wanneer geen van beide kanten een richting noemt. Twee peers met hetzelfde nummer zitten niet in die opstelling: elk verwacht in de ene sleuf te ondertekenen en in de andere te verifiëren, en beide doen dat op dezelfde manier.

# server.conf, external key
tls-auth ta.key 0

# client.ovpn, external key
tls-auth ta.key 1

# client.ovpn, inline key
key-direction 1

De ingebedde vorm is een richtlijn op een eigen regel, geen attribuut op de openingstag van het sleutelblok, en een argument aan die tag toevoegen is een fout, geen richtingswijziging. Ook de plaats is belangrijk: de richtlijn staat buiten het blok waar hij bij hoort, dus een waarde die binnen het blok is geschreven wordt als sleutelmateriaal gelezen. Kopieer de opstelling die de verdeler van het profiel bedoelde in plaats van een paar te verzinnen, want een profiel dat tegen één server werkt, is misschien al aan de andere kant gespiegeld.

Wat de optie ongemoeid laat

Hij versleutelt geen applicatieverkeer. tls-auth zet een HMAC om de pakketten van het controlekanaal, terwijl het datakanaal wordt beschermd door sessiesleutels die tijdens de handdruk worden onderhandeld, dus een vraag over doorvoer of cijfer heeft niets met het richtingsnummer te maken. De instelling voegt ook geen tweede versleutelingslaag toe, en dat is de aanname die mensen op zoek stuurt naar een langere sleutel.

Hij geldt niet voor tls-crypt, een ander controlekanaalmechanisme met eigen opties en sleutelbehandeling, en hij zegt niets over de certificaatidentiteit van welke peer dan ook. Een werkende richtingsovereenkomst bewijst dus alleen dat beide kanten het eens zijn over hoe het controlekanaal wordt geauthenticeerd, niet dat de vertrouwensketen is gevalideerd.

Lijn het paar uit en verbind opnieuw

Vergelijk de twee configuraties voordat u een van beide wijzigt, want de kant bewerken die al correct was verdubbelt het werk. De grep hieronder toont welk mechanisme elk bestand kiest; de uitvoerige run toont of het controlekanaal überhaupt is geauthenticeerd. Bewaar beide uitvoer, zodat de volgende wijziging met een bekende toestand kan worden vergeleken.

grep -n -E 'tls-auth|tls-crypt|key-direction' server.conf client.ovpn
openvpn --config client.ovpn --verb 4 2>&1 | grep -i -E 'hmac|tls error|control channel'

Herstart beide peers na elke wijziging, want deze opties worden bij het opstarten één keer gelezen en het herladen van één kant laat het paar inconsistent voor de hele levensduur van de oude sessie. Als de uitrol momenteel werkt zonder geconfigureerde richting, reproduceert het toevoegen van de instelling aan één peer de fout waarmee u begon; laat ze beide met rust of configureer beide. Wijzig één kant tegelijk en bewaar het vorige bestand, zodat een regressie een terugdraai van twee minuten is en geen herbouw.

Noteer het mechanisme, het sleutelbestand en de richting voor elke kant in de uitrolnotities, want anders leest de volgende persoon twee vergelijkbare bestanden en neemt aan dat de nummers bij elkaar moeten passen. De richting is een coördinatiedetail, geen beveiligingsupgrade: hij scheidt de twee richtingen van het controlekanaal en doet verder niets.