Foon-VPN na die huis: maak die firewall jou internetuitgang

Om 'n foon aan die tuistonnnel te koppel en 'n LAN-lêerdeling oop te maak, bewys dat die tonnel werk. Dit bewys nie dat die foon se internetversoeke deur die huis verlaat nie. Die verskil tussen dié twee uitkomste is 'n aanstuurbeleid plus 'n roete, nie nog 'n merkblokkie op die foon nie. Dit is ook die verskil wat die meeste mense aanneem hulle het reeds opgestel.

Drie besluite lewer die uitgangspad: wat die foon in die tonnel stuur, waar die tuispoort dit aanstuur, en wat gebeur wanneer die tonnel nie daar is nie. Elk het 'n foutmodus wat van die foon se skerm soos die ander lyk.

Twee spronge, twee beleide

Die buitenste verbinding eindig by die tuis-VPN-ontvanger. Die binneste pakket is 'n aparte objek wat êrens heen aangestuur moet word, en aanstuur is 'n ander firewall-besluit as om die tonnel in die eerste plek te aanvaar.

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

Op 'n tipiese tuisroeteerder woon hierdie in verskillende reëlstelle. Om die tonnel te aanvaar is insetbeleid op die VPN-koppelvlak; om die foon se verkeer na die internet uit te stuur is aanstuurbeleid plus watter bronvertaling die opvoerlyn ook al nodig het. 'n Roeteerder wat die tonnel aanvaar en niks aanstuur nie, lewer 'n foon wat wys dit is gekoppel en geen bladsye laai nie.

As die VPN-diens op 'n aparte masjien binne die huis loop, voeg 'n sprong by. Die roeteerder sien nou verkeer wat van daardie masjien af kom, so sy reëls geld vir die bediener se adres eerder as vir die foon se tonneladres, en bronvertaling kan elke foon soos een gasheer laat lyk.

Die ontvanger is nie die filter nie

Besluit waar die handhawing gebeur terwyl die inligting wat jy nodig het nog bestaan. Op die roeteerder is die foon se tonneladres sigbaar en kan dit direk gepas word. Agter 'n tweede vertaling is dit weg, en reëls wat vir die foon se adres geskryf is, pas stilweg niks.

Dit is die gewone rede waarom 'n beleid vir die skootrekenaar werk en nie vir die foon nie. Die skootrekenaar koppel direk aan die roeteerder, die foon koppel aan 'n bediener wat deur die roeteerder aanstuur, en net die eerste pad bewaar die adres wat die reël verwag. Die reël is nie verkeerd nie; dit pas 'n waarde wat op daardie punt nie meer bestaan nie.

Skryf die pad neer met die bronadres soos dit by elke handhawingspunt verskyn. Daardie enkele diagram los die meeste van hierdie gevalle op voordat enige reël geredigeer word.

Wat die foon werklik moet stuur

'n Foon wat net 'n roete na die tuissubnet ontvang, stuur net daardie subnet se verkeer in die tonnel in. Alles anders verlaat oor die mobiele netwerk, en daarom werk die lêerdeling en bereik die internetversoeke nooit die huis nie.

Volledige tonneldekking is 'n kliëntkant-roetebesluit, en dit moet met die platform se ondersteunde meganisme gestel word, nie aangeneem word uit die profiel wat geïnstalleer word nie. Sodra dit gestel is, moet die roete terug na die VPN-bediener self buite die tonnel bly, anders kan die kliënt nie sy eie transport onderhou nie.

DNS verdien sy eie besluit, want dit is die deel wat die meeste geneig is om van die res van die verkeer af te wyk. 'n Resolver-adres in die profiel is 'n voorstel wat kliënte verskillend hanteer, en 'n toepassing met sy eie geënkripteerde resolver kan 'n heeltemal aparte pad volg. As die tuisbeleid daarop berus dat navrae 'n bepaalde resolver bereik, handhaaf dit waar die verkeer werklik verbygaan, of aanvaar dat sommige navrae dit nie sal doen nie. 'n Navraag wat jou resolver omseil, bereik nooit 'n reël wat daarvoor geskryf is nie.

IPv6 hoort in dieselfde paragraaf as DNS, nie in 'n aanhangsel nie. 'n IPv4-voltonnel sê niks oor AAAA-verkeer nie, en 'n foon op 'n dual-stack mobiele netwerk sal dit graag oor die inheemse pad stuur. Kies vervoer of blokkering uitdruklik.

Wat die firewall kan sien en nie kan sien nie

Die poort kan optree op wat sy handhawingspunt blootlê: adresse, poorte, protokol, koppelvlak en die metadata van die verbinding. 'n Aangestuurde HTTPS-versoek gee nie die bladsy se inhoud of die wagwoord oor bloot omdat dit deur die tuistonnnel gaan nie.

Daardie beperking is die moeite werd om te noem, want die frase “stuur dit deur die firewall” impliseer meer inspeksie as wat 'n tuisroeteerder doen. 'n Bestemmingsreël, 'n DNS-beleid en 'n toepassingslaag-volmagtiging is drie verskillende kontroles met drie verskillende ontplooiingskoste.

Moenie aanneem dat 'n funksie wat vir tuis-LAN-kliënte opgestel is, op die VPN-koppelvlak van toepassing is nie. Sone-lidmaatskap is 'n opstellingskeuse, en 'n VPN-koppelvlak wat nie in die regte sone is nie, erf niks van die reëls wat jy van die rusbank af getoets het nie.

Besluit oor die afgekoppelde toestand

Wanneer die tonnel onbeskikbaar is, val die foon óf terug op die mobiele netwerk óf weier om die verkeer te stuur. Albei is redelik, en net een daarvan stem ooreen met wat die meeste mense dink hulle opgestel het.

Terugval is gerieflik en lek per definisie: die oomblik wanneer die tonnel val, is die oomblik wanneer versoeke oor die draerpad vertrek. Blokkering is sterker en maak die foon afhanklik daarvan dat die huis bereikbaar is, wat 'n werklike beskikbaarheidskoste vir iemand op reis is. Nie een van die twee gedrag is 'n fout nie; albei is produkte, en jy kies tussen hulle of jy dit sê of nie.

Toets die keuse eerder as om dit aan te neem. Stop die tuisdienst, probeer dan een versoek vanuit die foon se blaaier en een vanuit 'n toepassing wat in die agtergrond loop. Later weer koppel maak nie die versoeke wat reeds vertrek het, ongedaan nie.

Sluit af met twee beheerde kontroles van die foon self: een toegelate handeling wat deur die huis moet beweeg, en een weiering wat die tuisbeleid veronderstel is om af te dwing. Bevestig dat die poort die vloei aangeteken het wat jy verwag het, in die adresfamilie wat jy verwag het, ná 'n herkoppeling. 'n Foon wat Gekoppel wys, is die begin van daardie verifikasie, nooit die einde daarvan nie.