Android'in tek VPN kuralı barındırılan bir SSH sunucusunu engellemez

Bu inanç, gerçekmiş gibi ele alınacak kadar yaygın: Android yalnızca bir VPN'e izin verir, dolayısıyla telefonda çalışan bir SSH sunucusu o tünel üzerinden çalışamaz. İlk yarı doğru ve sonuç ondan çıkmıyor. Platform sınırı, kaç uygulamanın VPN hizmetinin yerini tutabileceğiyle ilgilidir; kaç soketin var olabileceği ya da kimin telefona bağlanabileceğiyle değil. Dinleyen sokete sahip bir SSH daemon'u sıradan portlu sıradan bir uygulamadır ve tünel, trafiğinin gidebileceği yollardan biridir.

Tek VPN kuralı gerçekte neyi kısıtlar

VpnService tek yerli bir kaynaktır. Bir uygulama tünel kurduğunda cihazın VPN'i o olur ve tünel kurmaya çalışan ikinci uygulama, birincisi kaybolana kadar reddedilir. Bu, tünelin sahipliğine dair bir kuraldır ve iki VPN istemcisinin neden aynı anda çalışamadığını açıklar.

Dinleyen soketler hakkında hiçbir şey söylemez. SSH sunucusu VpnService'i çağırmaz, paketleri yakalamaz ve o yer için yarışmaz. Bir portu bağlar ve bağlantıları kabul eder; VPN hiç kurulmamışken de aynı şeyi yapardı. Yani efsane, tünel sağlayıcılarına ilişkin sınırı ağ bağlantılarına ilişkin sınırla karıştırır ve ikisi arasında hiçbir ilişki yoktur.

Dinleyici bir hedeftir, tünelin parçası değildir

Tünel var olduğunda telefonun üzerinde bir adresi, eş cihazın da o adrese bir yolu vardır. Bir şeyin yanıt verip vermediğine dinleyici karar verir. loopback'e bağlı bir daemon yalnızca telefondan erişilebilir; eski tünel adresine bağlı bir daemon, yeniden bağlanmadan sonra bağını koruyabilir, oysa bağlandığı adres değişmiştir.

Bağlama kuralları sıradan SSH yapılandırmasıdır: dinleme adresi ve portu ile kimin kimlik doğrulayabileceği. Android'de bu ayarlar uygulamanın kendi yapılandırmasında yaşar ve uygulama sürecinin sahibinin ayrıcalıklı portları kullanmasına izin verilmemiş olabilir, bu yüzden masaüstünde port 22'yi root olarak bağlama alışkanlığı değişmeden aktarılmaz.

ListenAddress 10.90.0.4
Port 2222
AllowUsers alice

Sonra yolun kendisindeki izin var. Giden web trafiğini memnuniyetle taşıyan bir tüketici VPN'i, istemcilerine gelen bağlantılara hiç izin vermek zorunda değildir; birçok vermez, çünkü bu bir müşteriyi diğerine maruz bırakır. Eş, telefonun tünel adresine hiçbir yerden ulaşamıyorsa sorun hizmetin politikasındadır, telefonda değil.

Yanıt yolu genellikle kırılan yerdir

Eşin telefonun tünel adresine ulaştığını ve SYN'in geldiğini varsayalım. Şimdi yanıt aynı yoldan çıkmalı ve bu, telefonun içindeki bir yönlendirme kararıdır. Yanıt varsayılan ağ olduğu için Wi-Fi üzerinden çıkarsa, eş hiç tamamlanmayan bir bağlantı görür; bu tam olarak bir güvenlik duvarı gibi görünür.

Android bunu masaüstünden daha karmaşık yapar çünkü varsayılan ağ süreç başına seçilir ve VPN uygulamasının politikasıyla değiştirilebilir. Bir VPN istemcisi yalnızca izin verilen uygulamaların listesini yönlendirebilir, bu yüzden bu listenin dışındaki bir sunucu uygulaması yanıtları için fiziksel ağı kullanmaya devam ederken eş bunları tünel üzerinden bekler.

Bir uygulama ayrıca kendi soketlerini belirli bir ağa bağlayabilir ve bu, varsayılanı geçersiz kılar. Bir hizmetin bir adresten erişilebilir, diğerinden erişilemez olduğuna dair bir rapor okuduğunuzda, genellikle arkasındaki mekanizma budur.

VPN'i atlamak gelen hizmeti onarmaz

Popüler çözüm, SSH uygulamasını VPN'den hariç tutmak ve trafiğinin artık yönlendirilmemesini sağlamak, ters problemin düzeltmesidir. Giden bir SSH istemcisinin taşıması tünel yüzünden sürekli kırıldığında yardımcı olur. Barındırılan bir sunucu için yanıtları eşin kullandığı tünelin dışına taşıyabilir ve bu, kısmi bir hatayı tam bir hataya dönüştürür.

Aynısı yönlendiricide genel bir port açmak için de geçerlidir. Gereksinim, yetkili tek bir cihazın VPN üzerinden telefona ulaşmasıysa, SSH'ı internete açmak farklı bir tehdit modelidir, onarım değildir.

Önce hizmetin adresine karar verin: telefonun LAN adresi, tünel adresi veya bilinçli olarak yönlendirilmiş bir uç nokta. Her birinin kendi erişilebilirlik ve maruz kalma sözleşmesi vardır ve bunları karıştırmak, küçük bir erişim sorununun kalıcı bir deliğe dönüşme yoludur.

Her seferinde tek yönü teşhis edin

Yapılandırmayı değiştirmeden önce dört olguyu yazın: eşin bağlandığı adres, telefondaki dinleyicinin durumu, onu elinde tutan uygulama ve kullanıcı bağlamı ve her yönde gözlenen yol. VPN'in SSH'ı kopardığını söyleyen bir raporda bunlardan hiçbiri yoktur ve istemci taşıma sorununu erişilemeyen bir sunucudan ayıramaz.

adb shell ip -br addr
adb shell ip route get 10.90.0.9
nc -vz 10.90.0.4 2222

Port kontrolünü telefondan değil eşten çalıştırın ve SSH istemcisinin ayrıntılı çıktısını okuyarak TCP el sıkışmasından önce mi sonra mı başarısız olduğunu görün. Hiç bağlanmayan bir soket ile reddedilen bir oturum açma, farklı aşamalar ve farklı sorumlulardır.

Hata ayıklarken ana makine anahtarı doğrulamasını ve hesap kısıtlamalarını bozmayın. Dinleyiciyi ve izin verilen kullanıcıları kısıtlamak, erişilebilir bir sunucuyu kabul edilebilir kılan şeydir; bağlantı çalışsın diye bunları gevşetmek bir sorunu daha kötüsüyle değiştirir. Android uygulamanız aynı yapılandırma adlarını izliyorsa OpenSSH sunucu başvurusu dinleme ve erişim kontrollerini kapsar.