VPN-clients en het LAN: wanneer je een aparte zone gebruikt

De tunnelinterface in de LAN-zone zetten is de kortste weg naar een werkende VPN, en meestal is dat de verkeerde standaardinstelling. Het geeft de externe client hetzelfde vertrouwen als het bekabelde LAN, wat de taak zelden vereist. Een aparte zone kost een paar regels en maakt de grens zichtbaar. De beslissing is niet of zones beter zijn; ze is welke drie voorwaarden op jouw netwerk van toepassing zijn.

De zonenaam versleutelt niets en authenticeert geen gebruiker. Hij groepeert alleen interfaces voor het beleidsmodel van de firewall.

Wat zone-lidmaatschap werkelijk bestuurt

Een zone groepeert interfaces of verkeer binnen het model van de firewall. De instellingen voor input, output en forward bepalen vervolgens verschillende rollen. Input is verkeer naar de router zelf; forward is verkeer dat erdoorheen naar een andere host gaat. De zonedocumentatie van OpenWrt behandelt input, output en forward precies daarom als afzonderlijke instellingen.

Een toestemming van de VPN-zone naar de LAN-zone is niet automatisch een omgekeerde toestemming. Forwardregels zijn gericht, en een regel die verkeer van client naar server toestaat, staat geen sessies van server naar client toe. Een client die een verbinding naar een server kan openen, is geen client waar de server een verbinding terug naartoe kan openen.

Dat onderscheid is de reden dat een aparte zone nuttig is: je kunt elke richting en elke rol expliciet benoemen. Schrijf de richting naast elke regel.

Beslissing één: input, forward of beide

Als externe clients DNS van de router nodig hebben, sta dan input alleen voor die dienst toe. Als ze een fileserver moeten bereiken, sta dan forward naar die bestemming toe. De meeste VPN-ontwerpen hebben beide nodig, maar voor verschillende diensten.

Brede inputtoegang tot elke lokale dienst is bijna nooit nodig. Behandel routerbeheer als een aparte beslissing van toegang tot applicaties. Als de router alleen DNS hoeft te beantwoorden, schrijf die ene toestemming op en laat de rest dicht.

Beslissing twee: welke resources externe clients nodig hebben

Inventariseer de clientbereiken, de bestemmingen en de diensten die de VPN moet bieden voordat je regels schrijft. Een bestemmingslijst is nuttiger dan een vertrouwenslabel, omdat die een firewallmigratie overleeft.

Houd beheerinterfaces gescheiden van gewone toegang tot applicaties. Een externe client die een wiki bereikt, heeft daardoor nog niet de beheerpagina van de router of de console van de hypervisor nodig.

Als een toegestane bestemming verder kan doorsturen, stopt de zonegrens bij de firewall, niet bij wat de bestemming daarna doet.

Beslissing drie: hoe je de grens bewijst

Test na elke wijziging een toegestane stroom en een bewust geweigerde. Bewijzen dat één website laadt, onthult geen onbedoelde brede toestemming. Test vanaf het adresbereik van de VPN-client, niet vanaf het LAN, en neem de richting mee waarvan je verwacht dat die faalt. Noteer beide resultaten naast de regel.

Behoud de herstelmogelijkheid van de gateway voordat je het beleid van de externe zone wijzigt. Gebruik de blijvende beheerde configuratie in plaats van wijzigingen tijdens runtime, anders herstelt de volgende herstart het oude vertrouwen. Een kopie van de vorige configuratie, buiten het apparaat bewaard, is de goedkoopste terugdraai die je ooit krijgt.

Als het netwerk groeit, documenteer dan lidmaatschap en het doel van de regels. Een nieuw aangesloten interface mag geen rechten erven alleen omdat iemand er een handige zonenaam aan gaf.