Split-tunneling vir hotspot-kliënte is nie uitsluiting per toepassing nie
Om 'n toepassing van die VPN uit te sluit, verander net die foon. 'n Gekoppelde skootrekenaar het sy eie deurvoerreël nodig, wat op bron, bestemming en NAT pas.
Twee vereistes wat soos dieselfde klink, is nie dieselfde nie: „sluit hierdie toepassing van die VPN uit” en „stuur hierdie een bestemming buite die VPN vir die skootrekenaar op my hotspot”. Die eerste verander hoe 'n sokket op die foon 'n netwerk kies. Die tweede moet 'n deurvoerbesluit verander vir 'n pakkie wat van 'n ander toestel gekom het nadat die foon dit al aanvaar het. Om die twee te verwar, is hoe 'n hotspot-kliënt beland met 'n uitsondering wat net ooit op die foon se eie blaaier van toepassing was.
Twee substelsels hanteer die twee vrae
Android hou toepassingsnetwerking en tethering apart. Toepassingsokette word deur die konnektiwiteitstapel aan 'n netwerk toegewys, en 'n VPN-toepassing besluit watter van sy eie sokette die tonnel binnegaan. Deurgevoerde pakkies van 'n gekoppelde kliënt word deur die tethering-substelsel hanteer, wat netd vra vir roetes, beleidsreëls en vertaling op die stroomaf-koppelvlak.
Die uitsluiting van 'n enkele toepassing word geëvalueer wanneer 'n toepassing 'n sokket oopmaak. 'n Deurgevoerde pakkie bereik nooit daardie kontrole nie, want dit het nie van 'n toepassingsokket op hierdie toestel gekom nie. Dit is die hele rede waarom die twee instellings nie vir mekaar kan instaan nie, en dit is nie 'n fout in enige van hulle nie.
Wat uitsluiting per toepassing werklik verander
Die bouer van 'n VpnService kan pakkette noem wat buite die tonnel bly met addDisallowedApplication, of die enigste pakkette noem wat binne toegelaat word met addAllowedApplication. Daardie toepassings maak dan sokette op die onderliggende netwerk oop terwyl die VPN die verstekroete vir alles anders bly besit.
Die omvang is presies: die pakket se eie sokette, op hierdie toestel, solank die tonnel op is. Dit sê niks oor deurgevoerde verkeer nie, niks oor 'n tweede toestel nie, en niks oor pakkies wat die stelsel namens tethering stuur nie.
Dit is ook nie 'n bestemmingsbeheer nie. Om 'n blaaier uit te sluit, sluit elke adres uit wat daardie blaaier bereik, insluitend die een wat jy in die tonnel wou hou. Wanneer die vereiste 'n bestemming noem eerder as 'n toepassing, is die toepassingskeuse by ontwerp die verkeerde hulpmiddel.
Hoe 'n gekoppelde pakkie vir die foon lyk
Die kliënt se pakkie kom op die hotspot-koppelvlak aan met 'n private bronadres wat deur die foon toegewys is, sê 192.168.43.20, en 'n publieke bestemming. Om dit deur te voer het die foon 'n roete na 'n opstroom nodig en 'n vertaalreël sodat antwoorde hul pad terug kan vind, want die kliënt se private adres is betekenisloos op die sellulêre netwerk.
Android druk dit uit met beleidsreëls wat 'n roetertabel kies, en netd bou die betrokke tabelle en reëls weer op wanneer netwerke en VPN's verander. 'n Tabelnommer, reëlprioriteit of koppelvlaknaam wat uit 'n forumplasing gekopieer is, of van dieselfde model op 'n ouer weergawe, vestig nie blywende eienaarskap nie. Daardie herbou is ook waarom 'n handgeskrewe reël 'n uur lank kan werk en ná die volgende herverbinding kan stop.
Die beleid wat 'n hotspot-uitsondering werklik nodig het
Skryf die besluit as bron, bestemming en beoogde pad voordat jy aan 'n reël raak. 'n Minimale vorm vir een goedgekeurde bestemming lyk so:
| 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 |
Albei rigtings moet volledig wees. Die direkte tak het 'n bruikbare roete deur die sellulêre opstroom nodig wat toevallig tans aktief is; die VPN-tak het die tonnelroete plus toestemming om deur te voer nodig. Enige brontranslasie moet by die uitgang pas wat jy gekies het, want NAT wat op 'n tonnelkoppelvlak toegepas word, wys die tonneladres en nie die sellulêre een nie, en die terugpad stem dan nie met die uitgaande pad ooreen nie.
Antwoorde moet dieselfde stroomaf-kliënt bereik deur bygehoue toestand of 'n eksplisiete roete, en 'n teller vir uitgaande pakkies bewys niks daarvan nie. Hou ook die VPN se eie buitenste vervoer buite die omvang van die uitsondering, anders erf die tonnel se draerpakkies 'n beleid wat vir 'n kliënt se webversoek geskryf is.
Een vasgevang adres is nie 'n bestemming nie
'n Enkele IPv4-adres wat uit 'n blaaier gelees word, is 'n momentopname. Groot dienste antwoord vanaf anycast of 'n roterende stel randadresse, baie is tweestapel, en 'n aanmeldvloei kan verifikasie- en telemetriehoste raak wat die bladsy nooit wys nie. 'n Uitsondering wat rondom die adres gebou is wat jy toevallig gesien het, breek die volgende keer wanneer die diens herbalanseer.
Gebruik die diens se eienaar se gedokumenteerde adresse, of 'n reeks wat hy publiseer, en reken vir albei adresfamilies. As die vereiste nie as 'n stabiele stel uitgedruk kan word nie, is dit waarskynlik 'n beleidsvraag vir die diens eerder as 'n roeteringstruuk op 'n foon.
Verifieer van die stroomaf-kant
Drie kontroles, in hierdie orde: die gekose diens vanaf die skootrekenaar, 'n gewone bestemming wat binne die VPN moet bly, en 'n foon-toepassing wat onaangeraak moet bly. Herhaal dan ná 'n herverbinding en ná 'n verandering van opstroom, want dit is wanneer die beleidstabelle herbou word.
As die foon se deelimplementering daardie kontrak nie oor 'n herverbinding kan hou nie, skuif die selektiewe beleid na 'n ondersteunde stroomaf-roeteerder eerder as om wortelreëls op die handstel op te hoop. 'n Roeteerder kan bron- en bestemmingspassing met 'n stabiele eienaar uitdruk, en die tethering-module-dokumentasie is die regte verwysing vir wat die foon werklik doen.