Telefon-VPN heim: gjer brannmuren til internettutgangen din

Å kople ein telefon til heimetunnelen og opne ei LAN-fildeling syner at tunnelen verkar. Det syner ikkje at internettførespurnadene frå telefonen går ut gjennom huset. Skilnaden mellom desse to resultata er ein vidaresendingspolicy pluss ei rute, ikkje nok ein avkrysningsboks på telefonen. Det er òg skilnaden dei fleste trur dei alt har konfigurert.

Tre avgjerder skapar utgangsvegen: kva telefonen sender inn i tunnelen, kvar heimeporten vidaresender det, og kva som skjer når tunnelen ikkje er der. Kvar har ein feilmodus som frå telefonskjermen ser ut som dei andre.

To hopp, to policyar

Den ytre sambindinga endar ved heimens VPN-lyttar. Den indre pakken er eit eige objekt som må vidaresendast ein stad, og vidaresending er eit anna brannmur-avgjerd enn å godta tunnelen i utgangspunktet.

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

På ein typisk heimeruter bur desse i ulike regelsett. Å godta tunnelen er inngangspolicy på VPN-grensesnittet; å senda trafikken frå telefonen ut på internett er vidaresendingspolicy pluss den kjeldeomsetjinga uplinken treng. Ein ruter som godtek tunnelen og ikkje vidaresender noko, gjev ein telefon som viser tilkopla og ikkje lastar nokon sider.

Viss VPN-tenesta køyrer på ein eigen maskin inne i huset, legg til eit hopp. Ruteren ser no trafikk som kjem frå den maskinen, så reglane gjeld adressa til tenaren i staden for tunneladressa til telefonen, og kjeldeomsetjing kan få kvar telefon til å sjå ut som éin vert.

Lyttaren er ikkje filteret

Avgjer kvar handhevinga skjer medan informasjonen du treng enno finst. På ruteren er tunneladressa til telefonen synleg og kan matchast direkte. Bak ei andre omsetjing er ho borte, og reglar skrivne for adressa til telefonen matchar stille ingenting.

Dette er den vanlege grunnen til at ein policy verkar for laptopen og ikkje for telefonen. Laptopen koplast direkte til ruteren, telefonen koplast til ein tenar som vidaresender gjennom ruteren, og berre den første vegen bevarer adressa regelen ventar. Regelen er ikkje feil; han matchar ein verdi som ikkje finst lenger på det punktet.

Skriv ned vegen med kjeldeadressa slik ho ser ut ved kvart handhevingspunkt. Det eine diagrammet løyser dei fleste av desse tilfella før nokon regel vert redigert.

Kva telefonen faktisk må senda

Ein telefon som berre får ei rute til heimesubnettet, sender berre trafikken til det subnettet inn i tunnelen. Alt anna går ut over mobilnettet, og difor verkar fildelinga og internettførespurnadene når aldri huset.

Full tuneldekkje er ei rutingsavgjerd på klientsida, og ho må setjast med mekanismen plattforma støttar, ikkje antakast frå profilen som vert installert. Når ho er sett, må ruta tilbake til sjølve VPN-tenaren bli utanfor tunnelen, elles kan klienten ikkje halda på eigen transport.

DNS fortener si eiga avgjerd, fordi det er delen som mest truleg avvik frå resten av trafikken. Ei resolveradresse i profilen er eit framlegg som klientar handterer ulikt, og ein applikasjon med eigen kryptert resolver kan ta ein heilt separat veg. Viss heimepolicyen er avhengig av at førespurnader når ein bestemd resolver, handhev han der trafikken faktisk går, eller godta at nokre førespurnader ikkje gjer det. Ein førespurnad som omgår resolversen din, når aldri ein regel skriven for han.

IPv6 høyrer i same avsnitt som DNS, ikkje i eit vedlegg. Ein full IPv4-tunnel seier ingenting om AAAA-trafikk, og ein telefon på eit dual-stack mobilnett vil gjerne bruka den opphavlege vegen til det. Vel transport eller blokkering eksplisitt.

Kva brannmuren kan og ikkje kan sjå

Porten kan handle på det handhevingspunktet avdekkjer: adresser, portar, protokoll, grensesnitt og metadataa til sambindinga. Ein vidaresend HTTPS-førespurnad gjev ikkje frå seg sideinnhaldet eller passordet berre fordi han kryssar heimetunnelen.

Den grensa er verdt å nemne, fordi formuleringa «send han gjennom brannmuren» antydar meir inspeksjon enn ein heimeruter gjer. Ein destinasjonsregel, ein DNS-policy og ein proxy på applikasjonslaget er tre ulike kontrollar med tre ulike utrullingskostnader.

Ikkje gå ut frå at ein funksjon konfigurert for heimens LAN-klientar gjeld for VPN-grensesnittet. Sonemedlemskap er eit konfigurasjonsval, og eit VPN-grensesnitt som ikkje er i rett sone, arvar ingen av reglane du testa frå sofaen.

Avgjer den fråkopla tilstanden

Når tunnelen ikkje er tilgjengeleg, fell telefonen anten tilbake til mobilnettet eller nektar å senda trafikken. Båe er rimelege, og berre éin av dei svarar til det dei fleste trur dei har konfigurert.

Tilbakefall er praktisk og lek per definisjon: augneblinken tunnelen fell, er augneblinken førespurnadene går ut via vegen til operatøren. Blokkering er sterkare og gjer telefonen avhengig av at huset er tilgjengeleg, som er ein reell tilgjengekostnad for ein som reiser. Ingen av åtferdene er ein feil; båe er produkt, og du vel mellom dei anten du seier det eller ikkje.

Test valet i staden for å anta det. Stopp heimeterjenesta, prøv deretter éin førespurnad frå nettlesaren på telefonen og éin frå ein app som køyrer i bakgrunnen. Å kople til att seinare angrar ikkje førespurnadene som alt har gått ut.

Avslutt med to kontrollerte sjekkar frå telefonen sjølv: éin tillaten operasjon som skal krysse huset, og éin avvising som heimepolicyen skal handheva. Stadfest at porten logga flyten du venta, i adressefamilien du venta, etter ei attkopling. Ein telefon som viser Tilkopla, er byrjinga på den verifiseringa, aldri slutten.