Kaynak Bağlantı Noktası Kuralı SSH Yollarınızdan Birini Neden Bozar

"sport 22" eşleşmesi bir yanıtın hangi SSH girişine ait olduğunu söylemez. İlke kuralını yalnızca WAN'a özel tek bir tablo yerine yönetim akışına sınırlayın.

Tek bir ana bilgisayarda iki yönetim girişi, tek bir hizmet bağlantı noktası ve ikisine de yardımcı olması gereken bir ilke kuralı. Kural kaynak bağlantı noktası 22 ile eşleşir, aramayı yalnızca WAN varsayılanını bilen bir tabloya gönderir ve doğrudan giriş çalışmaya devam ederken VPN girişi yeni oturum açmalara yanıt vermeyi bırakır. Seçici doğru okunduğunda bunların hiçbiri gizemli değildir. Kaynak bağlantı noktası bir hizmeti tanımlar, bir bağlantının geldiği yolu değil.

İki giriş, tek hizmet bağlantı noktası

Ana bilgisayarın LAN tarafında bir adresi ve bir VPN adresi vardır ve sshd ikisinde de dinler. Bu nedenle doğrudan oturum ile tünel oturumu hizmet bağlantı noktasını paylaşır ve yalnızca bağlantıyı hangi yerel adresin aldığı bakımından farklılaşır.

Bu fark yanıt yolunu seçmeye yeter ve bağlantı noktasına dayalı bir kuralın attığı fark tam olarak budur. İki oturum da kaynak bağlantı noktası 22 olan yanıtlar üretir, bu yüzden o bağlantı noktasıyla eşleşen bir kural onları ayıramaz. Her iki aramayı da aynı tabloya gönderir ve biri uygun olmayan bir yanıt alır. Düzeltme, gerçekten farklılaşan niteliği eşleştirmektir.

Her girişe kendi bağlantı noktasını vermek de işe yarardı ve bunu bir gereklilik olarak görmek SSH'ın özelliği değil, tasarım tercihidir.

Kuralı okuyun, sonra tabloyu

İlke kuralı sıralı bir seçicidir ve kullanılabilir bir yanıt döndüren ilk kural aramayı bitirir. Listeyi sırayla okuyun ve hangi kuralın kazanabileceğine dikkat edin.

Sonra o kuralın işaret ettiği tabloyu okuyun, çünkü başarıyla çözülen bir kural faydalı biçimde çözülen bir kural değildir. Yalnızca varsayılan rota içeren bir tablo, VPN kaynaklı yanıtı WAN arabirimi üzerinden dışarı gönderir. Sonraki bir tablodaki daha belirgin rota hiçbir zaman incelenmez ve bu yüzden ikinci bir tablo eklemek çoğu zaman hiçbir şeyi değiştirmez. İncelenmesi gereken, seçilen tablodur.

ip -4 rule show
ip route show table 100
ip route show table main

Bu iki çıktı birlikte sonucu açıklar; her biri tek başına yanlış bir sonuca davet eder.

Kuralı kastettiğiniz akışla sınırlayın

İki girişi ayıran nitelik yerel kaynak adresidir. Bu adresle eşleşen bir kural yalnızca tünel oturumlarını özel tabloya gönderir ve doğrudan oturumları ana tabloda bırakır.

Bu kural, özel rotayı ve o alt ağın dönüş yolunu içeren bir tabloyla eşleştirilmelidir. İkisini de ana bilgisayardaki her hizmete değil, yönetim trafiğine sınırlayın. O adresten gelen tüm trafiği yakalayan bir kural, ana bilgisayarın oradan gönderdiği her şeyi de yönlendirir. Burada dar olan akıllı olanı yener, çünkü bir sonraki kişinin bunu okuması gerekir.

sudo ip rule add from 10.90.0.1 lookup 100 priority 100
sudo ip route add 10.90.0.0/24 dev wg0 table 100
ip route get 10.90.5.20 from 10.90.0.1

İki giriş tek bir yerel adrese çevrilirse bu ayrım ortadan kalkar ve tasarımın bunun yerine bağlantıyı bilen bir duruma ihtiyacı olur.

Dinleyiciyi, izni ve yanıt seçimini ayrı tutun

Bir oturum çalışmadan önce üç ayrı şeyin doğru olması gerekir: adres var, hizmet onu dinliyor ve yanıt dönüş yolunu buluyor. Rota değişikliği yalnızca üçüncüsünü düzeltir.

Dinleyici yapılandırması kendi dosyası ve kendi yeniden yüklemesidir ve birden çok dinleme adresi normaldir. Kimlik doğrulama yine üçüncü bir karardır ve yönlendirme istisnası kimseye erişim vermez. Ana bilgisayar anahtarı doğrulamasını, hesap kimlik doğrulamasını ve kaynak kısıtlamalarını iki girişte de koruyun ve tek bir yönetim yolunun çalışması için tünelin diğer denetimlerini zayıflatma dürtüsüne karşı koyun.

Değiştirdiğiniz yola bağlı olmayan bir kurtarma kanalı tutun, çünkü buradaki bir hata düzeltmenin kendisini kilitler.

Bunu eski değil yeni bir oturumla kanıtlayın

Kurulmuş bir terminal hiçbir şey kanıtlamaz, çünkü değişiklikten önce kabul edilmiştir. Amaçlanan her girişten yeni bir oturum açın.

ss -ltnp | grep ':22'
sudo sshd -T | grep -i listenaddress
ssh -v [email protected] true
sudo journalctl -u ssh -n 30

Sonra VPN yeniden bağlanmasını yineleyin ve tekrar deneyin, çünkü yeniden bağlanmayı atlatan bir rota, yeniden bağlanmanın boşalttığı bir tabloya eklenmiş rota ile aynı değildir. Reddedilen kaynakları izin verilenlerden ayrı gözlemleyin, böylece engellenen bir deneme çalışan bir oturumun arkasına saklanmaz. Yerel adresi, kuralı ve tabloyu sonucun yanına kaydedin. Bunun yerine bağlantı noktalarını bölerseniz, bunu SSH'ın sınırı değil, operasyonel bir karar olarak kaydedin.

İlgili makaleler