OpenVPN auth-user-pass: dosya, stdin veya istem? Nasıl seçilir

Hangi kimlik bilgisi kaynağının kullanılacağını üç şey belirler: konsolda bir kişi oturuyor mu, sır diskte yaşayabilir mi ve istemi başka bir süreç mi yanıtlamalı. Yanlış seçerseniz, parola tamamen geçerliyken istemci stdin sorunu bildirir ve bu, çoğu kişiyi sebepsiz yere sunucuya gönderir. Önce yolu seçin; hata mesajları ancak hangi yolun onları ürettiğini bildiğinizde anlam kazanır.

Bunu belirleyen üç koşul

Konsol istemi insan gerektiren tek yoldur, bu yüzden bir systemd biriminde veya konteynerde sessizce başarısız olan tek yol da odur. Bir kişi istemciyi başlatıp parolayı yazarsa hiçbir dosya devreye girmez ve hassas hiçbir şey diske inmez. İstemci açılışta başlarsa aynı istem askıda kalmaya dönüşür ve zaman aşımı genellikle kimlik bilgisi hatası yerine genel bir bağlantı hatası olarak görünür.

Kimlik bilgisi dosyası, süreç gözetimsiz başladığında ve sır denetlenen bir izin kümesi altında diskte kalabildiğinde doğru yanıttır. Sır hiç yazılmamalıysa - yalnızca kasa ilkesi, kısa ömürlü belirteç - istemcinin açabileceği bir akış gerekir; bu da pratikte süreç ikamesi veya dosya tanımlayıcısına yazan bir yardımcı anlamına gelir. Yönetim arayüzü dördüncü durumu kapsar: tünelin yaşam döngüsünü zaten yöneten ve soruları soket üzerinden yanıtlayabilen bir denetleyici.

• Konsolda insan, otomasyon yok: etkileşimli istem.
• Gözetimsiz başlatma, sır saklanabilir: 0600 kipinde kimlik bilgisi dosyası.
• Gözetimsiz başlatma, sır saklanamaz: süreç ikamesi veya sır aracısının yazdığı fd.
• İstemciyi başka bir süreç sahipleniyor: yönetim arayüzü.

İki yanıt da uyduğunda, sırrı argv ve shell geçmişi dışında tutanı seçin. Program argümanı olarak verilen parolayı süreç listesi üzerinden her yerel kullanıcı okuyabilir ve bu açığa çıkmayı geri almak zordur.

Her giriş yolu gerçekte ne yapar

--auth-user-pass tek başına konsolda kullanıcı adı ve parola sorar. Bir dosya adı verildiğinde istemci ilk satırı kullanıcı adı, ikinci satırı parola olarak alır; hiçbir şey tırnak, yorum veya anahtar-değer sözdizimini desteklemez. Biçimin tamamı budur, bu yüzden onu bir INI dosyası bekleyerek düzenleyen herkes bozar. Satır içi <auth-user-pass> bloğu aynı iki satırı profil içinde tutar; bu da profilin kendisini bir sır yapar ve onu özel anahtarla aynı işlem sınıfına koyar.

Diğer iki yol bir akış ve bir sokettir. OpenVPN yalnızca okunabilir bir dosya tanımlayıcısına ihtiyaç duyar, bu yüzden süreç ikamesini, boru destekli /dev/fd girdisini veya gerçekte FIFO olan bir dosya adını kabul eder. Yönetim arayüzü doğası gereği farklıdır: istemci değerleri kendisi okumak yerine gözetleyici sürece sorar. Bu fark yeniden bağlanırken önemlidir: kimlik bilgisi dosyası, sır yardımcısının yeniden yazabildiği FIFO ve yönetim arayüzü insan olmadan yeniden sağlayabilir; süreç ikamesi sağlayamaz, çünkü tanımlayıcı ilk okumada tükenir.

Dosya tam olarak iki satır olmalı

Bozuk kimlik bilgisi dosyalarının çoğunu iki hata kipi kapsar. Windows düzenleyicisi CRLF sonlarını bırakır, satır başı parolanın parçası olur ve sunucu ekranda doğru görünen değeri reddeder. Boş ikinci satır - parolanın olması gereken yerde boş satır - istemciyi boş bir parolayla bırakır; ekrandaki değer doğru görünse de sunucu bunu reddeder. Paroladan sonraki fazladan satır sonu zararsızdır. Dosyayı düzenleyiciden değil shell'den yazın ve baytları denetleyin:

install -m 600 /dev/null /etc/openvpn/client.creds
printf '%s\n%s\n' "$VPN_USER" "$VPN_PASS" > /etc/openvpn/client.creds
od -c /etc/openvpn/client.creds | head -3

Yol, içerik kadar önemlidir. Göreli yol sürecin çalışma dizinine göre çözülür; bu bir hizmet için nadiren test ettiğiniz dizindir. Mutlak yol kullanın, dosyayı istemciyi çalıştıran hesabın mülkiyetine verin ve grup ile diğerlerinin okuyamaması için 0600 kipini koruyun. OpenVPN 2.6 kılavuzu yönergenin kabul edilen biçimlerini listeler; üçüncüsünü icat etmeden önce ona bakın.

Sunucuyu suçlamadan önce dosyayı test edin. openvpn --config client.ovpn --auth-user-pass /etc/openvpn/client.creds --verb 4 çalıştırmak dosyanın açılıp açılmadığını ve ardından kimlik bilgilerinin kabul edilip edilmediğini yazdırır; bu da bir sonraki hangi katmanı değiştireceğinizi söyler.

Akışlar, stdin ve ürettikleri hatalar

