NGINX akış aktarıcısı üzerinden SSH'ı bozmadan geçirmek

PROXY başlığı onu bekleyen bir alıcıya yönelik mesajdır ve proxy'lenmiş bir DNS kaydı TCP aktarıcısı değildir. Kenarı ve üst akışı ayrı ayrı düzeltin.

Bir aktarıcı üzerinden genel SSH, birbiriyle ilgisiz iki sınırda başarısız olur ve birini düzeltmek genellikle diğerini ortaya çıkarır. Ya kenar akış taşımak yerine HTTP yanıtı döndürür ya da aktarıcı, arka ucun okumayı hiç kabul etmediği bir başlığı öne ekler. Hangi duruma baktığınızı üç koşul belirler: genel kaydın gerçekte neyi işaret ettiği, akış bloğunun yukarıya ne gönderdiği ve SSH istemcisinin hangi adı doğruladığı. Bunları bu sırayla ele alın.

İki sınır, iki belirti

Kenardaki arıza, SSH başlığının olması gereken yere bir HTTP durum sayfası gelmesi gibi görünür. Bağlantı TCP düzeyinde tamamlanır ve ilk baytlar bir web sunucusuna ait metindir. Bu bir protokol uyuşmazlığıdır, kaybolmuş paket değil. Ayrıca kenarın o ad için bilerek başka bir şey sunduğunu söyler.

Üst akıştaki arıza farklı görünür. Bağlantı sshd'ye ulaşır, sshd beklediği kimlik doğrulama alışverişi olmayan baytları okur ve oturum hiç anahtar sunmadan ölür veya takılır.

İkisini karıştırmak kolaydır çünkü ikisi de bağlanıp sonra başarısız olan bir istemci üretir. Onları ayıran şey aldığınız ilk protokol yanıtıdır, bu yüzden o yanıt kayda girmelidir.

PROXY başlığı bir mesajdır, anahtar değil

Akış modülünde proxy_protocol on, NGINX'e yükün önünde üst akışa doğru bir PROXY protokol başlığı yazmasını söyler. Bu TCP proxy'sini etkinleştirmez ve SSH şifrelemesiyle hiçbir ilgisi yoktur. Alıcıya hitaben yazılmış bir nottur. Alıcı bunu okuyamazsa akışın başında çöp hâline gelir.

Alıcı hizmet bu başlığı bilerek tüketmelidir. Normal bir sshd bağlantıdaki ilk baytlar olarak SSH kimlik alışverişini bekler, bu yüzden beklenmeyen bir önsöz el sıkışmayı bozuk bir sunucu gibi görünecek şekilde bozar.

stream {
    server {
        listen 2222;
        proxy_pass 10.77.0.20:22;
    }
}

Bu parça, VPN üzerinden erişilebilen bir arka uç için çalışan aktarıcının tamamıdır. Hiçbir PROXY yönergesi görünmez çünkü alıcı bu protokolü konuşmaz ve bu yokluk bir ihmal değil, karardır.

İki yönü de ayırın. proxy_protocol ayarını listen satırına koymak, NGINX'in kendi istemcisinin başlığı önce göndermesini beklediği anlamına gelir; bunu sıradan bir SSH istemcisi için etkinleştirmek, insanların genellikle çözmeye çalıştığı sorunun tam tersini üretir.

Genel ana makine adı gerçekte neye ulaşır

Bir SSH oturumunda HTTP 400 sayfası kenar hakkında kanıttır. Yolda bir şey HTTP konuşuyor ve arka uçta anahtar veya hesap üzerinde yapılan hiçbir çalışma bunu değiştirmez. Kenar netleşene kadar arka ucu değiştirmeyi bırakın.

Cloudflare'in olağan proxy'lenmiş kaydı, desteklenen HTTP ve HTTPS trafiğini tanımlı bağlantı noktalarında taşır. Bir ana makine adı için proxy'yi açmak genel bir TCP aktarıcısı oluşturmaz ve SSH'ı 443 numaralı bağlantı noktasına taşımak onu HTTPS yapmaz.

İki uygulanabilir yön vardır. Yalnızca DNS kaydı kendi TCP aktarıcınıza işaret edebilir, bu da maruz kalma kararını sizin elinize bırakır. Alternatif olarak, SSH taşımasını açıkça belgeleyen, kendi kaynak, istemci ve erişim yapılandırmasına sahip bir ürün kullanın.

Hangisini seçerseniz seçin, aktarıcı yine de arka uca bir VPN yolu, izin verilmiş bir bağlantı ve bir dönüş yolu gerektirir. Yol, genel taraf çalıştığı için isteğe bağlı değildir.

SSH kimliğini bir takma ad aracılığıyla sabit tutun

Kullanıcılar genellikle mevcut ana makine adlarını yazmayı sürdürmek ister. SSH yapılandırmasındaki bir takma ad bunu aktarıcıda hiçbir şeyi değiştirmeden yapabilir ve değişikliği ait olduğu istemci tarafında tutar.

Host git.example.com
    HostName ssh-entry.example.net
    Port 2222
    User git
    HostKeyAlias git.example.com

HostKeyAlias olmadan OpenSSH, ana makine anahtarını bağlandığı adın altında arar, bu yüzden giriş kayar ve her kullanıcı ilk kullanımda anahtarın değiştiğine dair bir uyarı görür. Takma adı ayarlamak, bağlantı hâlâ aktarıcıya giderken known-hosts girişlerini sabit tutar.

Bu takma ad yalnızca SSH tabanlı uzak depolar için geçerlidir. HTTPS Git URL'si ona başvurmaz ve tipik uzak URL gerçekten hazırladığınız taşıma ile eşleşmelidir.

Yapmamanız gereken şey, uyarı kaybolsun diye ana makine anahtarı doğrulamasını kapatmaktır. Bu, yönlendirme onarımının hiç dokunmayı istemediği bir korumayı kaldırır ve kozmetik bir rahatsızlığı gerçek bir maruziyete dönüştürür.

Her atlamayı ayrı ayrı doğrulayın

Genel dinleyiciyi tek başına test edin, sonra aktarıcı ana makinesinden aktarıcı-arka uç bağlantısını ve ancak ondan sonra istemciyi uçtan uca test edin. Bu üç testin her biri farklı bir katmanı eler. Birini atlamak, kalan iki sonucun yorumlanamayacağı anlamına gelir. Üç gözlem, arızanın yaşayabileceği üç yer.

Her sonuçla birlikte hedef adresi, bağlantı noktasını ve ilk protokol baytlarını saklayın. Bu üçlü, kenar hatasını VPN yönlendirme sorunundan ve SSH kimlik doğrulama hatasından ayırır; onarım ile tahmin arasındaki fark da budur.

Son olarak, amaçlanan maruziyeti belgeleyin. SSH'ı özel bir arka uca taşıyan bir TCP aktarıcısı, genel çevrede bilerek açılmış bir kapıdır ve diğer her gelen hizmet gibi aynı incelemeyi hak eder.

İlgili makaleler