Ien kant fan de tunnel ûndertekent it kontrôlekanaal mei in kaaislot dat de oare kant nea kontrolearret, en de ferbining stjert mei in autentikaasjeflater foardat ien sertifikaat útwiksele is. Sa sjocht in rjochtingsôfwiking by tls-auth derút, en it is deterministysk: deselde twa bestannen mislearje by elke poging, fan elk netwurk. Neat yn it loch neamt de opsje dy't jo sykje, dêrom bouwe minsken kaai opnij en jouwe sertifikaten opnij út dy't nea stikken wiene. De oplossing is de twa kanten komplemintêr te meitsjen of beide twarjochtings te litten, ynstee fan de ferifikaasje te ferswakjen.

De flater bart foar de sertifikaten

Mei tls-auth hâlde beide pearen deselde dielde kaai en elk brûkt ien fan twa slots dy't dêrút ôflaat binne: ien slot ûndertekent útgeande kontrôlepakketten, it oare ferifiearret ynkommende. Rjochting 0 en rjochting 1 jouwe dy rollen yn tsjinoerstelde folchoarder ta, dus it pear moat komplemintêr wêze om de HMAC-kontrôles oerienkomme te litten. As de tawizing oan ien kant omkeard is, siket de ûntfanger in hantekening yn it ferkearde slot en wiist it pakket ôf. De sesje einiget dêr, dêrom giet de flater oer pakketautentikaasje en net oer eat dat de sertifikaatopslach produsearje soe.

It determinisme is wichtich foar diagnostyk, want in tiid- of paadprobleem lit in oar spoar efter: ûnregelmjittige ûnderbrekkings, ien rjochting dy't mislearret, of in sesje dy't allinne op in beskaat netwurk stjert. In rjochtingsôfwiking mislearret elke kear by de earste hânskud, en it mislearret identyk op in oare masine mei deselde twa bestannen. Lês it loch by --verb 4 en fyn it earste ôfwiisde pakket ynstee fan de lêste rigel. As dy ôfwizing foar elke sertifikaatútwikseling bart, binne de dielde kaai en syn rjochting de twa dingen dy't it kontrolearjen wurdich binne.

What you seeWhat it rules outNext check
Authentication error before any certificate is sentThe data channel is irrelevant; the control channel never authenticatedCompare tls-auth and its direction on both ends
Certificate or handshake failure after the control channel authenticatesThe shared key and its direction already agreeCheck the CA, the certificate dates and the hostname
Session completes but throughput or cipher warnings appearDirection was never the problemCompare the data-channel cipher settings
Startup stops on an options errorThe number itself is not the issueRe-read the inline versus external directive syntax

Wêr't it nûmer wennet

De hânlieding foar OpenVPN 2.6 dokumintearret twa plakken foar de rjochting: it twadde argumint fan tls-auth as de kaai yn in eigen bestân stiet, en in selsstannige key-direction-rigel as de kaai yn it profyl yntsletten is. Beide sette deselde wearde, dus in profyl moat de iene foarm of de oare brûke, nea beide. Weilitten is ek in kar, en it set beide pearen yn in twarjochtingsregeling dy't wurket as gjin kant in rjochting neamt. Twa pearen mei itselde nûmer binne net yn dy regeling: elk ferwachtet yn ien slot te ûndertekenjen en yn it oare te ferifiearjen, en beide dogge dat op deselde wize.

# 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 yntsletten foarm is in rjochtline op syn eigen rigel, net in attribút op de iepeningstag fan it kaai-blok, en in argumint oan dy tag taheakje is in flater, net in rjochtingsferoaring. It plak makket ek út: de rjochtline stiet bûten it blok dêr't it by heart, dus in wearde dy't yn it blok skreaun is, wurdt as kaaimateriaal lêzen. Kopiearje de regeling dy't de fersprieder fan it profyl bedoelde ynstee fan in pear te betinken, want in profyl dat tsjin ien server wurket, is miskien al oan de oare kant spegele.

Wat de opsje gewurde lit

It fersiferet gjin applikaasjeferkear. tls-auth set in HMAC om de pakketten fan it kontrôlekanaal, wylst it datakanaal beskerme wurdt troch sesjekaaien dy't by de hânskud ûnderhannele wurde, dus in fraach oer trochset of sifer hat neat mei it rjochtingsnûmer te krijen. De ynstelling foeget ek gjin twadde fersiferingslaach ta, en dat is de oanname dy't minsken op syk stjoert nei in langer kaai.

It jildt net foar tls-crypt, in oar kontrôlekanaalmeganisme mei syn eigen opsjes en kaaiôfhanneling, en it seit neat oer de sertifikaatidentiteit fan hokker pear dan ek. In wurkjende rjochtingoerienkomst bewiist dus allinne dat beide kanten it iens binne oer hoe't it kontrôlekanaal autentisearre wurdt, net dat de fertrouwenskeatling falidearre is.

Rjochtsje it pear út, ferbyn dan opnij

Fergelykje de twa konfiguraasjes foardat jo ien fan beide feroarje, want it bewurkjen fan de kant dy't al goed wie, ferdûbelet it wurk. De grep hjirûnder lit sjen hokker meganisme elk bestân kiest; de wiidweidige run lit sjen oft it kontrôlekanaal uberhapt autentisearre is. Bewarje beide útfieringen, sadat de folgjende feroaring tsjin in bekende tastân fergelike wurde kin.

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'

Start beide pearen opnij nei elke feroaring, want dizze opsjes wurde by it starten ien kear lêzen en it werladen fan ien kant lit it pear ynkonsistint efter foar de hiele libbensdoer fan de âlde sesje. As de útrôl no wurket sûnder in konfigurearre rjochting, dan reprodulearret it tafoegjen fan de ynstelling oan ien pear de flater dêr't jo mei begûn binne; lit se beide gewurde of konfigurearje beide. Feroarje ien ein tagelyk en bewarje it foarige bestân, sadat in regression in weromdraai fan twa minuten is ynstee fan in weropbou.

Skriuw it meganisme, it kaaibestân en de rjochting foar elk ein yn de útrôlnotysjes, want oars lêst de folgjende persoan twa like bestannen en nimt oan dat de nûmers by elkoar passe moatte. De rjochting is in koördinaasjedetail, gjin feiligensferbettering: it skiedt de twa rjochtings fan it kontrôlekanaal en docht neat oars.

Relatearre artikelen