Parolayı boruya vermek çoğu kişinin ilk denediği şeydir ve en çok sürpriz barındıran yoldur. Süreç ikamesi çalışır çünkü istemcinin yalnızca okunabilir bir tanımlayıcıya ihtiyacı vardır: openvpn --config client.ovpn --verb 3 --auth-user-pass <(printf '%s\n%s\n' "$VPN_USER" "$VPN_PASS"). /dev/stdin aktarmak yalnızca istemci sorduğu anda stdin hâlâ açık ve okunabilirse çalışır; onu zaten tüketmiş bir boru hattında bu doğru değildir.

ERROR: could not read Auth username from stdin iki farklı nedene sahiptir. Bazı 2.3.x istemcilerinde mesaj, sonraki 2.3 sürümlerinin düzelttiği bir stdin işleme kusurundan geliyordu, bu yüzden bu kadar eski bir istemci yalnızca yükseltmeyle düzelir. Güncel bir istemcide aynı ifade, istemcinin konsol girdisi istediği ve stdin'in terminal olmadığı anlamına gelir - tam olarak systemd biriminde, cron işinde veya -t olmadan başlatılan konteynerdeki durum.

auth-nocache bozuk parola gibi görünen üçüncü bir döngü ekler. Kullanımdan sonra kimlik bilgilerini bellekten atar, bu yüzden ağ değişikliğinin tetiklediği yeniden bağlanmanın yeniden oynatacağı bir şey yoktur ve istem geri döner. Bu, tasarlandığı gibi çalışan yönergedir. auth-nocache istemcinin bellekte tuttuğunu değiştirir, sunucunun veya kimlik sağlayıcının hesap hakkında düşündüğünü değil, bu yüzden tüm düzeltme aynı dosyayı yeniden sağlamaktır; yeniden başlatmada yeniden okunur - ve yönetilen bir bağlantı için bu sağlama onaylı sır deposundan gelmelidir, bir betikteki paroladan değil.

İstem başka bir sürece ait olduğunda yönetim arayüzü

Tüneli zaten gözetleyen bir denetleyici onun sorularını da yanıtlayabilir. İstemciyi --management 127.0.0.1 7505 ile başlatın, durum satırlarını okuyun ve >PASSWORD:Need 'Auth' username/password öğesini izleyin. Denetleyici ayrı komut satırlarında username "Auth" alice ve ardından password "Auth" ... ile yanıt verir. 'Auth' belirteci isteğin tanımlayıcısını yineler ve eşleşmelidir, aksi halde yanıt yok sayılır ve istemci bekler.

Bedel, artık size ait olan bir durum makinesidir: bağlantı sırası, istemci yeniden başlatmaları ve ana makinedeki diğer kullanıcıların erişmemesi gereken yerel soket. Satın aldığınız şey çalışma anında sağlanan bir kimlik bilgisidir; diskte dosya ve askıda kalabilecek bir istem yoktur. Yığınınızda başka hiçbir şey bu protokolü konuşmuyorsa, bu yol bakımı gereken bir bileşen ekler.

Kimlik bilgisi sorunu gibi görünen arızalar

Hiç tamamlanmayan bir TLS el sıkışması veya bir VERIFY ERROR: depth=0, error=certificate signature failure, güven sorunudur ve herhangi bir kullanıcı adı okunmadan önce olur. UDP dinleyicisine yönelen proto tcp istemci de aynı yerde başarısız olur: paketler asla kimlik doğrulama aşamasına ulaşmaz, bu yüzden her parola ilişkilendirme nedeniyle yanlış görünür. Kimlik bilgisi gönderilmeden önce sertifika doğrulamasını açık tutun; tanıdık bir istem parolayı kimin aldığı hakkında hiçbir şey söylemez. Kimlik bilgisine dokunmadan önce sertifika zincirini, ortak adı ve taşımayı denetleyin.

Profili birleştiren betikteki shell hataları diğer sahte izdir. [ ! -f "$file" ] içinde eksik boşluk command not found üretir, betik erken durur, profil hiç yeniden oluşturulmaz ve istemci öncekiyle başlar. O hata shell'e aittir, kimlik doğrulamaya değil, ve parolayı kaç kez yeniden yazarsanız yazın onu silmez.

Bu akıştaki her istem bu kimlik bilgisi değildir. Özel anahtar parolası, HTTP proxy oturum açması ve hizmet parolası farklı aşamalarda sorulan üç farklı sırdır ve anahtar parolası genellikle auth-user-pass yerine istemci veya bir aracı tarafından işlenir. İstem TLS oturumu kurulmadan önce görünürse yanlış soruyu yanıtlıyorsunuzdur ve hiçbir hesap sıfırlama yardımcı olmaz. Yanlış istem dışlandığında kalan denetimler en erken katmandan başlar:

• Son kimlik bilgisi satırını değil ilk protokol hatasını okuyun: TLS, sonra kimlik doğrulama, sonra push.
• Dosyanın iki satır olduğunu, satır başı içermediğini ve mutlak bir yolla belirtildiğini doğrulayın.
• Profilin ve komut satırının yönerge konusunda çelişmediğini doğrulayın.
• "Kimlik bilgileri kabul edildi" ile "trafik akıyor"u ayırın - yönlendirme ve DNS daha sonraki katmandır.

İstemci push aşamasına ulaştığında kimlik bilgilerine bakmayı bırakın ve sunucunun gönderdiği rotaları ve DNS sunucularını okumaya başlayın. O bir sonraki sorundur ve az önce düzelttiğiniz parolayla hiçbir ilgisi yoktur.