DH dosyası mı tls-auth anahtarı mı? İki OpenVPN dosyasını ayırmak

İki dosya, iki yönerge ve ikisini de yapılandırdıkları şeyin adıyla adlandırma alışkanlığı. Böylece dh.pem bir tls-auth satırına düşer ve istemci beklenmeyen bir anahtar biçimiyle ilgili bir mesajla başarısız olur. Önünüzdeki karar hangi dosyanın daha güçlü olduğu değil. Dağıtımın gerçekten hangi role ihtiyacı olduğudur ve üç koşul bunu belirler: TLS yığınınızın hangi anahtar değişimini görüşeceği, kontrol kanalı kimlik doğrulamasını isteyip istemediğiniz ve malzemenin gizli kalması gerekip gerekmediği.

Bunları sırayla yanıtlayın, dosya sorusu kendini yanıtlar. Atlarsanız yönerge adları birbirinin yerine geçebilir görünmeye başlar ve hata tam olarak bu durumdan doğar.

Dosya adından önce etiketi okuyun

Dosyanın ilk satırı adından daha çok şey söyler, çünkü ad insan uzlaşımıdır, etiketi ise araç üretir. Diffie-Hellman parametreleri BEGIN DH PARAMETERS PEM etiketini taşır. OpenVPN statik anahtarı tamamen başka bir yapıdır, kendi başlığı ve onaltılık yükü vardır.

Yeniden adlandırma hiçbir şeyi dönüştürmez. ta.key adlı parametre dosyası hâlâ parametredir ve dh.pem adlı statik anahtar hâlâ statik anahtardır; ayrıştırıcı içeriği okur ve uyumsuzluğu reddeder. Profili düzenlemeden önce kontrol edin:

head -n 1 dh.pem
head -n 1 ta.key

Hangi dosyaya ihtiyacınız olduğunu belirleyen üç koşul

İlk koşul değişimdir. Sonlu alanda Diffie-Hellman el sıkışması bir grup gerektirir ve dh yönergesi sunucunun bunun için parametreleri adlandırdığı yerdir. Eliptik eğri el sıkışması o dosyaya hiç ihtiyaç duymaz, çünkü eğri parametre kümesinin kendisidir. Sunucunuz yalnızca ECDHE paketleriyle görüşüyorsa, DH dosyası ek güç değil ölü ağırlıktır.

İkinci koşul kontrol kanalı kimlik doğrulamasıdır, kendi malzemesi olan ayrı bir özelliktir. tls-auth dosyası iki tarafın da tuttuğu ortak statik anahtardır ve kontrol kanalı paketlerini imzalamak için kullanılır, böylece kimliği doğrulanmamış taraf el sıkışmayı bile tamamlayamaz. Sonlu alan DH kullansanız da kullanmasanız da vardır ve grup parametreleriyle ilgisi yoktur.

Üçüncü koşul gizlilik ve dağıtımdır. DH parametreleri oturumu zayıflatmadan yayımlanabilir, çünkü gizli değerler her el sıkışma için üretilir ve tarafları asla terk etmez. Statik anahtar yayımlanmamalıdır: iki uçta aynı baytlardır, kendiliğinden dönmez ve elinde bulunduran herkes geçerli kontrol kanalı imzaları üretebilir. Bu iki yanıt tamamen farklı işlem kurallarına işaret eder, bu yüzden dosyalardan biri bir depoda durabilir, diğeri duramaz.

Her rol için doğru malzemeyi üretin

Yönergenin beklediği biçimi üreten aracı kullanın, aralarında dönüştürmek yerine. OpenVPN 2.6'daki ortak anahtar için üretecin tipli biçimi amacı açıkça belirtir.

openvpn --genkey tls-auth ta.key

Bu komut yeni gizli malzeme oluşturur; var olan bir anahtarı onarmaz veya incelemez ve yeniden çalıştırmak size diğer taraflarda olmayan farklı bir anahtar verir. Ortaya çıkan dosyayı ihtiyaç duyan taraflara herhangi bir ortak sır için kullanacağınız kanaldan kopyalayın ve yön uzlaşımını tutarlı tutun: tls-auth ile bir taraf key-direction 0, diğeri key-direction 1 kullanır.

DH parametreleri gerektiğinde anahtar üretecinden değil parametre üretiminden gelir ve sonuç açık olsa bile kökenleri önemlidir. Bilinmeyen bir kaynaktan alınan grup açık olduğu için güvenilir hale gelmez; hâlâ taraflarınızın üzerinde anlaştığı ve boyutu ya da yapısı tarafından zayıflatılmayan bir grup olmalıdır.

dh none ne anlama gelir, ne anlama gelmez

dh none dar anlamlı gerçek bir yönergedir: sonlu alan parametre dosyası yüklenmez, çünkü el sıkışma eliptik eğri Diffie-Hellman kullanır. Bir şeyi zayıflatma anlamında «DH adımını atla»nın kısaltması değildir ve OpenVPN'e başka bir dosyayı yedek olarak kabul etmesini kesinlikle söylemez.

Yanlış okumaktan iki hata doğar. Birincisi dh none yönergesinin tls-auth ihtiyacını ortadan kaldırdığını sanmaktır, oysa ikisi farklı şeyleri denetler. İkincisi yalnızca eğri yapılandırmasının yanında eski bir dh satırı tutup sonra sunucunun gerçekte hangi dosyayı kullandığını merak etmektir; yönerge varsa dosya okunur ve oradaki bozuk yol, görüşülecek değişimle ilgisi olmayan bir nedenle başlatmayı başarısız kılar.

Yanlış dosya zaten dağıtıldıysa

Amaçlanan sırrı profil sahibinden geri yükleyin ve bunu yaparken sertifika doğrulamasına dokunmayın. Hata bir biçim uyumsuzluğudur, güven hatası değildir ve hatayı atlamak için doğrulamayı kapatmak başlatma sorununu sessiz bir sorunla değiştirir.

Sonra insanların birleştirme eğiliminde olduğu iki olayı ayırın. Bir DH parametre dosyasını yayımlamak neredeyse zararsızdır, çünkü parametreler tasarımı gereği açıktı. tls-auth anahtarını açığa çıkarmak başka bir olaydır: anahtar, onu tutan her taraf için kontrol kanalı paketlerinin kimliğini doğrular, bu yüzden değiştirme tek bir ana makinede değil tüm dağıtımda eşgüdümlü yapılmalıdır.

Beş dakikalık bir kontrol hangi durumda olduğunuzu belirler: her dosyanın ilk satırını okuyun, ona başvuran yönergeyi doğrulayın ve dosyanın dağıtımının malzemenin gerektirdiğiyle eşleştiğini doğrulayın. Bu, çalışan bir PKI'yi yeniden oluşturmaktan küçük bir iştir ve üç koşulun baştan beri işaret ettiği de budur.