tls-auth key-direction: 0 ve 1 farklı olmalı, aynı olmamalı
tls-auth ile iki uç zıt yönlere ihtiyaç duyar, 0 ve 1, ya da ikisi de ayarı atlamalıdır. Aynı numara başarısız olur ve tls-crypt bunu asla kullanmaz.
Tünelin bir tarafı, diğer tarafın hiç kontrol etmediği bir anahtar yuvasıyla kontrol kanalını imzalar ve bağlantı, tek bir sertifika bile değiş tokuş edilmeden bir kimlik doğrulama hatasıyla ölür. tls-auth yön uyuşmazlığı böyle görünür ve deterministiktir: aynı iki dosya her denemede, her ağdan başarısız olur. Günlükte aradığınız seçeneğin adı geçmez, bu yüzden insanlar hiç bozulmamış anahtarları yeniden oluşturur ve sertifikaları yeniden verir. Çözüm, iki ucu tamamlayıcı hale getirmek ya da ikisini de iki yönlü bırakmaktır, doğrulamayı zayıflatmak değil.
Hata sertifikalardan önce gelir
tls-auth ile her iki taraf da aynı ortak anahtarı tutar ve her biri ondan türetilen iki yuvadan birini kullanır: bir yuva giden kontrol paketlerini imzalar, diğeri gelenleri doğrular. Yön 0 ve yön 1 bu rolleri ters sırayla atar, dolayısıyla HMAC kontrollerinin uyuşması için çiftin tamamlayıcı olması gerekir. Atama bir tarafta tersine döndüğünde, alıcı yanlış yuvada imza arar ve paketi reddeder. Oturum orada biter, bu yüzden hata sertifika deposunun üreteceği bir şeyle değil, paket kimlik doğrulamasıyla ilgilidir.
Determinizm teşhis için önemlidir, çünkü zaman veya yol sorunu farklı bir iz bırakır: aralıklı kopmalar, tek yönün başarısız olması ya da yalnızca belirli bir ağda ölen oturum. Yön uyuşmazlığı her seferinde ilk el sıkışmada başarısız olur ve aynı iki dosyayı taşıyan başka bir makinede de aynı şekilde başarısız olur. Günlüğü --verb 4 ile okuyun ve son satır yerine ilk reddedilen paketi bulun. Bu ret herhangi bir sertifika değişiminden önce gerçekleşiyorsa, ortak anahtar ve yönü kontrol etmeye değer iki şeydir.
| What you see | What it rules out | Next check |
|---|---|---|
| Authentication error before any certificate is sent | The data channel is irrelevant; the control channel never authenticated | Compare tls-auth and its direction on both ends |
| Certificate or handshake failure after the control channel authenticates | The shared key and its direction already agree | Check the CA, the certificate dates and the hostname |
| Session completes but throughput or cipher warnings appear | Direction was never the problem | Compare the data-channel cipher settings |
| Startup stops on an options error | The number itself is not the issue | Re-read the inline versus external directive syntax |
Numara nerede yaşar
Kılavuz OpenVPN 2.6 yön için iki yer belgeler: anahtar kendi dosyasındayken tls-auth ikinci argümanı ve anahtar profile gömülüyken ayrı bir key-direction satırı. İkisi de aynı değeri ayarlar, bu yüzden profil bir biçimi ya da diğerini kullanmalı, asla ikisini birden değil. Atlama da bir seçimdir ve hiçbir taraf yön belirtmediğinde çalışan iki yönlü bir düzenlemeye iki tarafı da koyar. Aynı numarayı taşıyan iki taraf o düzenlemede değildir: her biri bir yuvada imzalamayı ve diğerinde doğrulamayı bekler, ikisi de bunu aynı şekilde yapar.
# 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
Gömülü biçim kendi satırında bir yönergedir, anahtar bloğunun açılış etiketinde bir öznitelik değildir ve o etikete argüman eklemek yön değişikliği değil hatadır. Yerleşim de önemlidir: yönerge ait olduğu bloğun dışındadır, bu yüzden bloğun içine yazılan değer anahtar malzemesi olarak okunur. Profilin dağıtıcısının amaçladığı düzenlemeyi kopyalayın, bir çift uydurmayın, çünkü bir sunucuya karşı çalışan bir profil diğer tarafta zaten yansıtılmış olabilir.
Seçeneğin dokunmadığı şeyler
Uygulama trafiğini şifrelemez. tls-auth kontrol kanalı paketlerinin çevresine bir HMAC koyar, veri kanalı ise el sıkışma sırasında görüşülen oturum anahtarlarıyla korunur, bu yüzden aktarım hızı veya şifre sorusunun yön numarasıyla hiçbir ilgisi yoktur. Ayar ikinci bir şifreleme katmanı da eklemez ve insanları daha uzun bir anahtar aramaya gönderen tam olarak bu varsayımdır.
Bu, tls-crypt için geçerli değildir, kendi seçenekleri ve anahtar işlemesi olan başka bir kontrol kanalı mekanizmasıdır ve hiçbir tarafın sertifika kimliği hakkında bir şey söylemez. Bu yüzden çalışan bir yön eşleşmesi yalnızca iki ucun kontrol kanalının nasıl doğrulanacağı konusunda anlaştığını kanıtlar, güven zincirinin doğrulandığını değil.
Çifti hizalayın, sonra yeniden bağlanın
Herhangi birini değiştirmeden önce iki yapılandırmayı karşılaştırın, çünkü zaten doğru olan tarafı düzenlemek işi ikiye katlar. Aşağıdaki grep her dosyanın hangi mekanizmayı seçtiğini gösterir; ayrıntılı çalıştırma kontrol kanalının kimlik doğrulamasının yapılıp yapılmadığını gösterir. Her iki çıktıyı da saklayın, böylece bir sonraki değişiklik bilinen bir durumla karşılaştırılabilir.
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'
Her değişiklikten sonra iki ucu da yeniden başlatın, çünkü bu seçenekler başlangıçta bir kez okunur ve bir tarafı yeniden yüklemek çifti eski oturumun ömrü boyunca tutarsız bırakır. Dağıtım şu anda yapılandırılmış bir yön olmadan çalışıyorsa, ayarı bir uca eklemek başladığınız hatayı yeniden üretir; ya ikisini de bırakın ya da ikisini de yapılandırın. Bir seferde bir ucu değiştirin ve önceki dosyayı saklayın, böylece gerileme yeniden derleme değil iki dakikalık bir geri alma olur.
Her uç için mekanizmayı, anahtar dosyasını ve yönü dağıtım notlarına kaydedin, aksi halde bir sonraki kişi iki benzer dosyayı okuyup numaraların birbiriyle eşleşmesi gerektiğini varsayar. Yön bir koordinasyon ayrıntısıdır, güvenlik yükseltmesi değildir: kontrol kanalının iki yönünü ayırır ve başka hiçbir şey yapmaz.