Android VPN yönlendirmesi: main tablosundan önce politika kuralları

Android'de main tablosuna eklenen bir yol her listede doğru görünür ve yine de trafiği taşımaz. Nedeni, main tablosunun birkaç seçenekten yalnızca biri olması ve ilk sırada sorulmamasıdır. Android'in ağ hizmeti, yönlendirme tablosunu hedef adresin içermediği bilgilerle seçen politika kuralları oluşturur — uygulamanın uid değeri, paket üzerindeki işaret, paketin geldiği arayüz — ve hedef araması bundan sonra, bu kuralların seçtiği tablonun içinde gerçekleşir.

Sabit sırada üç karar

Dışarı çıkan bir paket üç ayrı karar verir. Birincisi, bir politika kuralı hangi yönlendirme tablosunun geçerli olduğunu belirler. İkincisi, o tablo içindeki bir yol sonraki atlamayı ve çıkış arayüzünü belirler. Üçüncüsü, netfilter kancaları paketin hayatta kalıp kalmayacağını, değiştirilip değiştirilmeyeceğini veya yönlendirilip yönlendirilmeyeceğini belirler.

Sıra önemlidir çünkü her aşama yalnızca kendi sorusunu yanıtlayabilir. Bir paketi kabul eden güvenlik duvarı kuralı tablo seçmez ve hiçbir kuralın seçmediği bir tabloya eklenen yol etkisizdir. Android VPN'leri etrafındaki karışıklığın çoğu, üçünden birini düzeltip hiçbir değişiklik görmemekten gelir, çünkü arıza diğerindeydi.

İşaretler paketlenmiş bir alandır, sizin sahip olduğunuz bir etiket değil

Android birkaç olguyu aynı işaret değerine paketler: hangi ağın seçildiği, bir uygulamanın bir ağı açıkça seçip seçmediği, bir soketin VPN'den korunup korunmadığı ve izinlerle ilgili bitler. AOSP'nin fwmark başlığı bu yerleşimi geçerli ağaç için tanımlar ve yerleşim sürümler arasında değişen bir platform içi ayrıntıdır.

Bu yüzden Android'de bir işaret değerinin tamamını iptables -j MARK --set-mark ile yazmak tehlikelidir. Bir etiket eklemez; sistemin zaten yaptığı ağ seçimini değiştirir. Paket daha sonra farklı kurallarla eşleşir ve hangi bitlerin üzerine yazıldığına bağlı olarak VPN çalışmaya başlamış gibi ya da ilgisiz bir uygulama bağlantıyı kaybetmiş gibi görünebilir.

İşaretlere dokunmanız gerekiyorsa önce geçerli değeri okuyun ve yalnızca anladığınız bitlerin değişmesi için bir maske kullanın:

ip rule show
ip route show table all | head -40
ip route get 10.20.4.11

Bağlantı işareti, paket işaretinden ayrı bir nesnedir ve ikisi de yol değildir. İşareti yanıt paketlerinde geri yüklemek, çıkışta tablo seçmekten ayrı bir adımdır; bu yüzden tek yönlü düzeltmeler açılıp sonra takılan bağlantılar üretir.

Kuralların ve tabloların sahibi kim

Android'in ağ hizmeti netd, kuralları ve ağ başına tabloları oluşturur. AOSP RouteController bu kuralların VPN'ler, fiziksel ağlar ve uid aralıkları için bir araya getirildiği yerdir ve yaşam döngüsü bir yapılandırma dosyasına değil ağ olaylarına bağlıdır.

Bundan iki sonuç çıkar. Birincisi, bir cihazda bulduğunuz öncelikler ve tablo numaraları derleme içi ayrıntılardır, arayüz değildir: başka bir Android sürümünde aynı görünen numaralar tamamen başka bir anlam taşıyabilir. İkincisi, ağlar değiştiğinde durum yeniden oluşturulur, bu yüzden bugün root kabuğundan eklenen bir kural bir sonraki Wi-Fi geçişinden sonra gitmiş olabilir.

Bu kaybolma sık sık sistemin bir yolu yok sayması olarak bildirilir. Gerçekte olan şey, tabloyu seçen kuralın artık var olmaması ve tablo içindeki yolun paket açısından ulaşılamaz hale gelmesidir. Yeniden bağlanmadan sonra çalışan bir yapılandırma çalışmayı bıraktığında yol listesine değil kural listesine bakın.

Kanca sırası sorularının evrensel bir yanıtı yoktur

iptables'ın VPN yönlendirmesinden önce çalışıp çalışmadığı sorusu, paketin yolunu adlandırmadan yanıtlanamaz. Yerel olarak üretilen bir paket output kancasından geçer; burada işaret değişikliği bir yeniden yönlendirme denetimini tetikler — bu ikinci bir aramadır, birincisinin geriye dönük düzenlemesi değildir. Tether ile bağlı bir istemciden gelen paket prerouting yolundan geçer ve bunun yerine iletilir; onu gören zincirler başkadır.

Yani aynı kural bir uygulamanın trafiği için etkili, tether trafiği için görünmez olabilir ve sıfırda kalan bir sayaç size paketin hangi yolu izlediğini söyler, kuralın yanlış olup olmadığını değil. Herhangi bir eşleşme koşulunu değiştirmeden önce sayaçlarla yolu belirleyin.

Bu aynı zamanda politika yönlendirmesi hatasının görülmesinin zorlaştığı aşamadır. Var olan ama hedefi içermeyen bir tabloya yönlendirme, güvenlik duvarı düşürmesi gibi görünen ağ ulaşılamaz durumu üretir; güvenlik duvarı düşürmesi ise yönlendirme kara deliği gibi görünen bir zaman aşımı üretir.

Sistem içinde teşhis koyun, ya da ona dokunmayın

Yetkili bir inceleme için herhangi bir şeye dokunmadan önce dört olguyu saptayın: uygulamanın uid değeri ve profili, Android'in onun için seçtiği ağ, VPN'in o uygulamayı dahil edip etmediği ve sorunun her iki adres ailesinde de olup olmadığı. Uygulama bazında dışlama, hiçbir yönlendirme arızası olmadan gelen pek çok VPN çalışmıyor bildirimini açıklar.

Sonra gerçekten yürürlükte olan kuralları, maskeleri ve tabloları okuyun ve ağ geçişini gözlem penceresi içinde tutun. Davranış bir yeniden bağlanma boyunca değişiyorsa yönetilen bir yaşam döngüsüne bakıyorsunuz, eksik bir yola değil.

Olağan gereksinimler için desteklenen denetimleri kullanın: uygulama bazında dahil etme ve dışlama VPN uygulamasında ve belirli bir yol gerektiren her şey için platformun kendi ağ seçimini. Ayrıcalıklı bir entegrasyon gerçekten yönlendirme mekanizmasıyla işbirliği yapmak zorundaysa, desteklediğiniz Android sürümünün tam olarak o sürümünün uygulamasını hedefleyin ve yaşam döngüsünü ona sahip olan bileşen üzerinden sürdürün. Platform zincirlerini temizlemek veya yüksek öncelikli bir kural eklemek bir tanıyı ikinci bir ağ yöneticisine dönüştürür ve telefon buna göre davranır.