Telefoon-VPN naar huis: maak de firewall je internetuitgang

Een telefoon met de thuistunnel verbinden en een LAN-bestandsdeling openen bewijst dat de tunnel werkt. Het bewijst niet dat de internetverzoeken van de telefoon via het huis naar buiten gaan. Het verschil tussen die twee uitkomsten is een doorstuurbeleid plus een route, niet nog een selectievakje op de telefoon. Het is ook het verschil waarvan de meeste mensen aannemen dat ze het al hebben geconfigureerd.

Drie beslissingen produceren het uitgangspad: wat de telefoon de tunnel in stuurt, waar de thuisgateway het doorstuurt, en wat er gebeurt als de tunnel er niet is. Elk heeft een faalmodus die vanaf het scherm van de telefoon op de andere lijkt.

Twee sprongen, twee beleidsregels

De buitenste verbinding eindigt bij de thuis-VPN-listener. Het binnenste pakket is een apart object dat ergens heen moet worden doorgestuurd, en doorsturen is een andere firewallbeslissing dan het accepteren van de tunnel in de eerste plaats.

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

Op een typische thuisrouter leven deze in verschillende regelsets. De tunnel accepteren is ingangsbeleid op de VPN-interface; het verkeer van de telefoon naar het internet sturen is doorstuurbeleid plus de brontranslatie die de uplink nodig heeft. Een router die de tunnel accepteert en niets doorstuurt, levert een telefoon die verbonden toont en geen pagina's laadt.

Als de VPN-dienst op een aparte machine in huis draait, voeg een sprong toe. De router ziet nu verkeer dat van die machine komt, dus zijn regels gelden voor het adres van de server in plaats van het tunneladres van de telefoon, en brontranslatie kan elke telefoon als één host laten lijken.

De listener is niet het filter

Beslis waar de handhaving plaatsvindt terwijl de informatie die je nodig hebt nog bestaat. Op de router is het tunneladres van de telefoon zichtbaar en kan het direct worden gematcht. Achter een tweede translatie is het weg, en regels die voor het adres van de telefoon zijn geschreven, matchen stilzwijgend niets.

Dit is de gebruikelijke reden waarom een beleid voor de laptop werkt en niet voor de telefoon. De laptop verbindt rechtstreeks met de router, de telefoon verbindt met een server die via de router doorstuurt, en alleen het eerste pad bewaart het adres dat de regel verwacht. De regel is niet fout; hij matcht een waarde die op dat punt niet meer bestaat.

Schrijf het pad op met het bronadres zoals het op elk handhavingspunt verschijnt. Dat ene diagram lost de meeste van deze gevallen op voordat een regel wordt bewerkt.

Wat de telefoon werkelijk moet sturen

Een telefoon die alleen een route naar het thuissubnet ontvangt, stuurt alleen het verkeer van dat subnet de tunnel in. Al het andere verlaat het toestel via het mobiele netwerk, waardoor de bestandsdeling werkt en de internetverzoeken het huis nooit bereiken.

Volledige tunneldekking is een routeringsbeslissing aan de clientzijde, en die moet worden ingesteld met het door het platform ondersteunde mechanisme, niet worden aangenomen uit het profiel dat wordt geïnstalleerd. Eenmaal ingesteld moet de route terug naar de VPN-server zelf buiten de tunnel blijven, anders kan de client zijn eigen transport niet onderhouden.

DNS verdient een eigen beslissing, omdat het het deel is dat het meest geneigd is af te wijken van de rest van het verkeer. Een resolveradres in het profiel is een suggestie die clients anders behandelen, en een applicatie met een eigen versleutelde resolver kan een volledig apart pad nemen. Als het thuisbeleid afhangt van het bereiken van een bepaalde resolver, handhaaf het dan waar het verkeer werkelijk langskomt, of accepteer dat sommige query's dat niet zullen doen. Een query die je resolver omzeilt, bereikt nooit een regel die ervoor is geschreven.

IPv6 hoort in dezelfde alinea als DNS, niet in een bijlage. Een volledige IPv4-tunnel zegt niets over AAAA-verkeer, en een telefoon op een dual-stack mobiel netwerk zal daar graag het native pad voor gebruiken. Kies vervoer of blokkering expliciet.

Wat de firewall wel en niet kan zien

De gateway kan handelen op wat zijn handhavingspunt blootlegt: adressen, poorten, protocol, interface en de metadata van de verbinding. Een doorgestuurd HTTPS-verzoek geeft de paginainhoud of het wachtwoord niet prijs alleen omdat het de thuistunnel kruist.

Die grens is het vermelden waard, omdat de uitdrukking „stuur het door de firewall“ meer inspectie impliceert dan een thuisrouter uitvoert. Een bestemmingsregel, een DNS-beleid en een proxy op applicatieniveau zijn drie verschillende controles met drie verschillende implementatiekosten.

Neem niet aan dat een functie die voor thuis-LAN-clients is geconfigureerd, ook voor de VPN-interface geldt. Zone-lidmaatschap is een configuratiekeuze, en een VPN-interface die niet in de juiste zone zit, erft geen van de regels die je vanaf de bank hebt getest.

Beslis de losgekoppelde toestand

Wanneer de tunnel niet beschikbaar is, valt de telefoon terug op het mobiele netwerk of weigert hij het verkeer te sturen. Beide zijn redelijk, en slechts één ervan komt overeen met wat de meeste mensen denken te hebben geconfigureerd.

Terugvallen is handig en lekt per definitie: het moment dat de tunnel wegvalt, is het moment waarop verzoeken via het pad van de provider naar buiten gaan. Blokkeren is sterker en maakt de telefoon afhankelijk van de bereikbaarheid van het huis, wat een echte beschikbaarheidskostenpost is voor iemand die reist. Geen van beide gedragingen is een bug; beide zijn producten, en je kiest ertussen of je dat nu zegt of niet.

Test de keuze in plaats van hem aan te nemen. Stop de thuisdienst en probeer dan één verzoek vanuit de browser van de telefoon en één vanuit een app die op de achtergrond draait. Later opnieuw verbinden maakt de verzoeken die al zijn vertrokken niet ongedaan.

Sluit af met twee gecontroleerde controles vanaf de telefoon zelf: één toegestane bewerking die het huis moet passeren, en één weigering die het thuisbeleid hoort af te dwingen. Bevestig dat de gateway de stroom heeft gelogd die je verwachtte, in de adresfamilie die je verwachtte, na opnieuw verbinden. Een telefoon die Verbonden toont, is het begin van die verificatie, nooit het einde.