A hotspot-ügyfelek osztott alagútja nem alkalmazásonkénti kizárás
Egy alkalmazás kizárása a VPN-ből csak a telefont változtatja meg. A csatlakoztatott laptopnak saját továbbítási szabályra van szüksége, amely forrás, cél és NAT szerint illeszkedik.
Két követelmény, amely egyformán hangzik, nem ugyanaz: „zárd ki ezt az alkalmazást a VPN-ből” és „küldd ezt az egy célt a VPN-en kívülre a hotspotomon lévő laptophoz”. Az első megváltoztatja, hogyan választ hálózatot egy socket a telefonon. A másodiknak egy továbbítási döntést kell megváltoztatnia egy olyan csomaghoz, amely egy másik eszközről érkezett, miután a telefon már elfogadta. A kettő összekeverése az, amiért egy hotspot-ügyfél olyan kivétellel marad, amely mindig csak a telefon saját böngészőjére vonatkozott.
Két alrendszer birtokolja a két kérdést
Az Android külön tartja az alkalmazások hálózatkezelését és a megosztást. Az alkalmazások socketjeit a kapcsolódási verem rendeli hálózathoz, és a VPN-alkalmazás dönti el, mely saját socketjei lépnek be az alagútba. A csatlakoztatott ügyféltől továbbított csomagokat a megosztási alrendszer kezeli, amely útvonalakat, házirend-szabályokat és fordítást kér a netd-től az alsó interfészen.
Az alkalmazásonkénti kizárás akkor értékelődik ki, amikor egy alkalmazás socketet nyit. Egy továbbított csomag soha nem éri el ezt az ellenőrzést, mert nem ezen az eszközön lévő alkalmazás-socketből származik. Pontosan ez az oka annak, hogy a két beállítás nem helyettesítheti egymást, és ez nem hiba egyikben sem.
Mit változtat valójában az alkalmazásonkénti kizárás
A VpnService építője megnevezheti az alagúton kívül maradó csomagokat az addDisallowedApplication segítségével, vagy megnevezheti az egyedüli bent engedélyezett csomagokat az addAllowedApplication segítségével. Ezek az alkalmazások ezután socketeket nyitnak az alatta lévő hálózaton, miközben a VPN továbbra is birtokolja az alapértelmezett útvonalat minden más számára.
A hatókör pontos: a csomag saját socketjei, ezen az eszközön, amíg az alagút áll. Semmit nem mond a továbbított forgalomról, semmit egy második eszközről, és semmit a rendszer által a megosztás nevében küldött csomagokról.
Ez sem célirányítás. Egy böngésző kizárása minden címet kizár, amelyet az a böngésző elér, beleértve azt, amelyet az alagúton belül akart tartani. Amikor a követelmény alkalmazás helyett célt nevez meg, az alkalmazásválasztó már felépítésénél fogva rossz eszköz.
Hogyan néz ki egy továbbított csomag a telefon szemében
Az ügyfél csomagja a hotspot-interfészen érkezik a telefon által kiosztott privát forráscímmel, mondjuk 192.168.43.20, és nyilvános céllal. A továbbításhoz a telefonnak útvonal kell egy felső kapcsolat felé, és egy fordítási szabály, hogy a válaszok megtalálják a visszautat, mert az ügyfél privát címe értelmetlen a mobilihálózaton.
Az Android ezt olyan házirend-szabályokkal fejezi ki, amelyek útvonaltáblát választanak, és a netd újraépíti a vonatkozó táblákat és szabályokat, amikor a hálózatok és a VPN-ek változnak. Egy fórumbejegyzésből vagy ugyanazon modell régebbi kiadásából másolt táblaszám, szabályprioritás vagy interfésznév nem teremt tartós tulajdont. Ez az újraépítés az oka annak is, hogy egy kézzel írt szabály egy órán át működhet, majd a következő újracsatlakozás után leáll.
Milyen házirendre van valóban szüksége egy hotspot-kivételnek
Írja le a döntést forrásként, célként és szándékolt útvonalként, mielőtt bármelyik szabályhoz nyúlna. Egy jóváhagyott cél minimális formája így néz ki:
| Source | Destination | Intended path |
|---|---|---|
| One authorized hotspot client | One approved public service address | Ordinary cellular uplink |
| The same client | All other covered destinations | Shared VPN |
| The phone's own apps | Their existing destinations | Unchanged phone policy |
Mindkét iránynak teljesnek kell lennie. A közvetlen ágnak használható útvonalra van szüksége a mobil felső kapcsolaton, amely éppen aktuális; a VPN-ágnak az alagút útvonalára plusz továbbítási engedélyre. Minden forrásfordításnak illeszkednie kell a választott kimenethez, mert az alagút-interfészen alkalmazott NAT az alagút címét mutatja, nem a mobilét, és akkor a visszaút nem egyezik a kimenő útvonallal.
A válaszoknak ugyanahhoz az alsó ügyfélhez kell eljutniuk követett állapoton vagy kifejezett útvonalon keresztül, és a kimenő csomagszámláló ebből semmit nem bizonyít. Tartsa a VPN saját külső szállítását is a kivétel hatókörén kívül, különben az alagút hordozócsomagjai egy ügyfél webes kérésére írt házirendet örökölnek.
Egy elkapott cím nem cél
Egyetlen böngészőből olvasott IPv4-cím pillanatkép. A nagy szolgáltatások anycastról vagy forgó peremcím-készletről válaszolnak, sokuk kettős verem, és egy bejelentkezési folyamat olyan hitelesítési és telemetriai hosztokat érinthet, amelyeket az oldal soha nem mutat. Az a kivétel, amely a véletlenül látott cím köré épül, legközelebb elromlik, amikor a szolgáltatás újra terheli a rendszert.
Használja a szolgáltatás tulajdonosának dokumentált címeit vagy egy általa közzétett tartományt, és számoljon mindkét címcsaláddal. Ha a követelmény nem fejezhető ki stabil halmazként, az valószínűleg házirend-kérdés a szolgáltatás számára, nem útválasztási trükk a telefonon.
Ellenőrizze az alsó oldalról
Három ellenőrzés, ebben a sorrendben: a kiválasztott szolgáltatás a laptopról, egy hétköznapi cél, amelynek a VPN-en belül kell maradnia, és egy telefonos alkalmazás, amelynek érintetlennek kell maradnia. Utána ismételje meg újracsatlakozás és felső kapcsolatváltás után, mert akkor épülnek újra a házirend-táblák.
Ha a telefon megosztási megvalósítása nem tudja tartani ezt a szerződést egy újracsatlakozáson át, helyezze át a szelektív házirendet egy támogatott alsó routerre, ahelyett hogy root-szabályokat halmozna a készüléken. Egy router stabil tulajdonossal tudja kifejezni a forrás- és célillesztést, és a a megosztási modul dokumentációja a helyes hivatkozás arra, amit a telefon valójában tesz.