Een apparaat thuis bereiken via een VPN voor externe toegang: vijf poorten

Een commerciële internet-uitgangs-VPN verbergt uw adres; hij verbindt u niet met uw eigen huis. Om de NAS of de printer op een thuisnetwerk te bereiken is een gateway nodig die op dat netwerk staat en een client die daar een tunnel naartoe bouwt. Het pakket moet dan vijf controles doorstaan, en elke mislukking daarvan ziet er van buiten hetzelfde uit.

Poort 1: de client moet de tunnel kiezen

Controleer of het bestemmingsprefix op de client echt de tunnel in wordt gerouteerd. Een split-tunnelprofiel dat alleen het eigen subnet van de VPN pusht, stuurt 192.168.x.x rechtstreeks de lokale interface uit, waar het nergens aankomt. Kijk naar de routingtabel van de client, niet naar de profielnaam.

Dit is de meest voorkomende fout bij telefoonclients, die vaak standaard alleen DNS of alleen één prefix sturen. Ontbreekt de route, dan kan de handshake perfect zijn en het apparaat toch onbereikbaar.

Bevestig dat het pooladres van de client en het thuissubnet elkaar niet overlappen voordat u verder gaat.

Poort 2: de gateway moet doorsturen

De VPN eindigt op een host die het ontsleutelde pakket naar de LAN moet doorsturen. Dat vereist ingeschakelde IP-doorsturing en een firewallbeleid dat de stroom van de VPN-interface naar de LAN-interface toestaat. Op een routerapparaat is dit meestal ingebouwd; op een Linux-doos met strongSwan of WireGuard zijn het twee instellingen die mensen vergeten. Controleer beide voordat u de dienst test, want elk afzonderlijk geeft dezelfde time-out.

Test met een opname op de LAN-interface, want een pakket dat daar nooit verschijnt is gedropt of nooit doorgestuurd.

Dat is een andere fout dan een dienst die de verbinding weigert, en dat onderscheid scheelt veel tijd. Houd de toestemming smal, beperkt tot de dienst en de VPN-pool in plaats van het hele subnet.

Poort 3: het antwoordpad beslist alles

Het doel antwoordt naar het bronadres dat het zag, dat is ofwel het pooladres van de client ofwel de gateway, afhankelijk van of u vertaalt. Als de standaardgateway van het doel de thuisrouter is en die router heeft geen route naar de VPN-pool, dan verlaat het antwoord het netwerk via internet en sterft. Dat is de klassieke eenrichtingsverbinding.

Er bestaan twee legitieme oplossingen: een route voor de pool toevoegen op de LAN-gateway, of source-NAT doen op de VPN-gateway zodat het doel altijd alleen het gatewayadres ziet. De tweede is eenvoudiger en verliest de oorspronkelijke bronidentiteit.

Kies er bewust één en schrijf op welke, want firewallregels en logs hangen ervan af. De strongSwan-doorstuurgids loopt de Linux-kant van die beslissing door.

Poort 4: namen en prefixoverlap

Lokale detectienamen steken geen gerouteerde grens over, dus een apparaat dat binnen het huis als een vriendelijke naam verschijnt, kan via de tunnel onzichtbaar zijn. Zorg voor DNS voor de privézone, of documenteer het adres. Welke naam u ook gebruikt, die moet verwijzen naar iets wat de externe client kan routeren. Daarom kan een apparaat tegelijk bereikbaar zijn via adres en onzichtbaar via naam.

Overlappende prefixen zijn de andere valkuil: als de clientpool 192.168.1.0/24 is en het thuisnetwerk ook, behandelt de client de bestemming als lokaal en stuurt die nooit door de tunnel.

Hernummer één kant, of gebruik een pool uit een bereik dat u thuis nooit tegenkomt.

Poort 5: test van buiten het huis

Een test uit de keuken bewijst niets, want het verkeer verlaat de LAN misschien nooit. Verbind vanaf een mobiele hotspot of een ander netwerk en loop de poorten op volgorde door: route op de client, opname op de LAN-interface, antwoord van de dienst, opname van het antwoord en naamresolutie. De eerste poort die geen bewijs oplevert is waar het werk zit.

Als de dienst antwoordt maar de naam niet, hebt u een DNS-probleem en geen tunnelprobleem.

Bewaar de werkende configuratie in een notitie met de pool, de route en de NAT-keuze, want de volgende routervervanging reset alle drie.