El túnel dividit per a clients de punt d’accés no és una exclusió per aplicació
Excloure una aplicació de la VPN només canvia el telèfon. L’ordinador connectat necessita la seva pròpia regla de reenviament, casada per origen, destí i NAT.
Dos requisits que sonen equivalents no ho són: «exclou aquesta aplicació de la VPN» i «envia aquest únic destí fora de la VPN per a l’ordinador del meu punt d’accés». El primer canvia com un sòcol del telèfon tria una xarxa. El segon ha de canviar una decisió de reenviament per a un paquet que ha arribat d’un altre dispositiu després que el telèfon ja l’hagi acceptat. Confondre els dos és com un client de punt d’accés acaba amb una excepció que només s’havia aplicat mai al navegador del propi telèfon.
Dos subsistemes tenen les dues preguntes
Android manté separades la xarxa de les aplicacions i el tethering. La pila de connectivitat assigna els sòcols de les aplicacions a una xarxa, i una aplicació VPN decideix quins dels seus propis sòcols entren al túnel. Els paquets reenviats d’un client connectat els gestiona el subsistema de tethering, que demana a netd rutes, regles de política i traducció a la interfície de baixada.
L’exclusió per aplicació s’avalua quan una aplicació obre un sòcol. Un paquet reenviat no arriba mai a aquesta comprovació, perquè no s’ha originat en un sòcol d’aplicació d’aquest dispositiu. Aquesta és tota la raó per la qual els dos ajustos no es poden substituir l’un a l’altre, i no és cap error en cap dels dos.
Què canvia realment l’exclusió per aplicació
Un constructor de VpnService pot anomenar els paquets que queden fora del túnel amb addDisallowedApplication, o anomenar els únics paquets permesos a dins amb addAllowedApplication. Aquestes aplicacions obren llavors sòcols a la xarxa subjacent mentre la VPN continua tenint la ruta per defecte per a tota la resta.
L’abast és precís: els sòcols propis del paquet, en aquest dispositiu, mentre el túnel estigui aixecat. No diu res sobre el trànsit reenviat, res sobre un segon dispositiu i res sobre els paquets que el sistema envia en nom del tethering.
Tampoc no és un control de destí. Excloure un navegador exclou cada adreça que aquest navegador assoleix, inclosa la que volíeu mantenir dins del túnel. Quan el requisit anomena un destí en lloc d’una aplicació, el selector d’aplicacions és l’eina equivocada per construcció.
Com veu el telèfon un paquet connectat
El paquet del client arriba a la interfície del punt d’accés amb una adreça d’origen privada assignada pel telèfon, posem 192.168.43.20, i un destí públic. Per reenviar-lo, el telèfon necessita una ruta cap a un enllaç ascendent i una regla de traducció perquè les respostes trobin el camí de tornada, perquè l’adreça privada del client no té sentit a la xarxa cel·lular.
Android ho expressa amb regles de política que seleccionen una taula d’encaminament, i netd reconstrueix les taules i regles corresponents quan canvien les xarxes i les VPN. Un número de taula, una prioritat de regla o un nom d’interfície copiats d’un missatge de fòrum, o del mateix model en una versió anterior, no estableixen una propietat duradora. Aquesta reconstrucció és també la raó per la qual una regla escrita a mà pot funcionar una hora i aturar-se després de la propera reconnexió.
La política que realment necessita una excepció de punt d’accés
Escriviu la decisió com a origen, destí i camí previst abans de tocar cap regla. La forma mínima per a un destí aprovat és aquesta:
| 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 |
Tots dos sentits han de ser complets. La branca directa necessita una ruta utilitzable per l’enllaç ascendent cel·lular que resulti ser l’actual; la branca VPN necessita la ruta del túnel més permís per reenviar. Qualsevol traducció d’origen ha de coincidir amb la sortida que heu triat, perquè el NAT aplicat a una interfície de túnel presenta l’adreça del túnel i no la cel·lular, i llavors el camí de tornada no concorda amb el camí de sortida.
Les respostes han d’arribar al mateix client de baixada mitjançant estat seguit o una ruta explícita, i un comptador de paquets de sortida no demostra res d’això. Manteniu també el transport exterior propi de la VPN fora de l’abast de l’excepció, o els paquets portadors del túnel hereten una política escrita per a una petició web d’un client.
Una adreça capturada no és un destí
Una sola adreça IPv4 llegida d’un navegador és una instantània. Els serveis grans responen des d’anycast o des d’un conjunt rotatiu d’adreces de vora, molts són de doble pila, i un flux d’inici de sessió pot tocar amfitrions d’autenticació i telemetria que la pàgina no mostra mai. Una excepció construïda al voltant de l’adreça que heu vist per casualitat es trenca la propera vegada que el servei reequilibra.
Feu servir les adreces documentades pel propietari del servei, o un rang que publiqui, i compteu les dues famílies d’adreces. Si el requisit no es pot expressar com un conjunt estable, probablement és una qüestió de política per al servei i no un truc d’encaminament en un telèfon.
Verifiqueu des del costat de baixada
Tres comprovacions, en aquest ordre: el servei seleccionat des de l’ordinador, un destí ordinari que ha de quedar dins de la VPN i una aplicació del telèfon que ha de quedar sense afectació. Després repetiu-ho després d’una reconnexió i després d’un canvi d’enllaç ascendent, perquè és llavors quan es reconstrueixen les taules de política.
Si la implementació de compartició del telèfon no pot mantenir aquest contracte durant una reconnexió, moveu la política selectiva a un encaminador de baixada compatible en lloc d’acumular regles root al dispositiu. Un encaminador pot expressar la concordança d’origen i destí amb un propietari estable, i la documentació del mòdul de tethering és la referència correcta per a què fa realment el telèfon.