Telefon-VPN til hjemmet: gør firewallen til din internetudgang

At forbinde en telefon til hjemmets tunnel og åbne en LAN-fildeling beviser, at tunnelen virker. Det beviser ikke, at telefonens internetanmodninger forlader huset. Forskellen på de to resultater er en videresendelsespolitik plus en rute, ikke endnu en afkrydsningsboks på telefonen. Det er også den forskel, som de fleste antager, at de allerede har konfigureret.

Tre beslutninger frembringer udgangsstien: hvad telefonen sender ind i tunnelen, hvor hjemmets gateway videresender det hen, og hvad der sker, når tunnelen ikke er der. Hver har en fejltilstand, der fra telefonens skærm ligner de andres.

To spring, to politikker

Den ydre forbindelse ender ved hjemmets VPN-lytter. Den indre pakke er et separat objekt, der skal videresendes et sted hen, og videresendelse er en anden firewallbeslutning end at acceptere tunnelen i første omgang.

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

På en typisk hjemmerouter bor disse i forskellige regelsæt. At acceptere tunnelen er inputpolitik på VPN-interfacet; at sende telefonens trafik ud på internettet er videresendelsespolitik plus den kildeoversættelse, uplinket har brug for. En router, der accepterer tunnelen og ikke videresender noget, giver en telefon, der viser forbundet og ikke indlæser nogen sider.

Hvis VPN-tjenesten kører på en separat maskine inde i huset, tilføj et spring. Routeren ser nu trafik, der kommer fra den maskine, så dens regler gælder serverens adresse i stedet for telefonens tunneladresse, og kildeoversættelse kan få hver telefon til at ligne én vært.

Lytteren er ikke filteret

Beslut, hvor håndhævelsen sker, mens den information, du har brug for, stadig findes. På routeren er telefonens tunneladresse synlig og kan matches direkte. Bag en anden oversættelse er den væk, og regler skrevet til telefonens adresse matcher stille ingenting.

Det er den sædvanlige grund til, at en politik virker for laptop'en og ikke for telefonen. Laptop'en forbinder direkte til routeren, telefonen forbinder til en server, der videresender gennem routeren, og kun den første vej bevarer den adresse, reglen forventer. Reglen er ikke forkert; den matcher en værdi, der ikke findes længere på det punkt.

Skriv stien ned med kildeadressen, som den ser ud ved hvert håndhævelsespunkt. Det ene diagram løser de fleste af disse tilfælde, før nogen regel redigeres.

Hvad telefonen faktisk skal sende

En telefon, der kun modtager en rute til hjemmets undernet, sender kun det undernets trafik ind i tunnelen. Alt andet forlader via mobilnettet, og derfor virker fildelingen, og internetanmodningerne når aldrig huset.

Fuld tunnel-dækning er en routingbeslutning på klientsiden, og den skal sættes med platformens understøttede mekanisme, ikke antages ud fra den profil, der installeres. Når den er sat, skal ruten tilbage til selve VPN-serveren blive uden for tunnelen, ellers kan klienten ikke opretholde sin egen transport.

DNS fortjener sin egen beslutning, fordi det er den del, der mest sandsynligt afviger fra resten af trafikken. En resolveradresse i profilen er et forslag, som klienter håndterer forskelligt, og en applikation med sin egen krypterede resolver kan tage en helt separat vej. Hvis hjemmets politik afhænger af, at forespørgsler når en bestemt resolver, så håndhæv den, hvor trafikken faktisk passerer, eller accepter, at nogle forespørgsler ikke gør. En forespørgsel, der omgår din resolver, når aldrig en regel skrevet til den.

IPv6 hører i samme afsnit som DNS, ikke i et bilag. En fuld IPv4-tunnel siger intet om AAAA-trafik, og en telefon på et dual-stack-mobilnetværk vil med glæde bruge den oprindelige vej til det. Vælg transport eller blokering eksplicit.

Hvad firewallen kan og ikke kan se

Gatewayen kan handle på det, dens håndhævelsespunkt afslører: adresser, porte, protokol, interface og forbindelsens metadata. En videresendt HTTPS-anmodning udleverer ikke sidens brødtekst eller adgangskoden, blot fordi den krydser hjemmets tunnel.

Den grænse er værd at nævne, fordi formuleringen »send den gennem firewallen« antyder mere inspektion, end en hjemmerouter udfører. En destinationsregel, en DNS-politik og en proxy på applikationslaget er tre forskellige kontroller med tre forskellige udrulningsomkostninger.

Antag ikke, at en funktion, der er konfigureret til hjemmets LAN-klienter, gælder for VPN-interfacet. Zonemedlemskab er et konfigurationsvalg, og et VPN-interface, der ikke er i den rigtige zone, arver ingen af de regler, du testede fra sofaen.

Beslut den afbrudte tilstand

Når tunnelen ikke er tilgængelig, falder telefonen enten tilbage til mobilnettet eller nægter at sende trafikken. Begge er rimelige, og kun én af dem svarer til det, de fleste tror, de har konfigureret.

Tilbagefald er bekvemt og lækker per definition: i det øjeblik tunnelen falder, forlader anmodningerne via operatørens vej. Blokering er stærkere og gør telefonen afhængig af, at huset er tilgængeligt, hvilket er en reel tilgængelighedsomkostning for en, der rejser. Ingen af adfærdene er en fejl; begge er produkter, og du vælger mellem dem, uanset om du siger det.

Test valget i stedet for at antage det. Stop hjemmets tjeneste, prøv så én anmodning fra telefonens browser og én fra en app, der kører i baggrunden. At genoprette forbindelsen senere gør ikke de anmodninger, der allerede er gået ud, ugjorte.

Afslut med to kontrollerede tjek fra telefonen selv: én tilladt handling, der skal gå gennem huset, og én afvisning, som hjemmets politik skal håndhæve. Bekræft, at gatewayen loggede det flow, du forventede, i den adressefamilie, du forventede, efter en genoprettet forbindelse. En telefon, der viser Forbundet, er begyndelsen på den verifikation, aldrig slutningen.