Telefon-VPN hem: gör brandväggen till din internetutgång

Att ansluta en telefon till hemmets tunnel och öppna en LAN-fildelning bevisar att tunneln fungerar. Det bevisar inte att telefonens internetförfrågningar lämnar huset. Skillnaden mellan dessa två resultat är en vidarebefordringspolicy plus en rutt, inte ännu en kryssruta på telefonen. Det är också skillnaden som de flesta antar att de redan har konfigurerat.

Tre beslut skapar utgångsvägen: vad telefonen skickar in i tunneln, vart hemmagatewayen vidarebefordrar det och vad som händer när tunneln inte finns. Var och en har ett felläge som från telefonskärmen ser ut som de andras.

Två hopp, två policyer

Den yttre anslutningen slutar vid hemmets VPN-lyssnare. Det inre paketet är ett separat objekt som måste vidarebefordras någonstans, och vidarebefordran är ett annat brandväggsbeslut än att acceptera tunneln från början.

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

På en typisk hemrouter bor dessa i olika regeluppsättningar. Att acceptera tunneln är ingångspolicy på VPN-gränssnittet; att skicka telefonens trafik ut på internet är vidarebefordringspolicy plus den källöversättning som upplänken behöver. En router som accepterar tunneln och inte vidarebefordrar något ger en telefon som visar ansluten och inte laddar några sidor.

Om VPN-tjänsten körs på en separat maskin inne i huset, lägg till ett hopp. Routern ser nu trafik som kommer från den maskinen, så dess regler gäller serverns adress i stället för telefonens tunneladress, och källöversättning kan få varje telefon att se ut som en enda värd.

Lyssnaren är inte filtret

Bestäm var efterlevnaden sker medan informationen du behöver fortfarande finns. På routern är telefonens tunneladress synlig och kan matchas direkt. Bakom en andra översättning är den borta, och regler skrivna för telefonens adress matchar tyst ingenting.

Detta är det vanliga skälet till att en policy fungerar för laptopen och inte för telefonen. Laptopen ansluter direkt till routern, telefonen ansluter till en server som vidarebefordrar genom routern, och bara den första vägen bevarar adressen som regeln förväntar sig. Regeln är inte fel; den matchar ett värde som inte längre finns vid den punkten.

Skriv ner vägen med källadressen som den ser ut vid varje efterlevnadspunkt. Det enda diagrammet löser de flesta av dessa fall innan någon regel redigeras.

Vad telefonen faktiskt måste skicka

En telefon som bara tar emot en rutt till hemmets subnät skickar bara det subnätets trafik in i tunneln. Allt annat går ut över mobilnätet, och därför fungerar fildelningen och internetförfrågningarna når aldrig huset.

Full tunneltäckning är ett routingbeslut på klientsidan, och det måste ställas in med plattformens stödda mekanism, inte antas från profilen som installeras. När den är inställd måste vägen tillbaka till själva VPN-servern stanna utanför tunneln, annars kan klienten inte upprätthålla sin egen transport.

DNS förtjänar ett eget beslut, eftersom det är den del som mest sannolikt avviker från resten av trafiken. En resolveradress i profilen är ett förslag som klienter hanterar olika, och en applikation med egen krypterad resolver kan ta en helt separat väg. Om hemmets policy bygger på att förfrågningar når en viss resolver, genomdriv den där trafiken faktiskt passerar, eller acceptera att vissa förfrågningar inte gör det. En förfrågan som kringgår din resolver når aldrig en regel skriven för den.

IPv6 hör till samma stycke som DNS, inte till en bilaga. En fullständig IPv4-tunnel säger ingenting om AAAA-trafik, och en telefon på ett dual-stack-mobilnät använder gärna den inhemska vägen för det. Välj transport eller blockering uttryckligen.

Vad brandväggen kan och inte kan se

Gatewayen kan agera på det som dess efterlevnadspunkt avslöjar: adresser, portar, protokoll, gränssnitt och anslutningens metadata. En vidarebefordrad HTTPS-förfrågan lämnar inte ut sidans brödtext eller lösenordet bara för att den korsar hemmets tunnel.

Den gränsen är värd att nämna, eftersom formuleringen ”skicka den genom brandväggen” antyder mer inspektion än en hemrouter utför. En destinationsregel, en DNS-policy och en proxy på applikationslagret är tre olika kontroller med tre olika driftsättningskostnader.

Anta inte att en funktion som konfigurerats för hemmets LAN-klienter gäller för VPN-gränssnittet. Zonmedlemskap är ett konfigurationsval, och ett VPN-gränssnitt som inte ligger i rätt zon ärver ingen av de regler du testade från soffan.

Bestäm det frånkopplade läget

När tunneln inte är tillgänglig faller telefonen antingen tillbaka till mobilnätet eller vägrar skicka trafiken. Båda är rimliga, och bara en av dem stämmer med vad de flesta tror att de har konfigurerat.

Återfall är bekvämt och läcker per definition: ögonblicket då tunneln faller är ögonblicket då förfrågningarna lämnar operatörens väg. Blockering är starkare och gör telefonen beroende av att huset är nåbart, vilket är en verklig tillgänglighetskostnad för den som reser. Inget av beteendena är en bugg; båda är produkter, och du väljer mellan dem vare sig du säger det eller inte.

Testa valet i stället för att anta det. Stoppa hemmetjänsten och försök sedan med en förfrågan från telefonens webbläsare och en från en app som körs i bakgrunden. Att ansluta igen senare ångrar inte förfrågningarna som redan har gått ut.

Avsluta med två kontrollerade prov från telefonen själv: en tillåten åtgärd som ska passera huset, och en nekad som hemmets policy ska genomdriva. Bekräfta att gatewayen loggade flödet du förväntade dig, i den adressfamilj du förväntade dig, efter en återanslutning. En telefon som visar Ansluten är början på den verifieringen, aldrig slutet.