OpenVPN kimlik dosyası mı yönetim soketi mi: hangisi betiklenir

auth-user-pass hesap istemini karşılar; yönetim soketi dördünü de karşılar. Maruziyeti, betik maliyetini ve her birinin bir hizmette nasıl başarısız olduğunu karşılaştırın.

OpenVPN'i başlatıp hiç bağlanmayan bir betik genellikle ağ sorunu değildir: istemci, üzerine çizecek bir terminali olmayan bir komut istemi önünde oturuyordur. OpenVPN bu isteme insan olmadan yanıt vermenin tam olarak iki destekli yolunu sunar, auth-user-pass arkasındaki kimlik dosyası ve yönetim soketi, ve bunlar birbirinin yerine geçmez. Dosya bir yönergeye mal olur ve bir isteme yanıt verir; soket her isteme yanıt verir ve bir loopback portu açabilen her şeye kimlik doğrulamasız bir kontrol kanalı verir. Hangisinin dağıtımınıza ait olduğu, gerçekte hangi istemin tıkadığına ve hangi sırrı hareketsiz bırakmayı göze alabildiğinize bağlıdır.

Mekanizmayı seçmeden önce istemi adlandırın

Dört istem terminalde aynı görünür. Hesap çifti sunucunun PAM veya auth-user-pass-verify ayarından gelir ve auth-user-pass bunu yanıtlar. Özel anahtar parolası anahtar dosyasına aittir ve --askpass ile okunur ya da elle yazılır. Bir PKCS#12 paketi kendi parolasını ister. Proxy kimlik doğrulaması hesap kimlik bilgilerini değil, --http-proxy'nin aldığı auth dosyasını kullanır.

OpenVPN systemd, PHP veya Node'un çocuğu olarak çalıştığında terminal yoktur, bu yüzden bunlardan herhangi biri sessizce tıkar. Süreç orada oturur, günlük şifre satırından sonra durur ve birim sonunda zaman aşımına uğrar; insanların hangi istemin beklediğine bakmak yerine yeniden deneme döngüsü veya sleep eklemesinin nedeni o sessizliktir. Dördüne de yalnızca yönetim soketi yanıt verebilir. Kimlik dosyası birincisine yanıt verir ve başka hiçbir şeye vermez.

auth-user-pass: bir dosya, bir istem

Dosya kullanıcı adını birinci satırda ve parolayı ikinci satırda tutar, başka hiçbir şey yoktur: tırnak yok, anahtar adı yok, yorum yok. Modu 600 yapın ve sahibini openvpn'i çalıştıran hesap yapın; bu bir hizmet için çoğu zaman sizin oturumunuz değil ayrı bir kullanıcıdır. /root altında root'a ait bir dosya, kabuğunuzda çalışan bir komutla açılışta başarısız olan bir birim arasındaki farktır.

İki ayrıntı doğru bir dosyayı isteme dönüştürür. CRLF kaydeden bir düzenleyici parolaya yapışmış bir satır başı bırakır, bu yüzden sunucu dosyada doğru görünen parolayı reddeder; gözle değil cat -A veya od -c ile denetleyin. Ve profil içindeki argümansız auth-user-pass tasarım gereği «kullanıcıya sor» anlamına gelir; komut satırındaki ikinci yönerge bunu geçersiz kılamayabilir, çünkü profil bulunduğu yerde ayrıştırılır.

Seçenek sırası üçüncü tuzaktır ve sürüme bağlıdır. Bazı OpenVPN 2.4 yapıları --config'den önce geldiğinde --auth-user-pass'ı yok sayar, bu yüzden aynı iki seçenek ters sırada bağlanır. Yönergeyi profilin içine veya komut satırında --config'den sonraya koyun ve başka bir şeyi değiştirmeden önce profildeki her geçişi grep'leyin.

auth-nocache bu mekanizmaya aittir ama hiçbir şey sağlamaz. İstemcinin kimlik bilgisini bellekte ne kadar tuttuğunu sınırlar; bu bir çökmeden sonra yardımcı olur ve dosya eksikken hiç yardımcı olmaz. Sunucu tarafında oturum zaman aşımından sonra yeniden bağlanma dosyayı yeniden okur, bu yüzden açılışta çalışan bir kimlik bilgisi gün ortasında yine de sona erebilir.

Yönetim soketi: her istem, daha fazla yüzey

İstemciyi bir dinleyiciyle başlatın ve istemlerin onun üzerinden bildirileceğini açıkça belirtin, OpenVPN 2.6 kılavuzunda belgelenen yönergeleri kullanarak:

management 127.0.0.1 3030
management-query-passwords

