La VPN del mòbil cobreix l'ordinador portàtil al seu punt d'accés?
El punt d'accés comparteix la connexió a internet del mòbil, però no necessàriament el seu túnel. Tres condicions decideixen la cobertura, i l'ordinador sempre pot executar la seva pròpia VPN.
El navegador del mòbil informa d'una adreça en un altre país i l'ordinador connectat al seu punt d'accés encara informa de l'operador mòbil. Cap de les dues observacions no és errònia, i la contradicció que veu la gent ve de suposar que compartir una connexió a internet també comparteix un túnel. Tres condicions decideixen si el trànsit del dispositiu enllaçat entra a la VPN del mòbil, i només una té a veure amb la configuració del mòbil. Repasseu-les abans de buscar una funció de compartició que potser no existeix.
Què reenvia realment el punt d'accés
L'enllaçament dóna a l'ordinador un camí a internet a través de la interfície mòbil del telèfon. El telèfon reenvia aquests paquets i, en el cas habitual, tradueix les adreces de l'ordinador quan surten. Això és una funció de reenviament, i reenviar no és el mateix que capturar trànsit dins d'un túnel.
Si els paquets reenviats entren després a la VPN del mòbil depèn de com l'aplicació VPN va instal·lar les seves rutes i regles. Una aplicació que només captura el trànsit originat al telèfon no veurà els paquets que el nucli reenvia en nom d'un client enllaçat.
Per això les dues observacions conviuen tan fàcilment. El navegador del propi mòbil fa servir el túnel, els paquets de l'ordinador segueixen el camí de reenviament, i res de cap de les dues pantalles no us enganya. Els dos dispositius simplement no fan la mateixa pregunta a la mateixa interfície. Un cop veieu aquesta separació, la queixa “per què el meu ordinador no està protegit” es converteix en una qüestió de disseny i no en un error.
Primera condició: quin túnel executa el mòbil
Comenceu identificant l'abast de la VPN al telèfon. Un túnel per a tot el dispositiu, un túnel per aplicació i un proxy només per al navegador són tres coses diferents, i només el primer té cap possibilitat de cobrir el trànsit reenviat. Mireu la descripció del proveïdor sobre què captura l'aplicació, no la icona de la barra d'estat.
Després comproveu què diu el proveïdor sobre l'enllaçament. Alguns documenten explícitament que el trànsit ordinari del punt d'accés queda fora del túnel, que és la resposta honesta per a un servei de consum que mai no va prometre ser un encaminador. La guia de Proton VPN per al punt d'accés a Android n'és un exemple publicat d'aquesta distinció; la documentació del vostre proveïdor és la que importa per al vostre dispositiu.
Una icona de VPN a la barra d'estat us diu que el telèfon té un túnel. No us diu quines interfícies cobreix aquest túnel, i en aquest buit viu la major part de la confusió.
Segona condició: si l'enllaçament hi és inclòs
Fins i tot un túnel per a tot el dispositiu pot excloure per disseny el trànsit reenviat, perquè les regles d'encaminament de l'aplicació es van escriure per a paquets generats localment. Incloure clients enllaçats normalment requereix que el proveïdor ho admeti explícitament, o un dispositiu amb root i regles personalitzades que la majoria de la gent no hauria d'intentar.
Passar de Wi-Fi a USB no ho canvia. El subsistema d'enllaçament admet diversos transports, però el transport no és la decisió d'encaminament. Un cable fa l'enllaç més estable i no fa res per a la cobertura del túnel, i per això el consell de “fes servir només USB” respon una pregunta diferent de la que es fa.
Les receptes antigues que buiden les regles del tallafoc i suposen noms d'interfície concrets no són instruccions portables. Es van escriure per a un dispositiu concret, una ROM concreta i un any concret, i aplicar-les a un telèfon actual és més probable que trenqui l'enllaçament que no que ampliï un túnel.
Tercera condició: quina identitat necessita la destinació
Aquesta és la condició que normalment resol el disseny, i no té res a veure amb els punts d'accés. Si l'ordinador ha d'arribar a la xarxa d'un empleador, la identitat que importa pertany a l'ordinador, i una VPN de consum al telèfon no la pot proporcionar.
ip -brief addr show curl -sS https://ifconfig.me/ip dig +short myip.opendns.com @resolver1.opendns.com
Executeu-ho a l'ordinador, no al telèfon, perquè la pregunta és què veu la destinació des del dispositiu que us importa. Una adreça pública informada pel telèfon respon una pregunta sobre el telèfon.
Fins i tot un resultat coincident des de l'ordinador és una prova limitada. La resolució de noms, altres aplicacions i el comportament quan el túnel falla pertanyen al dispositiu la cobertura del qual proveu, i una sola petició HTTP no caracteritza cap d'aquestes coses. Proveu l'aplicació que realment us importa i torneu-la a provar amb el túnel desconnectat deliberadament.
Què cal fer en lloc d'això, per ordre d'esforç
La resposta correcta més barata és executar la VPN a l'ordinador. Connecteu-lo al punt d'accés, deixeu que el telèfon proporcioni la connexió mòbil subjacent i establiu el túnel des del dispositiu que necessita la identitat. Això funciona amb les VPN d'empresa, que és el cas que més importa.
Si el dispositiu no pot executar cap client VPN, busqueu una passarel·la de compartició admesa explícitament o un encaminador de viatge que acabi el túnel. Llegiu la seva documentació per a la plataforma real en lloc de suposar que una funció de punt d'accés és aquesta passarel·la.
Si no és possible cap de les dues, accepteu la limitació en lloc de saltar-vos-la amb una recepta que no podeu mantenir. La VPN del mòbil cobreix el mòbil; l'ordinador necessita el seu propi camí, i saber-ho per endavant val més que una tarda d'experiments amb interfícies. Documenteu l'acord perquè la propera persona no el redescobreixi durant un incident. Una línia a la wiki de l'equip és suficient.