Telefon-VPN hjem: gjør brannmuren til internettsutgangen din

Å koble en telefon til hjemmetunnelen og åpne en LAN-fildeling beviser at tunnelen virker. Det beviser ikke at telefonens internettforespørsler forlater huset. Forskjellen mellom de to resultatene er en videresendingspolicy pluss en rute, ikke nok en avkrysningsboks på telefonen. Det er også forskjellen de fleste tror de allerede har konfigurert.

Tre beslutninger skaper utgangsveien: hva telefonen sender inn i tunnelen, hvor hjemmegatewayen videresender det, og hva som skjer når tunnelen ikke er der. Hver har en feilmodus som fra telefonskjermen ser ut som de andres.

To hopp, to policyer

Den ytre forbindelsen ender ved hjemmets VPN-lytter. Den indre pakken er et eget objekt som må videresendes et sted, og videresending er en annen brannmur-beslutning enn å godta tunnelen i utgangspunktet.

phone app -> encrypted tunnel -> home listener
          -> decrypted packet -> forward policy -> home uplink -> destination

På en typisk hjemmeruter bor disse i forskjellige regelsett. Å godta tunnelen er inngangspolicy på VPN-grensesnittet; å sende telefonens trafikk ut på internett er videresendingspolicy pluss den kildeoversettelsen uplinket trenger. En ruter som godtar tunnelen og ikke videresender noe, gir en telefon som viser tilkoblet og ikke laster noen sider.

Hvis VPN-tjenesten kjører på en egen maskin inne i huset, legg til et hopp. Ruteren ser nå trafikk som kommer fra den maskinen, så reglene gjelder serverens adresse i stedet for telefonens tunneladresse, og kildeoversettelse kan få hver telefon til å se ut som én vert.

Lytteren er ikke filteret

Bestem hvor håndhevelsen skjer mens informasjonen du trenger fortsatt finnes. På ruteren er telefonens tunneladresse synlig og kan matches direkte. Bak en andre oversettelse er den borte, og regler skrevet for telefonens adresse matcher stille ingenting.

Dette er den vanlige grunnen til at en policy virker for laptopen og ikke for telefonen. Laptopen kobler direkte til ruteren, telefonen kobler til en server som videresender gjennom ruteren, og bare den første veien bevarer adressen regelen forventer. Regelen er ikke feil; den matcher en verdi som ikke finnes lenger på det punktet.

Skriv ned veien med kildeadressen slik den ser ut ved hvert håndhevelsespunkt. Det ene diagrammet løser de fleste av disse tilfellene før noen regel redigeres.

Hva telefonen faktisk må sende

En telefon som bare mottar en rute til hjemmesubnettet, sender bare det subnettets trafikk inn i tunnelen. Alt annet går ut over mobilnettet, og derfor virker fildelingen og internettforespørslene når aldri huset.

Full tunell dekning er en rutingsbeslutning på klientsiden, og den må settes med plattformens støttede mekanisme, ikke antas fra profilen som installeres. Når den er satt, må ruten tilbake til selve VPN-serveren bli utenfor tunnelen, ellers kan klienten ikke opprettholde sin egen transport.

DNS fortjener sin egen beslutning, fordi det er delen som mest sannsynlig avviker fra resten av trafikken. En resolveradresse i profilen er et forslag som klienter håndterer ulikt, og en applikasjon med sin egen krypterte resolver kan ta en helt separat vei. Hvis hjemmets policy avhenger av at forespørsler når en bestemt resolver, håndhev den der trafikken faktisk passerer, eller godta at noen forespørsler ikke gjør det. En forespørsel som omgår resolversen din, når aldri en regel skrevet for den.

IPv6 hører i samme avsnitt som DNS, ikke i et vedlegg. En full IPv4-tunnel sier ingenting om AAAA-trafikk, og en telefon på et dual-stack mobilnett vil gjerne bruke den opprinnelige veien til det. Velg transport eller blokkering eksplisitt.

Hva brannmuren kan og ikke kan se

Gatewayen kan handle på det håndhevelsespunktet avdekker: adresser, porter, protokoll, grensesnitt og metadataene til forbindelsen. En videresendt HTTPS-forespørsel gir ikke fra seg sideinnholdet eller passordet bare fordi den krysser hjemmetunnelen.

Den grensen er verdt å si, fordi formuleringen «send den gjennom brannmuren» antyder mer inspeksjon enn en hjemmeruter gjør. En destinasjonsregel, en DNS-policy og en proxy på applikasjonslaget er tre forskjellige kontroller med tre forskjellige utrullingskostnader.

Ikke anta at en funksjon konfigurert for hjemmets LAN-klienter gjelder for VPN-grensesnittet. Sonemedlemskap er et konfigurasjonsvalg, og et VPN-grensesnitt som ikke er i riktig sone, arver ingen av reglene du testet fra sofaen.

Bestem den frakoblede tilstanden

Når tunnelen ikke er tilgjengelig, faller telefonen enten tilbake til mobilnettet eller nekter å sende trafikken. Begge er rimelige, og bare én av dem samsvarer med det de fleste tror de har konfigurert.

Tilbakefall er praktisk og lekker per definisjon: øyeblikket tunnelen faller, er øyeblikket forespørslene forlater operatørens vei. Blokkering er sterkere og gjør telefonen avhengig av at huset er tilgjengelig, som er en reell tilgjengelighetskostnad for en som reiser. Ingen av atferdene er en feil; begge er produkter, og du velger mellom dem enten du sier det eller ikke.

Test valget i stedet for å anta det. Stopp hjemmetjenesten, prøv deretter én forespørsel fra telefonens nettleser og én fra en app som kjører i bakgrunnen. Å koble til igjen senere angrer ikke forespørslene som allerede har gått ut.

Avslutt med to kontrollerte sjekker fra telefonen selv: én tillatt operasjon som skal krysse huset, og én avvisning som hjemmets policy skal håndheve. Bekreft at gatewayen loggførte flyten du forventet, i adressefamilien du forventet, etter en gjentilkobling. En telefon som viser Tilkoblet, er begynnelsen på den verifiseringen, aldri slutten.