Android emülatörü ve ana makine VPN'i: DNS anlık görüntüsü ve NAT

Emülatör, ana makinedeki tarayıcının sorunsuz açtığı bir derleme sunucusuna ulaşamadığında, yararlı soru VPN'in çalışıp çalışmadığı değildir. Soru, konuğun iki mekanizmadan hangisinin eksik olduğudur. Sanal aygıt kendi ağ yığınını emülatörün NAT'ı arkasında çalıştırır ve çözümleyici listesi açılış sırasında alınmış bir kopyadır, bu yüzden sonradan açılan bir tünel ana makinenin yolunu değiştirir ama konuğun ne sorduğunu değiştirmez. Bu iki katmanı anlamak bu sorunun neredeyse her varyantını açıklar.

Konuk, sabit bir NAT arkasındaki ayrı bir yığındır

QEMU'nun kullanıcı modu ağı konuğu 10.0.2.15'e, ağ geçidini 10.0.2.2'ye ve DNS hizmetini 10.0.2.3 ile 10.0.2.6 arasına yerleştirir. Konuğun giden trafiği ana makinenin çekirdeği tarafından iletilmez; ana makine tarafında soketlere çevrilir, her konuk bağlantısı için bir tane, ve bu soketler ana makinenin adres alanından çıkar. Bu yüzden bir konuk bağlantısı oluşturulduğu anda ana makinenin yönlendirme kararını devralır ve bu yüzden konuğun yönlendirme tablosunda tünelinizi adlandıran bir girdi yoktur.

Aynı mekanizma konuğa kullanışlı bir çıkış yolu verir. 10.0.2.2 ana makinenin geri döngü arayüzünün diğer adıdır, bu yüzden dizüstü bilgisayarda 127.0.0.1 üzerinde dinleyen bir hizmete konuktan o adreste ulaşılabilir. İstemcinin yalnızca geri döngüde sunduğu her şeye bu yolla ulaşılabilir ve bu, aşağıda açıklanan vekil sunucu düzeninin temelidir.

Konuğun yapamadığı şey, ana makinenin ağını kendi ad alanıymış gibi gözlemlemektir. Köprü yoktur, paylaşılan yönlendirme tablosu yoktur ve devralınan çözümleyici yoktur; yalnızca paketlerini kabul eden NAT hizmeti ve sanal aygıt başlarken başlatıcının aldığı anlık görüntü vardır.

DNS bir anlık görüntüdür, canlı bir görünüm değildir

Başlangıçta emülatör ana makinenin çözümleyici listesini okur ve konuğa en fazla dört sunucu verir; bunlar 10.0.2.3 ile 10.0.2.6 adreslerinde sunulur. Tünel o anda kapalıysa anlık görüntü, dizüstü bilgisayarın kullandığı genel çözümleyiciyi içerir ve konuk ömrü boyunca onu sormaya devam eder. Genel adlar çözülür, iç adlar başarısız olur ve tüm belirtiler VPN'i işaret ederken gerçekte eski olan değer, tünel açılmadan birkaç dakika önce yakalanmış bir çözümleyici listesidir.

Dolayısıyla sıralama düzeltmesi folklor değildir. Önce tüneli bağlayın, sonra emülatörü yeniden başlatın ve anlık görüntü geri yüklemek yerine soğuk açılışı tercih edin, çünkü hızlı açılış imajı daha önce kaydettiği çözümleyici ve yol durumuyla geri gelebilir. Konuğun şu anda ne kullandığını görmek istiyorsanız ana makineye değil aygıta sorun:

adb shell dumpsys connectivity | grep -i -A2 dns
adb shell ping -c 1 build.internal.example

Emülatör başlangıçta açık bir çözümleyici de kabul eder; bu, konuğun hangi sunucuyu kullanması gerektiğini tam olarak bildiğinizde yararlı, o sunucu genel olduğunda ise tehlikelidir:

