Een OpenVPN-gateway met UFW-regels tot één LAN beperken

Bepaal de toestemming voordat u een firewallbestand opent: geauthenticeerde clients mogen verbindingen openen naar één bepaald subnet, en de gateway moet elk ander doorvoerpad weigeren, ook wanneer een client extra routes installeert. Die zin is het ontwerp, en elke regel hieronder bestaat om die af te dwingen. Iets breders, zoals de hele private adresruimte, internetuitgang door de tunnel of peer-to-peerverkeer, is een ander ontwerp dat zijn eigen beslissing nodig heeft. De regels zijn ook bewust saai, want een slimme firewall is er een die niemand later kan auditen.

Schrijf eerst de topologie en de toestemming op

Het voorbeeld gebruikt een Community OpenVPN server met een TUN-apparaat in de gebruikersruimte genaamd tun0, een clientpool 10.77.0.0/24, en één aangesloten subnet 192.168.60.0/24 op lan0. IPv4-doorsturen werkt al en het LAN heeft al een retourroute naar de pool, dus niets hier hangt af van vertaling tussen beide.

UFW bezit de firewall op deze host, en geen containerregelset of aparte nftables-tabel mag een eerder acceptatiepad installeren. Een flow-offload-shortcut die het filter overslaat zou de wachtketens tot decoratie maken, dus bevestig dat geen enkele actief is. Laat de eigen client-to-client-doorsturing van OpenVPN uitgeschakeld, want peer-to-peerverkeer dat nooit het filter van het besturingssysteem passeert kan daarmee niet worden begrensd. De externe luisteraar en de beheersregels blijven zoals ze zijn, omdat deze wijziging ontsleuteld tunnelverkeer regelt in plaats van de firewall te vervangen.

Plaats de wachten vóór de vroege acceptaties van UFW

Een routetoestemming gevolgd door een weigering is niet genoeg voor een strikte grens. De standaard before-regels accepteren gevestigd verkeer en bepaalde ICMP voordat enige gebruikersregel wordt bekeken, dus een flow die vorige week werd toegestaan kan buiten de nieuwe bestemmingsbeperking blijven puur omdat hij nog toestand heeft. Maak een back-up van de UFW-bestanden en houd een out-of-bandconsole open voordat u gaat bewerken.

In de sectie *filter van het bestand /etc/ufw/before.rules, declareer twee ketens naast de bestaande declaraties en vóór elke regelregel.

:vpn-src-guard - [0:0]
:vpn-reply-guard - [0:0]

Spring er direct na de declaraties, en vóór de toestemmingen voor invoer en doorsturen, in en definieer wat ze doorlaten.

-A ufw-before-input -i tun0 -j DROP
-A ufw-before-forward -i tun0 -j vpn-src-guard
-A ufw-before-forward -o tun0 -j vpn-reply-guard

-A vpn-src-guard -o lan0 -d 192.168.60.0/24 -s 10.77.0.0/24 -m conntrack --ctdir ORIGINAL -j RETURN
-A vpn-src-guard -j DROP

-A vpn-reply-guard -i lan0 -d 10.77.0.0/24 -s 192.168.60.0/24 -m conntrack --ctstate RELATED,ESTABLISHED --ctdir REPLY -j RETURN
-A vpn-reply-guard -j DROP

Behoud de rest van de sectie en zijn COMMIT -regel. Een tweede filtertabel plakken of niet-verwante regels verwijderen is de manier waarop een firewallwijziging een storing wordt, en het bestand is één herstart verwijderd van de enige kopie die ertoe doet.

Lees wat elke wacht doorlaat en weigert

De eerste keten gaat alleen door met verwerken wanneer de bron in de pool zit, de bestemming het ene subnet is, de uitgangsinterface het LAN is en het pakket in de oorspronkelijke richting van zijn flow reist. Al het andere dat uit de tunnel komt wordt weggegooid, inclusief een bron buiten de pool en elke bestemming voorbij het toegestane subnet.

Een peer-to-peerpakket komt binnen en gaat uit tun0, dus het faalt op de LAN-interfacetest nog voordat een bestemmingscontrole wordt bereikt. Nieuwe verbindingen van het LAN naar clients falen ook op de antwoordrichtingstest, wat het omgekeerde terugbelpad standaard sluit.

Het doel RETURN houdt het gewone UFW-beleid in werking. Deze ketens filteren, en de routetoestemming die u daarna toevoegt bepaalt nog steeds of een overlevend pakket wordt geaccepteerd. Precies die scheiding maakt het mogelijk om later het toegestane subnet op één plek te wijzigen. Als de wachten pakketten meteen zouden accepteren, zou elke toekomstige regel twee keer moeten worden toegevoegd.

Autoriseer het subnet en sluit de zijdeuren

Bekijk eerst een voorbeeld van de routetoestemming en verwijder dan de voorbeeldvlag om hem toe te passen: sudo ufw --dry-run route allow in on tun0 out on lan0 from 10.77.0.0/24 to 192.168.60.0/24. Controleer daarna de volgorde van de gebruikersregels, want een eerdere weigering wint nog steeds van een latere toestemming. Een toestemming voor het hele subnet is ook de verkeerde vorm wanneer alleen de HTTPS-poort van één host bereikbaar moet zijn.

Let op wat de invoer-drop doet: tunnelclients bereiken geen enkele dienst op de gateway zelf, inclusief een DNS-listener die aan zijn LAN-adres is gebonden. DNS daar hosten vereist een bewuste uitzondering vóór de drop en een herzien toestemmingscontract. Als UFW IPv6 beheert, voeg dan ook passende drops toe voor tun0 in before6.rules, want een lijst met IPv4-bestemmingen zegt niets over IPv6-pakketten.

Verifieer het geladen beleid, niet het voorbeeld

Bekijk het herladen in voorbeeld, pas het toe in een onderhoudsvenster en lees de live regelset.

sudo ufw --dry-run reload
sudo ufw show raw

Bevestig dat de tunnelwachten verschijnen vóór de standaardtoestemmingen voor status en ICMP. Een gewone ufw status toont handmatig bewerkte before-regels niet, waardoor beheerders concluderen dat een regel ontbreekt terwijl die in werkelijkheid is geladen. Lees de ruwe lijst van boven naar beneden in plaats van naar een fragment te zoeken. Als de wachten na een statustoestemming verschijnen, doet de grens niet wat het bestand suggereert.

Test daarna gedrag in plaats van tekst. Open een nieuwe verbinding naar een toegestane host en kijk naar het antwoord, stuur een onschuldig verzoek naar een bestemming buiten het subnet en bevestig dat het sterft, probeer een peer-to-peerverbinding, probeer een dienst die lokaal op de gateway is en probeer een ongevraagde LAN-naar-clientverbinding. Neem één flow buiten bereik op die bestond vóór de wijziging, en wis alleen die flow in plaats van de hele volgtabel van de machine te legen.

Noteer de grenzen naast de regels: dit begrenst doorvoer en niets anders. Het weerhoudt een client er niet van zijn eigen internetverbinding te gebruiken, het weerhoudt een toegestane LAN-host er niet van verkeer verder door te sturen, en het vervangt de authenticatie binnen de toegestane diensten niet.