OpenWrt VPN-zone, doorsturen en masquerading: welke heb je nodig?

Drie wijzigingen raken door elkaar zodra een VPN OpenWrt tegenkomt: een poort openen, doorsturen toestaan en masquerading aanzetten. Ze beantwoorden verschillende vragen, en meestal is maar één ervan de echte eis. Elke regel lezen naar de verkeersrol die hij bestuurt maakt van een gok een beslissing, en vertelt ook welk symptoom je moet verwachten als de wijziging verkeerd is. Begin met de rol die faalde te benoemen, niet met het vinkje dat je onthoudt.

Benoem de verkeersrol voordat je een regel aanraakt

Zone-invoer bepaalt wat de router zelf mag bereiken. Zone-uitvoer omvat verkeer dat de router zelf maakt, zone-doorsturen is de standaard voor verkeer dat door een zone gaat, en masquerading bepaalt of het bronadres onderweg naar buiten wordt herschreven. Dat zijn vier verschillende vragen, en een zonebeleid beantwoordt ze allemaal tegelijk met dezelfde waarde, daarom is een wijziging voor de hele zone een grof middel. Een benoemde regel kan er één beantwoorden zonder de rest aan te raken.

De bruikbare kaart is naar verkeersrol, want dat is wat je kunt waarnemen als er iets misgaat. Elke rol hieronder heeft één regel die hem bepaalt en één symptoom dat erop wijst:

Een luisteraar op de router heeft één smalle invoerregel nodig

Een OpenVPN-server op de router ontvangt verkeer dat aan de router is gericht, dus zijn buitenste verbinding hangt af van het invoerbeleid van de zone die hem draagt. Sta het geconfigureerde transport en de poort toe en laat al het overige in die zone geweigerd. Eén poortregel is een veel kleinere wijziging dan een toestemming voor de hele zone, en dat is degene die je over een jaar nog kunt uitleggen.

Twee dingen maken die regel veilig om te houden: hij noemt de poort die de dienst echt gebruikt, en hij staat naast de zonedeclaratie zodat de volgende persoon ziet waarom hij bestaat. De regels hieronder zijn de vorm, waarbij de poort staat voor wat op de server is geconfigureerd. Wijzig die poort op beide plaatsen wanneer de dienst verhuist, want een regel die op de oude blijft staan is onzichtbaar tot een audit.

config zone
    option name 'wan'
    option input 'REJECT'
    option forward 'REJECT'
    option output 'ACCEPT'
    option masq '1'

config rule
    option name 'allow-openvpn'
    option src 'wan'
    option proto 'udp'
    option dest_port '1194'
    option target 'ACCEPT'

Valideer voordat je herlaadt, want een syntaxisfout in een firewallbestand kan de router achterlaten zonder werkende regelset. In een release met fw4 is de controle een apart commando, en het faalt luid in plaats van stilzwijgend een kapot blok te accepteren. Herlaad pas nadat de controle slaagt, en bewaar het vorige bestand waar je het terug kunt zetten.

fw4 check
service firewall reload

Een cliëntverzoek gaat door doorsturen, niet door invoer

Na authenticatie levert een verzoek van een tunnelcliënt om een LAN-dienst een doorgestuurde stroom op, dus de regel die dat bepaalt is de doorstuurrelatie tussen de tunnelzone en de LAN-zone. Wijs de tunnelinterface toe aan de bedoelde zone en verklaar daarna de richting, de bronnen en de dienst. De zonetoewijzing is wat de doorstuurregel betekenis geeft, en beide zijn alleen samen gelezen zinvol. Een doorstuurrelatie die de tunnelzone als bron en de LAN-zone als bestemming noemt, leest als één bewuste beslissing, terwijl twee toestemmingen voor de hele zone als een ongeluk lezen.

De router zelf bereiken gebruikt nog steeds het invoerpad, daarom zegt een ping naar de gateway niets over de bestandsshare erachter. Die twee fouten leven in verschillende blokken en worden met verschillende wijzigingen verholpen. Schrijf beide paden apart op voordat je een van beide wijzigt.

Masquerading is een routingbeslissing, geen toestemming

Masquerading herschrijft het bronadres van geselecteerd uitgaand verkeer. Het kan een uitgangsontwerp redden waarbij de verre kant geen retourroute heeft, en het verbergt ook de adressen van individuele cliënten voor elke dienst die adressen logt of op adres autoriseert. Het uitzetten is een routingkeuze over de retourweg, geen beveiligingsschakelaar die een inkomend gat dicht. Een tunnel die werkt met vertaling aan en faalt op het moment dat die wordt uitgezet, mist meestal een retourroute, niet een firewallregel.

Het gerouteerde alternatief vereist een retourroute aan de verre kant in plaats van vertaling. Geen van beide opties levert de firewalls toestemming of het applicatieaccount, daarom lost het uitzetten van masquerading bijna nooit een tunnelcliënt op die nergens komt. Behandel ook het IPv4- en IPv6-beleid apart, want één vertaalinstelling beschrijft niet beide families.

Bewijs de beslissing met een toegestaan en een geweigerd verzoek

Stuur één verzoek dat toegestaan zou moeten worden en één dat geweigerd zou moeten worden, en bepaal daarna de regel die elke beslissing nam. Een pagina die toevallig laadt is geen bewijs; het bewijs is de regel die overeenkwam, in de keten waarin die overeenkwam. De weigering telt even zwaar als het succes, want ze toont dat het beleid iets doet in plaats van dat alles is toegestaan.

Twee commando’s geven je dat bewijs op een huidige release. De teller op de overeenkomende regel beweegt wanneer het verzoek wordt geaccepteerd, en de log toont de drop als je logging voor de regel hebt aangezet:

nft list chain inet fw4 forward_wan
logread -f | grep -i -E 'DROP|REJECT'

Houd een beheerpad dat je nog kunt gebruiken voordat je enig firewallbeleid wijzigt, en volg het validatie- en terugdraaiproces van de eigenaar van de configuratie. Een wijziging die je buiten de router sluit is geen testresultaat, het is een tweede incident. Noteer de zone en de verkeersrol naast elke waarneming, zodat het resultatenpaar het beleid uitlegt in plaats van een gelukkige paginalading te beschrijven.