De adminpagina van de router opent in twee seconden vanaf de bank en loopt vanaf een hotelkamer in een time-out, terwijl de VPN-client de hele tijd meldt dat hij verbonden is. Wat je hebt is een weg naar buiten, geen weg terug: de tunnel brengt je verkeer naar het internet en stopt daar. Om een apparaat in je eigen LAN te bereiken is een sessie nodig die eindigt op iets met een route ernaartoe. Dat is een ontwerpkeuze, geen instelling, en die bepaalt of de rest van het werk überhaupt mogelijk is.

Het onderscheid raakt makkelijk zoek omdat één product beide taken kan doen. Een commerciële uitgangsclient en een server voor toegang op afstand kunnen hetzelfde protocol op dezelfde poort spreken, en het verschil is welke kant de adresruimte achter het eindpunt bezit.

Welke kant van de tunnel bezit het LAN

Voor beheer moet het eindpunt in het netwerk liggen dat je wilt bereiken, of een geautoriseerde route daarnaartoe hebben. Een router met een eigen VPN-server voldoet; een kleine altijd aanwezige host met een vast adres en een route naar het LAN ook. Een uitgangsdienst van een derde partij voldoet niet, omdat het eindpunt geen interface op je LAN heeft en geen regel die er een zou laten verschijnen. Dit is de controle die klaar moet zijn voordat je iets anders aanraakt.

Firmware labelt dat verschil zelden, dus lees wat de functie doet in plaats van welk protocol hij noemt. WireGuard, OpenVPN en IKEv2 komen allemaal aan beide kanten van de markt voor: de ene build stuurt huisverkeer naar buiten, de andere accepteert je apparaat op afstand. Een build met alleen een client kan niet via configuratie een server worden, hoe het menu ook is geformuleerd.

De terugroute laten bestaan

Een WireGuard-server op de router heeft een interfaceadres zoals 10.8.0.1/24 en een peer-regel voor de laptop. De client bepaalt welke bestemmingen hij de tunnel in stuurt, en een lijst met alleen het tunnelsubnet laat het LAN onzichtbaar, hoe de server ook is geconfigureerd. Beide kanten moeten het eens zijn, en meestal wordt er maar één bewerkt.

wg show wg0 allowed-ips
ip route get 192.168.1.1

Het eerste commando meldt wat elke peer mag versturen vanuit het standpunt van de server; het tweede meldt waar een LAN-adres op de client werkelijk heen zou gaan. Een LAN-bestemming die naar de tunnelinterface oplost is routering die werkt, en een die via de fysieke gateway naar buiten gaat komt nooit aan, wat de firewall ook zegt. Voeg het LAN-prefix toe aan de toegestane lijst van de client en dezelfde twee commando’s worden een verificatiestap in plaats van een diagnose.

Dezelfde sprong voor IPsec-gateways wordt beschreven door de strongSwan-documentatie over doorsturen, waar doorsturen en een source-NAT-regel een tunnelclient met een interne host verbinden. De adressering verschilt; de eis niet.

Wie de adminpagina mag openen

Toegangsbeheer hoort op de router, niet in het voornemen voorzichtig te zijn. Sta alleen de geauthenticeerde tunnelidentiteit of het bronbereik toe dat de pagina nodig heeft, en lees zowel de eigen input-keten van de router als elk doorgestuurd LAN-beleid. Een regel die het bekabelde LAN de adminpagina laat bereiken, zegt niets over een client die op de tunnelinterface aankomt. Schrijf de uitzondering voor een specifieke identiteit en houd daarna een tweede identiteit die geweigerd moet worden.

De luisteraar is de andere helft en is onzichtbaar in de firewall-uitvoer. ss -ltnp toont het adres waaraan de webserver is gebonden, en een dienst die alleen aan het LAN-adres is gebonden antwoordt niet op het tunneladres, hoe toestemmend de regels ook zijn. Hem opnieuw binden of een adres toevoegen is een configuratiewijziging op de router, geen firewallwijziging.

Houd authenticatie en transportvalidatie aan in dezelfde doorgang. Bereikbaar is niet vertrouwd, en elk apparaat binnen een tunnel wordt daarmee geen beheerder. De tunnelreferentie en het routeraccount zijn gescheiden rechten met gescheiden levenscycli, zodat de sleutel van een verloren laptop kan worden ingetrokken zonder het wachtwoord van elke beheerder te resetten.

Testen van buiten, niet vanaf de bank

Test vanaf een netwerk dat je niet beheert. Verbind via de goedgekeurde tunnel, open een nieuwe beheersessie en wijzig iets onschuldigs dat je op de pagina ziet terugkomen. Vanaf de bank bewijs je dat het LAN werkt, wat nooit in twijfel stond.

Test daarna de weigeringen met dezelfde zorg. Probeer de pagina zonder de tunnel en bevestig dat het mislukt, en bevestig dat de beheerdienst helemaal niet luistert op het WAN-adres. Een pagina die alleen niet gelinkt is, is geen toegangsbeheer, en een WAN-luisteraar met een inlogformulier is nog steeds een WAN-luisteraar. Als een wachtwoord het enige is tussen het internet en de console van de router, is het ontwerp een wachtwoord.

Huishoudelijke diensten verdienen een blik terwijl je er bent. Het aanscherpen van beheerregels breekt vaak het gastnetwerk of de resolver die de apparaten van het gezin gebruiken, en dat komt dagen later naar boven als een losstaande klacht.

Een weg terug houden terwijl je dingen verandert

Voordat je routes of tunnelinstellingen op afstand wijzigt, zorg voor een onafhankelijke weg terug. Een bestaande sessie kan de wijziging overleven die nieuwe verbindingen al blokkeert, en precies zo sluiten mensen zichzelf buiten terwijl ze naar een sessie kijken die nog werkt. De opties zijn concreet: een geplande herstart naar een bekende configuratie, console- of fysieke toegang, een tweede tunnel die niet afhangt van de instelling die wordt bewerkt, of out-of-band-beheer waar de hardware dat biedt. Kies er één en bewijs die vóór het onderhoudsvenster, niet erin.

Houd de registratie kort en actueel: welke host de tunnel beëindigt, welke identiteiten de pagina kunnen bereiken, aan welk adres de dienst bindt en hoe een verloren apparaat wordt ingetrokken. Die lijst dient ook als herstelplan, omdat erin staat waar elke afhankelijkheid woont. Een ontbrekende terugroute is een routeringsprobleem om te repareren, en het is nooit een reden om beheer op de WAN te publiceren.

Gerelateerde artikelen