emulator -avd Pixel_API_34 -dns-server 203.0.113.53

Genel bir çözümleyicinin iç bölgenin kopyası yoktur, bu yüzden birini sabitlemek sıralama sorununu kalıcı bir hataya çevirir. Profil özel DNS gönderiyorsa tünelin onu sağlamasına izin verin ve adresi sabit kodlamak yerine konuğu soğuk açılışla başlatın.

Yönlendirme bağlantı anında ana makineyi izler

Konuk bağlantıları ana makinenin soketleri olduğundan yönlendirme kararı soket oluşturulurken verilir. İstekten önce açılmış tünel, isteğin profilin rotalarına tabi olarak tünelden çıktığı anlamına gelir. Yalnızca seçili önekleri taşıyan bir bölünmüş tünel profili özel alt ağınızı memnuniyetle dışarıda bırakır, bu yüzden ana makineye ulaşılabilirlik konuk hakkında bir varsayımdır, sonuç değil. Var olan konuk bağlantıları oluşturuldukları yolu korur, bu yüzden yeniden bağlanan bir istemci emülatörde takılmış bir indirmeyi her zaman düzeltmez.

Doğrulama ana makinenin arayüzünde yapılır, konuğun istatistiklerinde değil:

sudo tcpdump -ni tun0 'host 203.0.113.10'

Konuğun isteği tünel arayüzünde görünüyorsa yönlendirme çalışıyor ve sorun onun üzerindedir. Fiziksel arayüzde görünüyorsa profil o öneki kapsamıyor ve konuk tarafındaki hiçbir yeniden yapılandırma bunu değiştirmez.

İstemci yalnızca geri döngü vekili sunuyorsa

Bazı ticari istemciler hiç sistem tüneli oluşturmaz. 127.0.0.1 üzerinde bir HTTP veya SOCKS dinleyicisi sunarlar ve uygulamaların onu kullanmasını beklerler. Konuk o soketi doğrudan göremez ama emülatöre onu kullanması söylenebilir; ya genişletilmiş kontroller aracılığıyla (Settings, ardından Proxy, manuel mod, ana makine 127.0.0.1 ve istemcinin yazdırdığı bağlantı noktası) ya da başlatma sırasında:

emulator -avd Pixel_API_34 -http-proxy http://127.0.0.1:8080

Bağlantı noktasını istemci penceresinden kopyalayın; tahmin edilen bir bağlantı noktası sessizce başarısız olur ve bozuk bir tünel gibi görünür. Bunun neyi kapsadığını unutmayın: HTTP vekil ayarı vekili tanıyan uygulamalar tarafından dikkate alınır ve ham soketler onu tamamen yok sayar. İş yükü kendi bağlantılarını açan yerel bir ikili dosyaysa vekil yolu bir tünele eşdeğer değildir ve karşılaştırma açıkça yapılmalıdır.

Sonucu konuğun içinden kanıtlayın

Aynı oturumda iki testle ad çözümlemeyi yönlendirmeden ayırın. Sayısal adres yanıt verirken başarısız olan bir ad, DNS anlık görüntüsü sorunudur ve çözüm sıralama ya da açık bir çözümleyicidir. İkisi de başarısız olursa bu yönlendirmeye veya ilkeye işaret eder ve sonraki kontrol uygulamanın kendi ağ kısıtlamaları olan bir çalışma profilinde çalışıp çalışmadığıdır.

Son olarak hangi konukta test ettiğinizi bilin. Çok eski emülatör imajları, konuk tarafındaki bir VPN istemcisinin ihtiyaç duyduğu tun desteği olmadan gönderiliyordu, bu yüzden orada hiçbir profil asla çalışamazdı; güncel imajlarda bu destek vardır. Güncel bir imajda başarısız olan istemci bir istemci veya profil sorunudur ve ana makinenin tünelini yeniden kurmak sonucu değiştirmez.