Tek bir cihaz için ters SSH: loopback dinleyicisi mi yoksa yönlendirilmiş VPN mi?

Cihazınız operatörün NAT'ı arkasında duruyor, giden bağlantılar açabiliyor ve kimsenin erişemediği bir SSH sunucusu çalıştırıyor. Gelen istek genellikle "ona bir VPN verin" diye formüle edilir, ki bu birkaç yanıttan biridir. Kabul etmeden önce tek bir yönetim TCP bağlantı noktasına mı yoksa tüm alt ağa yönlendirilmiş bir yola mı ihtiyacınız olduğuna karar verin, çünkü bunlar farklı maruziyetleri olan farklı projelerdir.

Ters tünel dar sürüme iyi yanıt verir. Cihaz hub'ınıza bağlanır, hub'dan bir loopback bağlantı noktasında dinlemesini ister ve o bağlantı noktasını kendi SSH hizmetine geri iletir. Ardından yöneticiler dinleyiciye genel internet üzerinden değil, hub üzerinden ulaşır.

Seçimi belirleyen üç koşul

Bunları herhangi bir yapılandırmadan önce yazın. Sınırlı bir yönetim girişi ile ağ genişletmesi arasındaki sınır bunlardır ve bunları karıştırmak, beş satırlık bir tünelin sahipsiz düz bir ağa dönüşme yoludur.

İnsanların tartıştığı satır üçüncüsüdür. Bir cihazın SSH bağlantı noktasına açılan tünel komşularını ağınıza koymaz ve daha fazla yönlendirme zinciriyle öyle görünmesi sağlanmamalıdır. Gereksinim gerçekten LAN ise bunu söyleyin ve onun yerine LAN'ı tasarlayın.

Hub tarafı: sınırlı bir röle hesabı

Her cihaza genel anahtar kimlik doğrulaması olan ve etkileşimli oturumu olmayan kendi röle hesabını verin. Match o hesaba sınırlanmış blok izni küçük tutar ve özel anahtar ait olduğu yerde, cihazda kalır.

Match User relay-dev-7
    AuthenticationMethods publickey
    PubkeyAuthentication yes
    AllowTcpForwarding remote
    PermitListen 127.0.0.1:21022
    GatewayPorts no
    MaxSessions 0
    PermitTTY no
    X11Forwarding no
    AllowAgentForwarding no

MaxSessions 0 ilginç satırdır. Kabuk ve alt sistem oturumlarını reddederken cihazın ihtiyaç duyduğu yönlendirmeye izin verir, böylece çalınan bir anahtar etkileşimli oturum açmaya dönüştürülemez. PermitListen hub tarafındaki dinleyicinin adresini ve bağlantı noktasını sabitler ve GatewayPorts no onu hub'ın bulunduğu ağa açmak yerine loopback üzerinde tutar.

Etkin yapılandırmayı yeniden yüklemeden önce test edin ve bunu yaparken ikinci bir oturumu açık tutun. Match bloğun yanlışlıkla herkese uygulanması veya bir seçenek adındaki yazım hatası, sağlamlaştırdığınız kutunun dışında kendinizi kilitlemenin klasik yoludur. Çalışan yapılandırmayı dökün ve yeni yazdığınız dosyaya güvenmek yerine seçenekleri yeniden okuyun. Seçenek desteğinin yapılar arasında farklı olduğunu unutmayın, bu yüzden yeni bir sunucuda kabul edilen bir satır eski bir sunucu tarafından kolayca yok sayılabilir.

Cihaz tarafı: yüksek sesle başarısız olan yönlendirme

Cihaz bağlantıyı açar ve dinleyiciyi ister. Argümandaki iki adres -R farklı anlamlara gelir ve soldan sağa okumak hangisinin hangisi olduğunu hatırlamanın en hızlı yoludur.

ssh -NT \
    -o ExitOnForwardFailure=yes \
    -o ServerAliveInterval=30 \
    -o ServerAliveCountMax=3 \
    -R 127.0.0.1:21022:127.0.0.1:22 \
    [email protected]

Sol çift hub'ın dinlemesi gereken yerdir. Sağ çift, bir istek geldiğinde cihazın bağlandığı hedeftir ve cihazın kendi tarafından çözülür. Bunları değiştirmek, temiz biçimde yükselen ve yanlış yere yönlendiren bir tünel üretir; bu bir hatadan daha kötüdür.

ExitOnForwardFailure=yes istenen dinleyici kurulamadığında komutun çıkmasını sağlar, böylece yeniden başlatma döngüsü yarı çalışan bir oturum bırakmak yerine size gerçeği söyler. Yerel SSH hizmetinin daha sonra sağlıklı olup olmadığı hakkında hiçbir şey söylemez, bu yüzden onu bir süreç yöneticisi ve ara sıra gerçek bir bağlantı testiyle eşleştirin.

Ekstra bir atlamadan kaçınmak için loopback dinleme adresini asla joker karakterle değiştirmeyin. O tek değişiklik, bir yönetim yolu ile herkese açık erişilebilir bir bağlantı noktası arasındaki farktır ve genellikle hata ayıklama sırasında olur ve sonra kalır. Bir iş arkadaşı bağlantı noktasına hub üzerinden ulaşamıyorsa, bağlamayı genişletmek yerine atlama yapılandırmasını düzeltin. Loopback bu tasarımın tüm güvenlik argümanıdır.

Hub üzerinden yönetici erişimi

Hub'da sıradan bir hesabı olan yönetici, onun üzerinden iletilen bağlantı noktasına atlayabilir. Röle hesabı bunun için kullanılmaz ve onları ayrı tutmanın amacı da tam budur.

ssh -J [email protected] -o HostKeyAlias=device-7 \
    -p 21022 [email protected]

Cihazın ana makine anahtarını seçtiğiniz takma ad altında doğrulayın, çünkü o anahtar zincirin sonundaki cihazı tanımlar ve tünel yalnızca taşımadır. Uçtan uca oturum açma hâlâ iki ucu da kimlik doğrular; paylaşılan bir hub'da biten tünel, onu kendi başına güvenilir bir yol yapmaz.

Yaşam döngüsünün sahipliğini alın

Cihaz komutunu bir süreç yöneticisi altında tam olarak bir etkin örnek ve bilinçli olarak seçtiğiniz bir yeniden başlatma ilkesiyle çalıştırın. keepalive seçenekleri ölü bir eşi algılar; çıkmış bir süreci diriltmez.

Ardından devre dışı bırakma prosedürünü yazın. Her cihaz kendi dinleyicisine ve kendi anahtarına sahiptir, bu yüzden devreden çıkarma o hesabı iptal etmek ve o anahtarı kaldırmak demektir, tüm filonun paylaştığı bir sırrı döndürmek değil.

Son olarak loopback'in size ne verdiğini hatırlayın. Ağ maruziyetini sınırlar ve paylaşılan bir hub'daki diğer yerel kullanıcılar konusunda hiçbir şey yapmaz, bu yüzden hub'ın kendi erişim ilkesi yine de doğru olmalıdır. sshd_config başvurusu yukarıda kullanılan seçeneklerin her birini belgeler ve herhangi birini genişletmeden önce yönlendirme bölümlerini tamamen okumaya değer.