Android emulyatoru və host VPN: DNS snapshot və NAT izahı

Emulyator host brauzerinin problemsiz açdığı build serverinə çata bilmədikdə, faydalı sual VPN-in işləyib-işləməməsi deyil. Sual qonağın iki mexanizmdən hansının çatışmadığıdır. Virtual cihaz emulyatorun NAT-ı arxasında öz şəbəkə yığını işlədir və onun resolver siyahısı yükləmə zamanı götürülmüş kopyadır, buna görə sonradan qalxan tunel host yolunu dəyişir, amma qonağın soruşduğunu dəyişmir. Bu iki qatı başa düşmək bu problemin demək olar ki, hər variantını izah edir.

Qonaq sabit NAT arxasında ayrı bir yığındır

QEMU-nun istifadəçi rejimli şəbəkəsi qonağı 10.0.2.15 ünvanına, şlüzü 10.0.2.2-yə və DNS xidmətini 10.0.2.3-dən 10.0.2.6-ya yerləşdirir. Qonağın çıxan trafiki host nüvəsi tərəfindən yönləndirilmir; host tərəfindəki soketlərə çevrilir, hər qonaq bağlantısı üçün bir soket, və o soketlər host ünvan məkanından çıxır. Buna görə qonaq bağlantısı yarandığı anda hostun marşrut qərarını miras alır və buna görə qonağın tunelinizi adlandıran heç bir marşrut cədvəli qeydi yoxdur.

Eyni mexanizm qonağa faydalı çıxış yolu verir. 10.0.2.2 hostun loopback interfeysinin ləqəbidir, buna görə noutbukda 127.0.0.1 üzərində dinləyən xidmətə qonaqdan həmin ünvanda çatmaq olar. Müştərinin yalnız loopback üzərində açdığı hər şeyə bu yolla çatmaq olar və bu, aşağıda təsvir olunan proksi quruluşunun əsasıdır.

Qonağın edə bilmədiyi şey host şəbəkəsini sanki onun üzərində bir ad məkanı imiş kimi müşahidə etməkdir. Körpü yoxdur, ortaq marşrut cədvəli yoxdur və miras alınan resolver yoxdur; yalnız paketlərini qəbul edən NAT xidməti və virtual cihaz başlayarkən başladıcının götürdüyü snapshot var.

DNS snapshot-dır, canlı görünüş deyil

Başlanğıcda emulyator hostun resolver siyahısını oxuyur və qonağa dörd serverə qədər verir, bunlar 10.0.2.3-dən 10.0.2.6-ya qədər ünvanlarda görünür. Əgər o anda tunel söndürülmüşdüsə, snapshot noutbukun istifadə etdiyi istənilən ictimai resolveri saxlayır və qonaq ömrünün qalan hissəsində ondan soruşmağa davam edir. İctimai adlar həll olunur, daxili adlar uğursuz olur və hər simptom VPN-i göstərir, halbuki əsl köhnəlmiş dəyər tunel qalxmazdan bir neçə dəqiqə əvvəl tutulmuş resolver siyahısıdır.

Buna görə sıralama ilə düzəliş əfsanə deyil. Əvvəlcə tuneli qoşun, sonra emulyatoru yenidən başladın və snapshot bərpasındansa soyuq yükləməyə üstünlük verin, çünki sürətli yükləmə obrazı əvvəl saxladığı resolver və marşrut vəziyyəti ilə qayıda bilər. Qonağın hazırda nə istifadə etdiyini görmək lazımdırsa, hostdan deyil, cihazdan soruşun:

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

Emulyator başlanğıcda açıq resolveri də qəbul edir; bu, qonağın hansı serveri istifadə etməli olduğunu dəqiq bildiyiniz zaman faydalı, həmin server ictimai olduqda isə təhlükəlidir:

emulator -avd Pixel_API_34 -dns-server 203.0.113.53

İctimai resolverin daxili zona kopyası yoxdur, buna görə birini bərkitmək sıralama problemini daimi uğursuzluğa çevirir. Profil şəxsi DNS təlqin edirsə, tunelin onu təmin etməsinə icazə verin və ünvanı sərt kodlaşdırmaq əvəzinə qonağı soyuq yükləyin.

Marşrutlaşdırma bağlantı vaxtında hostu izləyir

Qonaq bağlantıları host soketlərinə çevrildiyi üçün marşrut qərarı soket yaradılarkən verilir. Tunel sorğudan əvvəl qalxmışsa, sorğu profil marşrutlarına uyğun olaraq tuneldən çıxır. Yalnız seçilmiş prefiksləri daşıyan split-tunnel profili şəxsi alt şəbəkənizi məmnuniyyətlə kənarda qoyacaq, buna görə hostun əlçatanlığı qonaq haqqında bir fərziyyədir, nəticə deyil. Mövcud qonaq bağlantıları yaradıldıqları yolu saxlayır, buna görə yenidən qoşulan müştəri emulyatorun içində ilişmiş yükləməni həmişə düzəltmir.

Yoxlama qonağın statistikasında deyil, host interfeysində aparılır:

sudo tcpdump -ni tun0 'host 203.0.113.10'

Qonaq sorğusu tunel interfeysində görünürsə, marşrutlaşdırma işləyir və problem onun üstündədir. Fiziki interfeysdə görünürsə, profil həmin prefiksi əhatə etmir və qonaq tərəfində nə qədər yenidən konfiqurasiya etsəniz də bu dəyişməyəcək.

Müştəri yalnız loopback proksisi təklif etdikdə

Bəzi kommersiya müştəriləri ümumiyyətlə sistem tuneli yaratmır. Onlar 127.0.0.1 üzərində HTTP və ya SOCKS dinləyicisi açır və tətbiqlərin ondan istifadə etməsini gözləyirlər. Qonaq o soketi birbaşa görə bilməz, lakin emulyatora ondan istifadə etmək tapşırıla bilər: ya genişləndirilmiş idarəetmə vasitəsilə (Parametrlər, sonra Proksi, əl rejimi, host 127.0.0.1 və müştərinin çap etdiyi port), ya da başlanğıcda:

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

Portu müştəri pəncərəsindən kopyalayın; təxmin edilən port səssizcə uğursuz olur və qırıq tunel kimi görünür. Bunun nəyi əhatə etdiyini unutmayın: HTTP proksi parametrini proksidən xəbərdar olan tətbiqlər nəzərə alır, xam soketlər isə onu tamamilə ignore edir. Əgər iş yükü öz bağlantılarını açan yerli binar fayldırsa, proksi yolu tunelə bərabər deyil və müqayisə açıq şəkildə aparılmalıdır.

Nəticəni qonağın içindən sübut edin

Həlli marşrutlaşdırmadan eyni sessiyada iki testlə ayırın. Rəqəm ünvanı cavab verərkən uğursuz olan ad DNS snapshot problemidir və düzəliş sıralama və ya açıq resolverdir. Hər ikisi uğursuz olursa, bu marşruta və ya siyasətə işarə edir və növbəti yoxlama tətbiqin öz şəbəkə məhdudiyyətləri olan iş profili içində işləyib-işləmədiyidir.

Nəhayət, hansı qonaqda test etdiyinizi bilin. Çox köhnə emulyator obrazları qonaq tərəfli VPN müştərisinin ehtiyac duyduğu tun dəstəyi olmadan göndərilmişdi, buna görə orada heç bir profil işləyə bilməzdi; hazırkı obrazlarda bu var. Hazırkı obrazda uğursuz olan müştəri müştəri və ya profil problemidir və host tunelini yenidən qurmaq nəticəni dəyişməyəcək.