Ana makine giden VPN kullandığında yerel SSH'ı koruyun

Küçük bir Linux sunucusu barındırdığı uygulama için giden bir VPN kullanıyor ve yönetici yine de yan masadan SSH ile ona ulaşmak istiyor. Bu makul bir gereksinimdir ve genellikle ne bağlantı noktası yönlendirmesi, ne sağlayıcı adresi ne de tünelde bir delik gerektirir. Gereken şey, VPN istemcisinin yönlendirme tablosuna yaptıklarından miras alınmış değil, bilerek tasarlanmış bir yönetim yoludur.

Aşağıdaki adımlar yöneticinin aynı LAN üzerinde olduğunu varsayar.Uzaktan yönetim, farklı bir yanıtı olan farklı bir sorundur.

SSH'ı yöneticilerin kullandığı adrese bağlayın

Dinleyiciden başlayın.ss -ltnp | grep :22 sshd'nin neye bağlı olduğunu gösterir ve 0.0.0.0 üzerindeki dinleyici tünel dahil her arayüzden bağlantı kabul eder. LAN adresine bağlanmak daha dardır ve niyeti görünür kılar:ListenAddress 192.168.10.20 içinde sshd_config, ardından bir yapılandırma testi ve yeniden yükleme gelir. O adresteki bir yazım hatası joker karakterden daha görünürdür, çünkü adres yoksa sshd başlamayı reddeder.

Ana makine anahtarı denetimini ve kullanıcı başına kimlik doğrulamayı olduğu gibi bırakın. „Sadece yerel ağ“ bir kimlik doğrulama yöntemi değildir ve rota kısa olduğu için anahtar doğrulamasını atlayan bir yönetim kanalı, kötüye kullanım bekleyen bir kanaldır. Bir DHCP rezervasyonu veya statik adres, hedefi sunucunun genel kimliğine dönüştürmeden öngörülebilir kılar.

LAN rotasını tünelin dışında tutun

192.168.10.0/24 üzerinde adresi olan bir ana makinenin o önek için bağlı bir rotası vardır ve aynı tablodaki daha özel bir rota VPN'in varsayılanını yener. Bu yüzden tünel yükseldiğinde yerel SSH genellikle kendi kendine çalışmaya devam eder. Varsaymak yerine doğrulayın:ip route get 192.168.10.50 çekirdeğin kullanacağı arayüzü ve kaynak adresi adlandırır ve yanıt tünel değil LAN aygıtı olmalıdır. Denetimi yöneticinin makinesinden de tekrarlayın, çünkü paketlerin hiç ulaşıp ulaşmayacağına onun kendi tablosu karar verir. Aynı kablodaki iki ana makine hangi yönün erişilebilir olduğu konusunda anlaşamayabilir.

Varsayım iki yerde kırılır. İlke tabanlı bir yönlendirme kuralı, trafiği ana tabloya bakılmadan önce varsayılanı tünele işaret eden bir tabloya gönderebilir. Kilitleme veya kill switch özelliği olan bir VPN istemcisi de yönlendirme tablosunun ne dediğine bakmaksızın tünele girmeyen trafiği engelleyebilir.

Yönlendirilmiş yönetim VLAN'ları diğer durumdur. Yönetici yerel yönlendiricinin arkasında 192.168.50.0/24 üzerinde oturuyorsa, sunucunun o önek için 192.168.10.1 üzerinden açık bir rotaya ihtiyacı vardır ve bu rota yeniden bağlanmayı atlatmalıdır. İstisnayı yönetim önekiyle sınırlı tutun; özel aralıklar için geniş bir istisna tünelin amacını bozar.

Güvenlik duvarı istisnasını kural kadar dar yapın

Ana makine bir güvenlik duvarı çalıştırıyorsa SSH'a yalnızca yönetim kaynağından ve yalnızca LAN arayüzünde izin verin. 22 numaralı bağlantı noktasına her yerden izin veren bir kural gereksinimden daha geniştir ve incelemede savunulması daha zordur. nftables ana makinesinde kural, arayüz ve kaynağın eşleştiği giriş zincirine aittir; iptables ana makinesinde eşdeğeri şu üzerindeki iki eşleşmedir:-i ve -s. Kurala hizmet ettiği yönetici grubuyla yorum yazın, böylece bir sonraki denetim 22 numaralı bağlantı noktasının neden açık olduğunu tahmin etmek zorunda kalmasın.

VPN istemcisinin kendi filtresini de denetleyin. Bazı istemciler tasarım gereği yerel trafiği düşüren kurallar kurar ve istemci düzeyindeki bir düşürmenin üzerindeki doğru güvenlik duvarı kuralı hiçbir şeyi değiştirmez. Ana makinenin güvenlik duvarını düzenlemeden önce istemcinin yapılandırmasını okuyun, çünkü seri haldeki iki filtre ikisine de benzemeyen bir arıza üretir.

Her iki durumu test edin

Testi iki kez çalıştırın: bir kez tünel bağlıyken, bir kez de bağlantı kesilmişken. Her durumda dinleyiciyi, rotayı ve yöneticinin makinesinden gerçek bir SSH oturum açmasını doğrulayın. Yalnızca tünel ayaktayken çalışan bir yol yerel bir yönetim yolu değildir; bu bir rastlantıdır.

Ardından bir SSH oturumu açıkken tüneli yeniden başlatın. Hayatta kalan oturum yönlendirmenin kararlı olduğunu kanıtlar; düşen oturum istemcinin yeniden bağlanırken rotaları veya filtreleri yeniden yazdığını söyler, bunu bir olaydan önce bilmek olay sırasında bilmekten iyidir.

Test ettiğiniz kaynak adresi kaydedin, çünkü 192.168.10.50 için yazılmış bir kural yöneticinin dizüstü bilgisayarı başka bir alt ağa taşındığında sessizce başarısız olur.

Kurtarma yolunu runbook'a yazın

Giden VPN yerel yolu bozarsa ne olacağına şimdi karar verin. Konsol erişimi, ikinci bir yönetim adresi veya istemciyi durdurmak için belgelenmiş bir prosedür hepsi meşru yanıtlardır ve bunlardan herhangi biri, oturum açmanız gerektiği anda sorunu keşfetmekten daha iyidir. Sunucu uzaktaysa yerel yol yoktur ve doğru tasarım, açıkta bırakılmış bir genel bağlantı noktası yerine ayrı onaylanmış bir uzaktan erişim yolu veya bir bastion'dır.

Belgelerde iki rolü ayrı tutun: yakındaki yönetici için yerel SSH ve uygulamanın trafiği için giden tünel. Bu roller yazıya döküldüğünde, herhangi birindeki gelecekteki bir değişikliğin denetleneceği belirgin bir yer olur ve bir sonraki kişi VPN'li bir sunucunun neden hâlâ LAN adresinde yanıt verdiğini yeniden keşfetmek zorunda kalmaz.