Bash'ten bağlantıyı yedek bir dosya tanımlayıcısında tutun ve konuma değil istem adına göre yanıt verin, çünkü yeniden bağlanma farklı bir sırada sorabilir:

exec 3<>/dev/tcp/127.0.0.1/3030
while read -r -u 3 line; do
  case "$line" in
    *"Need 'Auth' username/password"*)
      echo 'username "Auth" alice' >&3
      echo 'password "Auth" secret' >&3 ;;
    *"Need 'Private Key' password"*)
      echo 'password "Private Key" secret' >&3 ;;
  esac
done

Sınır taşımadır. Yönetim protokolü loopback üzerinde TCP üzerinden düz metindir, bu yüzden dinleyici uzak bir denetleyicinin ona ulaşması için bir LAN veya tünel adresinde yayımlanmamalıdır; uzak denetleyici daha geniş bir bağlama değil SSH yönlendirmesi anlamına gelir. Topluluk daemonu da aynı anda yalnızca bir yönetim istemcisi kabul eder, bu yüzden bir GUI veya monitör soketi betiğinizle paylaşamaz. İkinci bağlantı kuyruğa alınmadan reddedilir ve arıza sağırlaşmış bir betik gibi görünür.

O soket aynı zamanda bir kontrol kanalıdır. Yönetim parolası olmadan 127.0.0.1:3030'a bağlanabilen her şey durumu okuyabilir, tüneli öldürebilir veya bir isteme kendisi yanıt verebilir. Yönetim parolası ve kimlik dosyası aynı sınıftan sırlardır ve ikisi de aynı özeni hak eder.

Hangisi dağıtıma uyar

Kimlik dosyasını, tek istem hesap çifti olduğunda, istemci istikrarlı bir sahibi olan hizmet olarak çalıştığında ve 600 dosyayı denetlemediğiniz yedeklemelerin dışında tutabildiğinizde seçin. Yönetim soketini, anahtar parolası veya PKCS#12 parolası söz konusu olduğunda, sarmalayıcı süreci zaten gözetlediğinde veya yeniden bağlanmayı ayıklarken durumu ve istemleri izlemeniz gerektiğinde seçin.

İki koşul kararı kaydırır. Sarmalayıcı /bin/sh ise, ikiliyi doğrudan çağıran bir systemd birimi veya asgari bir konteyner ise yalnızca bash için olan soket tutkalı bulunmaz ve dosya daha ucuz yanıttır. Sır sık sık dönüyorsa hiçbir dosya onun için iyi bir ev değildir: küçük bir sarmalayıcıdan anahtarlık sorun ve birimin sarmalayıcıyı çağırmasına izin verin; bu dönüşü tek yerde tutar ve parolayı kabuk geçmişinin dışında bırakır.

Süreç yerine koyma ikisinin arasında durur ve hiçbirine ait değildir. Aşağıdaki tek satır, openvpn başlamadan önce bash onu genişlettiği için çalışır, istemci sözdizimini anladığı için değil:

openvpn --config client.ovpn --auth-user-pass <(printf "%s
%s
" "$USER" "$PASS")

/bin/sh altında, kabuğu atlayan bir birimde ve bash veya /dev/fd olmayan imajlarda bozulur. Onu etkileşimli testler için saklayın, asla bir hizmetin bağlı olduğu sözleşme olarak değil.

Sırrı koruyun, sonra günlükten doğrulayın

Her iki mekanizma da OpenVPN sürecinin okuyabileceği bir sır bırakır. Parolayı asla komut satırına veya birim dosyasına koymayın, çünkü orada ps ve systemctl onu her yerel kullanıcıya gösterir; dosyanın yolunu verin, içindeki değeri değil. Sertifikaların hesap çiftinin yerini alabildiği yerde bu, istem kategorisini gizlemek yerine ortadan kaldırır.

Doğru bir çalıştırma, istem dizisinin tamamlandığını ve oturumun «Initialization Sequence Completed» düzeyine ulaştığını gösterir. İstemci aynı istemde durursa eşleşme başarısız oldu: soketin gönderdiği tam satırları yazdırın, tırnakları ve istem adını denetleyin ve sleep eklemek yerine deseni düzeltin. Başarı bildirip hiçbir şey taşımayan bir tünel yönlendirme veya push sorunudur, kimlik bilgisi sorunu değil.

Sonra yalnızca ilk başlatmayı değil, yeniden bağlanmayı da test edin. Sunucu tarafındaki oturumu düşürün veya zaman aşımını bekleyin; istemci yeniden sorar ve tam orada açılışta doğru görünen dosyanın yeniden bağlanan hesap için hâlâ okunabilir olup olmadığı ortaya çıkar.

İlgili makaleler