Android chroot VPN: tünel neden çalışır ve uygulamalar neden onu yok sayar

Telefonda chroot altında çalışan bir Linux dağıtımı kurarsınız, içine bir VPN istemcisi yüklersiniz ve kabuk tünelin tamamlandığını duyurur. Sonra tarayıcıya geçersiniz ve trafik hiçbir şey olmamış gibi mobil veriden çıkar. Ya da tam tersi: istemci, Android'in gerçekten kullandığı ad alanına varsayılan bir rota eklediği için telefondaki her uygulama bağlantısını kaybeder. Bu iki belirti aynı eksik parçadan gelir ve ikisi de VPN istemcisindeki bir hata değildir.

Kabuk bağlı diyor, uygulamalar aynı fikirde değil

İlk sonuç yaygın olanıdır. Chroot'tan açılan bir kullanıcı alanı tüneli el sıkışmasını tamamlayabilir, istatistiklerini yazdırabilir ve aynı kabuğun ürettiği trafiği taşıyabilir, ancak Android uygulamaları telefonun varsayılan ağını kullanmaya devam eder. Hiçbir şey onları yakalamıyor, çünkü hiçbir şey Android'e bir VPN olduğunu söylemedi.

İkinci sonuç tehlikeli olanıdır. Chroot, Android'in ağ ad alanını paylaşıyorsa, ki varsayılan olarak paylaşır, yeterli ayrıcalığa sahip bir süreç tüm telefonu etkileyen rotalar ve bir TUN arayüzü ekleyebilir. O zaman tünel her uygulama için çalışır, yönlendirmeyi düşünmediğiniz uygulamalar dahil, ve telefonun bağlantısı artık yaşam döngüsü yönetimi, bağlantı göstergesi ve her zaman açık politikası olmayan bir arka plan servisine bağlıdır.

Hangisini aldığınız tek bir komutla belirlenebilir. Chroot içindeki ip route ile aynı komutu dışarıdaki bir Android kabuğundan karşılaştırın. Aynı çıktı, chroot'un ana makinenin ad alanında olduğu anlamına gelir: yaptığı her ağ değişikliği tüm telefonu kapsar. Farklı çıktı, başlatıcının onun için bir ad alanı oluşturduğu ve tünelinin Android'e yapısı gereği görünmez olduğu anlamına gelir.

Chroot neyi değiştirdi, neyi değiştirmedi

Chroot sistem çağrısı tek bir şey yapar: yol adlarının çözümlenmesinde kullanılan dizini değiştirir. Kılavuz sayfası bunun bir güvenlik sınırı olmadığını açıkça söyler ve arayüzler, rotalar veya VPN durumu hakkında hiçbir şey söylemez. İnsanların bir Linux konteynerinden beklediği her şey — özel bir ağ yığını, filtrelenmiş bir dosya sistemi, kaynak sınırları — başlatıcının kullanmış olabileceği ya da olmayabileceği başka mekanizmalardan gelir.

Bu yüzden chroot'un bir VPN'i izole ettiği iddiaları genellikle yanlış soruyu yanıtlar. İlgili soru, sürecin hangi ad alanında çalıştığı ve hangi SELinux alanıyla sınırlandığıdır; ikisi de nasıl başlatıldığının özellikleridir, chroot kelimesinin değil.

TUN üç şey ister ve aygıt düğümü bunlardan yalnızca biridir

Geleneksel bir kullanıcı alanı tüneli açabileceği bir TUN aygıtı, o aygıt için çekirdek desteği ve arayüz ile rotaları yapılandırma izni ister. Bunlar ayrı gereksinimlerdir ve /dev altında bir yol adı oluşturmak bunların hiçbirini tek başına karşılamaz:

ls -l /dev/net/tun
ip tuntap add dev tun0 mode tun

Android'de çekirdek genellikle TUN desteğini derlenmiş olarak içerir, çünkü platformun kendi VPN hizmeti onu kullanır, ancak bu sizin sürecinizin onu kullanabileceği anlamına gelmez. Arayüz yapılandırması ağ yönetimi yeteneği gerektirir ve SELinux, sürecin aygıt düğümüne hiç ulaşıp ulaşamayacağına karar verir. Ret, belirgin bir nedeni olmayan bir izin hatası gibi görünür ve cevap denetim kaydındadır:

