VPN üzerinden uzak SSH: tünelin yapmadığı şey

Bir VPN, bir SSH sunucusuna özel bir yol verir ve 22 numaralı bağlantı noktasında genel bir dinleyici gereksinimini ortadan kaldırır. Ana makineyi doğrulamaz, kullanıcıyı yetkilendirmez ve hangi hesapların oturum açabileceğine karar vermez. Bu hâlâ SSH'nin işidir. Sunucuya ulaşmanın doğru yolu VPN mi, üç koşula bağlıdır ve tünel olası yanıtlardan yalnızca biridir.

Tünel neyi değiştirir, SSH neye hâlâ karar verir

Tünel erişilebilirliği değiştirir: hangi adreslere ve nereden ulaşılabileceğini. TCP bağlantısı kurulduktan sonra olanları değiştirmez; orada sunucu bir ana makine anahtarı sunar ve kullanıcı kimliği ister.

İki katmanı kafanızda ve belgelerinizde ayrı tutun. Bir VPN oturumu, ağı kimin kullanabileceğini kanıtlar. Hedefte hangi hesapların olduğu hakkında hiçbir şey söylemez ve erişilebilen her makineye giriş izni değildir.

Başarısızlık biçimleri de ayrıdır ve bu ayrımı bir olay sırasında yararlı kılan tam olarak budur.

Erişim modelini belirleyen üç koşul

Birincisi, sunucuya ağınızın dışındaki kişilerin erişmesi gerekiyor mu? Gerekmiyorsa, özel bir yol artı bir bastion ya da mesh daha küçük tasarımdır. İkincisi, istemci kitlesi VPN istemcisini gerçekten çalıştırabiliyor mu, kısıtlamalı yönetilen cihazlardakiler dahil?

Üçüncüsü, hizmet bazında mı yoksa kullanıcı bazında mı kontrol gerekiyor? VPN ağ erişimi verir; SSH hesap erişimi verir. Gereksinim bir yüklenicinin tek bir ana makineye ulaşması ve başka hiçbir şeye ulaşmaması ise, bu bir yetkilendirme gereksinimidir ve tünel tek başına bunu ifade edemez.

Bu üçünü yanıtlayın, model kendini seçer. Atlarsanız, istemci dağıtımından kaçınmak için SSH'yi genel olarak açık bırakırsınız.

SSH'yi suçlamadan önce özel yolu doğrulayın

Onaylı VPN'e bağlanın ve hedefin belgelenmiş özel adını ya da adresini kullanın. Ardından seçilen rotayı, ağ geçidinin iznini ve istemciye dönüş yolunu denetleyin. Doğru çözülen bir ad, adresin amaçlanan tünelden gittiğinin kanıtı değildir, çünkü çakışan yerel ve uzak önekler isteği tamamen başka bir yere gönderebilir. Bu ayrımı runbook'a yazmakta yarar var.

Bağlantı hiç kurulmuyorsa, sunucunun beklediğiniz arayüzde dinlediğini ve ana makine güvenlik duvarının gerçekten gördüğü kaynağa izin verdiğini doğrulayın. Ağ geçidindeki bir NAT bu kaynağı yeniden yazabilir, bu yüzden istemcinin tünel adresi için yazılmış bir izin listesi hiçbir zaman eşleşmeyebilir.

Bu uyumsuzluk, bir VPN üzerinden en sık görülen kendi kendine açılan SSH arızasıdır.

Birleşik hatayı değil, başarısızlık aşamasını okuyun

Üç aşama üç farklı ileti üretir ve bunlardan yalnızca biri kimlik bilgileriyle ilgilidir.

VPN ve SSH kimlik bilgilerini birlikte sıfırlamak yerine tam hatayı ve sunucunun kendi günlüğünü kullanın. İkisini birlikte sıfırlamak, beş dakikalık bir tanılamanın iki günlük bir kimlik olayına dönüşme biçimidir.

Ayrıntılı çıktı hangi aşamaya geldiğinizi gösterir:

ssh -vv [email protected]

Ana makine anahtarlarını ve yetkilendirmeyi koruyun

Ana makine anahtarını amaçlanan güvenilir süreçle doğrulayın, özellikle bir sunucu değişiminden sonra. Beklenmedik bir anahtar değişti uyarısı, yalnızca VPN bağlandı diye göz ardı etmemeniz gereken iletidir, çünkü özel bir tünel hedefi sandığınız makine yapmaz. Parmak izini bağlantıdan bağımsız olarak güvendiğiniz bir kaynakla karşılaştırın.

Sunucu tarafında, hesabın yetkili olduğunu ve yapılandırdığınız kimlik doğrulama yönteminin sunulan yöntem olduğunu doğrulayın. Var olan ama yok sayılan bir anahtar genellikle bir izin ya da yapılandırma sorunudur, ağ sorunu değil.

Hizmet erişimini gereken kimliklerle sınırlayın ve ağ değişiklikleri için yetkili bir kurtarma yolu bulundurun.