Eyni görünən iki tələb eyni deyil: “bu tətbiqi VPN-dən çıxar” və “bu bir təyinatı hotspot-dakı noutbuk üçün VPN-dən kənara göndər”. Birincisi telefonun soketinin şəbəkəni necə seçdiyini dəyişir. İkincisi, başqa cihazdan gələn və telefonun artıq qəbul etdiyi paket üçün yönləndirmə qərarını dəyişməlidir. İkisini qarışdırmaq, hotspot müştərisinin yalnız telefonun öz brauzerinə aid olan bir istisna ilə qalmasına gətirib çıxarır.

İki sualı iki ayrı alt sistem idarə edir

Android tətbiq şəbəkələri ilə tethering-i ayrı saxlayır. Tətbiq soketləri bağlantı yığını tərəfindən şəbəkəyə təyin edilir, VPN tətbiqi isə öz soketlərindən hansının tunelə girəcəyini qərarlaşdırır. Qoşulmuş müştəridən yönləndirilən paketlərlə tethering alt sistemi məşğul olur və o, netd-dən aşağı axın interfeysi üzrə marşrutlar, siyasət qaydaları və tərcümə tələb edir.

Tətbiq üzrə istisna tətbiq soket açanda qiymətləndirilir. Yönləndirilmiş paket heç vaxt o yoxlamaya çatmır, çünki bu cihazdakı tətbiq soketindən yaranmayıb. İki ayarın bir-birini əvəz edə bilməməsinin tam səbəbi budur və bu, heç birində qüsur deyil.

Tətbiq üzrə istisna əslində nəyi dəyişir

VpnService qurucusu addDisallowedApplication ilə tuneldən kənarda qalan paketləri adlandıra bilər və ya addAllowedApplication ilə içəri buraxılan yeganə paketləri adlandıra bilər. Sonra həmin tətbiqlər əsas şəbəkədə soket açır, VPN isə qalan hər şey üçün standart marşrutu saxlamağa davam edir.

Əhatə dəqiqdir: paketin öz soketləri, bu cihazda, tunel açıq olduğu müddətdə. Bu, yönləndirilmiş trafik, ikinci cihaz və sistemin tethering adından göndərdiyi paketlər barədə heç nə demir.

Bu, təyinat nəzarəti də deyil. Brauzeri istisna etmək həmin brauzerin çatdığı hər ünvanı istisna edir, o cümlədən tunelin içində saxlamaq istədiyiniz ünvanı. Tələb tətbiq əvəzinə bir təyinatı adlandırdıqda, tətbiq seçicisi quruluşuna görə yanlış vasitədir.

Qoşulmuş paket telefon üçün necə görünür

Müştərinin paketi hotspot interfeysinə telefonun təyin etdiyi xüsusi mənbə ünvanı ilə, deyək ki 192.168.43.20, və ictimai təyinatla gəlir. Onu yönləndirmək üçün telefonun yuxarı axına marşrut və tərcümə qaydası lazımdır ki, cavablar geri yolunu tapsın, çünki müştərinin xüsusi ünvanı mobil şəbəkədə mənasızdır.

Android bunu marşrut cədvəlini seçən siyasət qaydaları ilə ifadə edir və şəbəkələr və VPN-lər dəyişdikdə netd müvafiq cədvəlləri və qaydaları yenidən qurur. Forum yazısından və ya eyni modelin köhnə buraxılışından köçürülmüş cədvəl nömrəsi, qayda prioriteti və ya interfeys adı davamlı sahiblik yaratmır. Bu yenidənqurma həm də əl ilə yazılmış qaydanın bir saat işləyib növbəti yenidənqoşulmadan sonra dayanmasının səbəbidir.

Hotspot istisnasının əslində ehtiyac duyduğu siyasət

Qaydaya toxunmazdan əvvəl qərarı mənbə, təyinat və nəzərdə tutulan yol kimi yazın. Bir təsdiqlənmiş təyinat üçün minimal forma belə görünür:

SourceDestinationIntended path
One authorized hotspot clientOne approved public service addressOrdinary cellular uplink
The same clientAll other covered destinationsShared VPN
The phone's own appsTheir existing destinationsUnchanged phone policy

Hər iki istiqamət tam olmalıdır. Birbaşa budaq hazırda mövcud olan mobil yuxarı axın üzrə işlək marşrut tələb edir; VPN budağı isə tunel marşrutu və yönləndirmə icazəsi tələb edir. Hər hansı mənbə tərcüməsi seçdiyiniz çıxışa uyğun olmalıdır, çünki tunel interfeysində tətbiq olunan NAT tunel ünvanını göstərir, mobil ünvanı yox, və onda geri dönüş yolu çıxış yolu ilə uzlaşmır.

Cavablar izlənən vəziyyət və ya açıq marşrut vasitəsilə həmin aşağı axın müştərisinə çatmalıdır və çıxan paket sayğacı bunların heç birini sübut etmir. VPN-in öz xarici nəqlini də istisnanın əhatəsindən kənarda saxlayın, əks halda tunelin daşıyıcı paketləri müştərinin veb sorğusu üçün yazılmış siyasəti miras alır.

Tutulmuş bir ünvan təyinat deyil

Brauzerdən oxunan tək IPv4 ünvanı bir anlıq görüntüdür. Böyük xidmətlər anycast-dən və ya dəyişən kənar ünvanlar dəstindən cavab verir, çoxu ikimərtəbəlidir və giriş axını səhifənin heç vaxt göstərmədiyi autentifikasiya və telemetriya hostlarına toxuna bilər. Təsadüfən gördüyünüz ünvan ətrafında qurulmuş istisna, xidmət növbəti dəfə balanslaşdırdıqda pozulur.

Xidmətin sahibinin sənədləşdirilmiş ünvanlarından və ya onun dərc etdiyi diapazondan istifadə edin və hər iki ünvan ailəsini nəzərə alın. Tələb sabit dəst kimi ifadə oluna bilmirsə, bu, çox güman ki, telefon üzərində marşrut hiyləsi deyil, xidmət üçün siyasət sualıdır.

Aşağı axın tərəfdən yoxlayın

Üç yoxlama, bu sıra ilə: noutbukdan seçilmiş xidmət, VPN-in içində qalmalı olan adi təyinat və təsirlənməməli olan telefon tətbiqi. Sonra yenidənqoşulmadan və yuxarı axın dəyişikliyindən sonra təkrarlayın, çünki siyasət cədvəlləri məhz o zaman yenidən qurulur.

Telefonun paylaşım tətbiqi bu müqaviləni yenidənqoşulma boyunca saxlaya bilmirsə, seçici siyasəti telefon üzərində root qaydaları yığmaq əvəzinə dəstəklənən aşağı axın marşrutlaşdırıcısına köçürün. Marşrutlaşdırıcı sabit sahiblə mənbə və təyinat uyğunlaşdırmasını ifadə edə bilər və tethering modulu sənədləşməsi telefonun həqiqətən nə etdiyi üçün doğru mənbədir.

Əlaqəli məqalələr