Telefona VPN al hejmo: faru la fajroŝirmilon via interreta eliro

Konekti telefonon al la hejma tunelo kaj malfermi LAN-dosierkunhavigon pruvas, ke la tunelo funkcias. Ĝi ne pruvas, ke la interretaj petoj de la telefono eliras tra la domo. La diferenco inter tiuj du rezultoj estas plusenda politiko plus itinero, ne plia markobutono sur la telefono. Ĝi ankaŭ estas la diferenco, kiun plej multaj homoj supozas, ke ili jam agordis.

Tri decidoj produktas la eliran vojon: kion la telefono sendas en la tunelon, kien la hejma enirejo plusendas ĝin, kaj kio okazas kiam la tunelo ne estas. Ĉiu havas malsukcesan reĝimon, kiu de la ekrano de la telefono aspektas kiel la aliaj.

Du saltoj, du politikoj

La ekstera konekto finiĝas ĉe la hejma VPN-aŭskultanto. La interna paketo estas aparta objekto, kiun oni devas plusendi ien, kaj plusendado estas malsama fajroŝirmila decido ol akcepti la tunelon unue.

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

Sur tipa hejma enkursigilo tiuj loĝas en malsamaj regul-aroj. Akcepti la tunelon estas eniga politiko sur la VPN-interfaco; sendi la trafikon de la telefono al la interreto estas plusenda politiko plus tiu fonttraduko, kiun la suprenligo bezonas. Enkursigilo, kiu akceptas la tunelon kaj plusendas nenion, produktas telefonon, kiu montras konektite kaj ŝargas neniujn paĝojn.

Se la VPN-servo ruliĝas sur aparta maŝino ene de la domo, aldonu salton. La enkursigilo nun vidas trafikon alvenantan de tiu maŝino, do ĝiaj reguloj validas por la adreso de la servilo anstataŭ por la tunela adreso de la telefono, kaj fonttraduko povas igi ĉiun telefonon aspekti kiel unu gastiganto.

La aŭskultanto ne estas la filtrilo

Decidu, kie okazas la trudado, dum la informo, kiun vi bezonas, ankoraŭ ekzistas. Sur la enkursigilo la tunela adreso de la telefono estas videbla kaj povas esti rekte kongruigita. Malantaŭ dua traduko ĝi malaperis, kaj reguloj skribitaj por la adreso de la telefono silente kongruas kun nenio.

Tio estas la kutima kialo, kial politiko funkcias por la tekkomputilo kaj ne por la telefono. La tekkomputilo konektiĝas rekte al la enkursigilo, la telefono konektiĝas al servilo, kiu plusendas tra la enkursigilo, kaj nur la unua vojo konservas la adreson, kiun la regulo atendas. La regulo ne malĝustas; ĝi kongruigas valoron, kiu jam ne ekzistas ĉe tiu punkto.

Skribu la vojon kun la fontadreso, kiel ĝi aperas ĉe ĉiu truda punkto. Tiu unu diagramo solvas la plej multajn el tiuj kazoj antaŭ ol iu regulo estas redaktata.

Kion la telefono efektive devas sendi

Telefono, kiu ricevas nur itineron al la hejma subreto, sendas en la tunelon nur la trafikon de tiu subreto. Ĉio alia eliras tra la poŝtelefona reto, tial la dosierkunhavigo funkcias kaj la interretaj petoj neniam atingas la domon.

Plena tunela kovrado estas enkursiga decido ĉe la klienta flanko, kaj ĝi devas esti agordita per la mekanismo, kiun la platformo subtenas, ne supozita el la profilo, kiu estas instalata. Post kiam ĝi estas agordita, la itinero reen al la VPN-servilo mem devas resti ekster la tunelo, alie la kliento ne povas konservi sian propran transporton.

DNS meritas propran decidon, ĉar ĝi estas la parto, kiu plej verŝajne devias de la resto de la trafiko. Solvila adreso en la profilo estas sugesto, kiun klientoj traktas malsame, kaj aplikaĵo kun sia propra ĉifrita solvilo povas preni tute apartan vojon. Se la hejma politiko dependas de tio, ke petoj atingas difinitan solvilon, trudu ĝin tie, kie la trafiko efektive pasas, aŭ akceptu, ke iuj petoj ne faros tion. Peto, kiu preteriras vian solvilon, neniam atingas regulon skribitan por ĝi.

IPv6 apartenas al la sama alineo kiel DNS, ne al aldono. Plena IPv4-tunelo diras nenion pri AAAA-trafiko, kaj telefono sur duobla-staka poŝtelefona reto volonte uzos la indiĝenan vojon por ĝi. Elektu portadon aŭ blokadon eksplicite.

Kion la fajroŝirmilo povas vidi kaj kion ne

La enirejo povas agi laŭ tio, kion ĝia truda punkto malkaŝas: adresoj, pordoj, protokolo, interfaco kaj la metadatumoj de la konekto. Plusendita HTTPS-peto ne transdonas la korpon de la paĝo aŭ la pasvorton nur ĉar ĝi trapasas la hejman tunelon.

Tiu limo indas esti dirata, ĉar la frazo «plusendu ĝin tra la fajroŝirmilo» implicas pli da inspektado ol hejma enkursigilo faras. Celdestina regulo, DNS-politiko kaj aplikaĵtavola prokura servilo estas tri malsamaj regiloj kun tri malsamaj deplojaj kostoj.

Ne supozu, ke funkcio agordita por hejmaj LAN-klientoj validas por la VPN-interfaco. Zona membreco estas agorda elekto, kaj VPN-interfaco, kiu ne estas en la ĝusta zono, heredas neniun el la reguloj, kiujn vi testis de la sofo.

Decidu la malkonektitan staton

Kiam la tunelo ne disponeblas, la telefono aŭ reen falas al la poŝtelefona reto aŭ rifuzas sendi la trafikon. Ambaŭ estas raciaj, kaj nur unu el ili kongruas kun tio, kion plej multaj kredas, ke ili agordis.

Reenfalo estas oportuna kaj likas laŭdifine: la momento, kiam la tunelo falas, estas la momento, kiam petoj eliras laŭ la vojo de la operatoro. Blokado estas pli forta kaj igas la telefonon dependa de tio, ke la domo estu atingebla, kio estas reala haveblec-kosto por vojaĝanto. Neniu el la du kondutoj estas cimo; ambaŭ estas produktoj, kaj vi elektas inter ili ĉu vi diras tion aŭ ne.

Testu la elekton anstataŭ supozi ĝin. Haltigu la hejman servon, poste provu unu peton el la retumilo de la telefono kaj unu el aplikaĵo, kiu ruliĝas en la fono. Rekonekti poste ne malfaras la petojn, kiuj jam eliris.

Finu per du kontrolitaj ekzamenoj de la telefono mem: unu permesita operacio, kiu devas trapasi la domon, kaj unu rifuzo, kiun la hejma politiko devas trudadi. Konfirmu, ke la enirejo registris la fluon, kiun vi atendis, en la adresa familio, kiun vi atendis, post rekonekto. Telefono montranta «Konektite» estas la komenco de tiu kontrolado, neniam la fino.