dmesg | grep avc
logcat -d | grep "avc: denied"

Root bunu çözmez. SELinux, uid 0 olarak çalışan süreçleri diğerleri gibi sınırlar, bu yüzden root kabuğundan başlatılan bir chroot bile gördüğü bir aygıt için reddedilebilir. Eski bir yükleyicinin çalışması için zorlamayı kapatmak, tünelin çok ötesinde sonuçları olan bir tüm telefon kararıdır ve eski bir ikili dosyanın onarımı değildir.

Android uygulamaları tünelinizi neden yok sayar

Android'in desteklediği model, platformun VPN hizmeti üzerinden kaydolan, kullanıcıdan bir kez onay isteyen ve tüneli için bir dosya tanımlayıcısı alan bir VPN uygulamasıdır. Platform daha sonra trafiği o tanımlayıcıya yönlendirir ve kullanıcının veya yöneticinin seçtiği uygulama kapsamını uygular; bu yüzden aynı mekanizma uygulama başına, profil başına olabilir ve her zaman açık ile VPN olmadan engelle ayarlarıyla birleştirilebilir. Android VPN geliştirme kılavuzu bu el sıkışmayı anlatır ve kilit nokta bunun bir kayıt olduğu, bir yönlendirme hilesi olmadığıdır.

Chroot içindeki bir arka plan servisi asla kaydolmaz. Onay iletişim kutusu yok, durum çubuğunda anahtar simgesi yok, uygulama başına dahil etme veya hariç tutma listesi yok ve her zaman açık politikasına katılım yok. Bu yüzden uygulamalar varsayılan ağı kullanmaya devam eder ve tünel yalnızca kabuğun kendisinin gönderdiğini taşır.

Diğer yöne gitmek de yardımcı olmaz. Rotaları ana makinenin ad alanına itmek her şeyi yakalar, platformun yerel kalmasını beklediği trafik dahil, ve bunu uygulama başına kontrol olmadan ve kullanıcının görme veya geri alma imkânı olmadan yapar. Chroot servisinin yalnızca tek bir uygulama için trafik yönlendirdiği bir ara ayar yoktur.

İkili uyumluluk ayrı bir duvardır

Ağ tarafı ilginç olsa bile çalıştırılabilir dosyanın kendi gereksinimleri vardır: CPU mimarisi, dinamik yükleyici, C kitaplığı ve beklediği çekirdek olanakları. Android glibc yerine bionic kullanır ve masaüstü dağıtımı için derlenmiş eski bir ikili dosya, aygıtta artık bulunmayan kitaplıklara ihtiyaç duyabilir.

Bir kitaplık dosyası adını yeni bir sürüme sembolik olarak bağlamak ABI uyumluluğu yaratmaz ve on yıllık bir paketten arşivlenmiş kriptografik kitaplık bakımı yapılan bir bileşen değildir. Plan buna bağlıysa plan, telefonda ağ ayrıcalıklarıyla bakımsız kod çalıştırmaktır.

Android bağlamında kanıtlayın ve sonra temizleyin

Gerçekten önemsediğiniz şeyi, önemli olan taraftan test edin: belirli uygulamayı açın, belirli özel hedefe ulaşın, hangi çözümleyicinin yanıt verdiğini doğrulayın, sonra tüneli kesin ve belgelenen davranışı doğrulayın. Chroot içindeki bir terminalden alınan sonuç, yalnızca o terminalin yürütme bağlamı hakkında kanıttır, fazlası değil.

Deneyler sırasında ana makine rotalarını değiştirdiyseniz bunları geri alın ve neyi değiştirdiğinizi yazın. Sonra telefonda her zaman açık bir VPN yapılandırılmış mı kontrol edin, çünkü geride bir kural bırakan eski bir deney aylar sonra platform arızası gibi görünebilir.

Gerçek bir uzaktan erişim ihtiyacı için hizmetin desteklediği istemciyi veya onaylanmış bir ağ geçidi tasarımını kullanın. Sorulmaya değer soru, root'lu bir yükleyicinin çalıştırılıp çalıştırılamayacağı değil, desteklenen bir uygulamanın ihtiyacınız olan uygulamaları amaçladığınız sınırın ötesine taşıyıp taşımadığıdır; aygıtta sahipsiz ayrıcalıklı değişiklikler bırakmadan.