Delad tunnel för hotspotklienter är inte undantag per app
Att undanta en app från VPN ändrar bara telefonen. Den anslutna bärbara datorn behöver sin egen vidarebefordringsregel, matchad på källa, mål och NAT.
Två krav som låter lika är inte lika: ”undantag den här appen från VPN” och ”skicka det här enda målet utanför VPN för den bärbara datorn på min hotspot”. Det första ändrar hur en socket på telefonen väljer nätverk. Det andra måste ändra ett vidarebefordringsbeslut för ett paket som kom från en annan enhet efter att telefonen redan har accepterat det. Att blanda ihop de två är hur en hotspotklient hamnar med ett undantag som alltid bara gällde telefonens egen webbläsare.
Två delsystem äger de två frågorna
Android håller appnätverk och tethering åtskilda. Appsockets tilldelas ett nätverk av anslutningsstacken, och en VPN-app avgör vilka av dess egna sockets som går in i tunneln. Vidarebefordrade paket från en ansluten klient hanteras av tethering-delsystemet, som ber netd om rutter, policyregler och översättning på nedströmsgränssnittet.
Undantag per app utvärderas när en app öppnar en socket. Ett vidarebefordrat paket når aldrig den kontrollen, eftersom det inte uppstod från en appsocket på den här enheten. Det är hela skälet till att de två inställningarna inte kan ersätta varandra, och det är inte en bugg i någon av dem.
Vad undantag per app faktiskt ändrar
En VpnService-byggare kan namnge de paket som stannar utanför tunneln med addDisallowedApplication, eller namnge de enda paket som tillåts inuti med addAllowedApplication. Dessa appar öppnar då sockets på det underliggande nätverket medan VPN fortsätter att äga standardrutten för allt annat.
Omfattningen är exakt: paketets egna sockets, på den här enheten, så länge tunneln är uppe. Den säger ingenting om vidarebefordrad trafik, ingenting om en andra enhet och ingenting om paket som systemet skickar på tetheringens vägnar.
Det är inte heller målstyrning. Att undanta en webbläsare undantar varje adress som den webbläsaren når, inklusive den du ville hålla kvar i tunneln. När kravet nämner ett mål i stället för en app, är appväljaren fel verktyg av konstruktion.
Hur ett tetherat paket ser ut för telefonen
Klientens paket anländer på hotspotgränssnittet med en privat källadress som telefonen har tilldelat, säg 192.168.43.20, och ett offentligt mål. För att vidarebefordra det behöver telefonen en rutt mot en upplänk och en översättningsregel så att svar hittar vägen tillbaka, eftersom klientens privata adress är meningslös i mobilnätet.
Android uttrycker det med policyregler som väljer en routingtabell, och netd bygger om de relevanta tabellerna och reglerna när nätverk och VPN ändras. Ett tabellnummer, en regelprioritet eller ett gränssnittsnamn som kopierats från ett foruminlägg, eller från samma modell i en äldre utgåva, etablerar inget varaktigt ägande. Den ombyggnaden är också skälet till att en handskriven regel kan fungera i en timme och sluta efter nästa återanslutning.
Vilken policy ett hotspotundantag faktiskt behöver
Skriv beslutet som källa, mål och avsedd väg innan du rör en regel. Minsta form för ett godkänt mål ser ut så här:
| 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 |
Båda riktningarna måste vara fullständiga. Den direkta grenen behöver en användbar rutt genom den mobila upplänken som råkar vara aktuell; VPN-grenen behöver tunnelrutten plus tillstånd att vidarebefordra. Varje källöversättning måste matcha den utgång du valde, eftersom NAT som tillämpas på ett tunnelgränssnitt visar tunneladressen och inte den mobila, och returvägen stämmer då inte med den utgående vägen.
Svar måste nå samma nedströmsklient via spårat tillstånd eller en explicit rutt, och en räknare för utgående paket bevisar inget av det. Håll också VPN:ens egen yttre transport utanför undantagets omfattning, annars ärver tunnelns bärarpaket en policy skriven för en klients webbförfrågan.
En fångad adress är inte ett mål
En enda IPv4-adress läst från en webbläsare är en ögonblicksbild. Stora tjänster svarar från anycast eller från en roterande uppsättning kantadresser, många är dubbelstackade, och ett inloggningsflöde kan röra autentiserings- och telemetrivärdar som sidan aldrig visar. Ett undantag byggt kring adressen du råkade se går sönder nästa gång tjänsten ombalanserar.
Använd tjänstens ägares dokumenterade adresser, eller ett intervall som den publicerar, och räkna med båda adressfamiljerna. Om kravet inte kan uttryckas som en stabil mängd är det sannolikt en policyfråga för tjänsten och inte ett routingtrick på en telefon.
Verifiera från nedströmssidan
Tre kontroller, i den här ordningen: den valda tjänsten från den bärbara datorn, ett vanligt mål som måste stanna i VPN, och en telefonapp som måste vara opåverkad. Upprepa sedan efter en återanslutning och efter en ändring av upplänken, för det är då policytabellerna byggs om.
Om telefonens delningsimplementering inte kan hålla det avtalet genom en återanslutning, flytta den selektiva policyn till en stödd nedströmsrouter i stället för att samla root-regler på enheten. En router kan uttrycka käll- och målmatcning med en stabil ägare, och dokumentationen för tetheringmodulen är den rätta referensen för vad telefonen faktiskt gör.