Blokkeer één bestemmingsbereik voor elke VPN-clientpool

Eén regel kan een toegestane VPN-pool weghouden van een bestemmingsbereik zonder iets anders te verstoren wat de gateway doet. De regel zelf is kort; wat bepaalt of hij werkt, zijn de hook waarin hij leeft en zijn positie in de keten. Wie die twee verkeerd doet, krijgt een firewall die er correct uitziet en zich inconsistent gedraagt. Begin bij wat het pakket doet wanneer de regel het ziet.

Wat de regel werkelijk matcht

De regel matcht drie dingen tegelijk: een invoerinterface, een bronprefix en een bestemmingsprefix. Alle drie moeten waar zijn voordat de drop geldt, en dat houdt hem smal. Hem als één expressie lezen is eenvoudiger dan als drie aparte beleidsregels.

De interface-match is wat doorgestuurd clientverkeer onderscheidt van de eigen verbindingen van de gateway. Zonder die match zou een regel die alleen de bronpool noemt ook pakketten raken die de gateway zelf vanaf dat adres genereert, als dat ooit gebeurt. Het bronprefix beperkt het beleid tot toegestane clients, en het bestemmingsprefix beperkt het tot één bereik. Lees de regel als een doorsnede en niet als een lijst.

Schrijf de drie waarden op voordat u iets wijzigt: de naam van de tunnelinterface, de pool die de server uitgeeft, en het prefix dat u wilt weigeren. Een typefout in een van die drie levert een regel op die netjes parseert en niets beschermt. Houd die drie waarden bij in het wijzigingsrecord naast de regel.

De hook bepaalt voor wie de regel geldt

Een netfilter-keten hangt aan een hook, en de hook bepaalt welke pakketten de keten überhaupt ziet. De forward-hook ziet verkeer dat via de gateway wordt gerouteerd, en dat is precies client-naar-bestemming-verkeer. Al het andere in de keten richt zich op een ander publiek.

De input-hook ziet verkeer dat aan de gateway zelf is geadresseerd, dus een regel die daar staat regelt de toegang tot zijn eigen diensten en niet het transitverkeer. De output-hook ziet verkeer dat de gateway zelf opwekt, wat het tegenovergestelde is van wat een clientpoolbeleid nodig heeft. Ketennamen zijn willekeurige labels die de auteur van de ruleset heeft gekozen, dus leid de hook niet af uit de naam. Controleer waar de keten aan hangt voordat u aanneemt wat hij kan matchen.

De aansluiting lezen is een controle van één regel die voorkomt dat een regel belandt in een keten die het pakket nooit ziet.

Plaats de regel vóór de brede accept

Regels worden op volgorde geëvalueerd en het eerste oordeel wint. Een brede accept eerder in de keten beëindigt de evaluatie voor de pakketten die hij matcht, dus een drop die daarna wordt toegevoegd, draait daar nooit voor. Die volgorderegel is de hele reden dat een correct uitziende regel geen effect kan hebben.

Voeg de regel vóór de accept in in plaats van hem achteraan toe te voegen. Bevat de keten al een algemene accept voor de tunnelinterface, dan moet de nieuwe regel daarvoor staan, anders is hij alleen decoratief. Controleer de resulterende volgorde en niet het bestand dat u hebt bewerkt, want een ruleset die uit meerdere bestanden is samengesteld, komt misschien met geen enkel daarvan overeen. Bevestig daarna met een testpakket uit de pool.

sudo nft list chain inet filter forward
sudo nft insert rule inet filter forward iifname "tun0" ip saddr 10.90.0.0/24 ip daddr 198.51.100.0/24 drop
sudo nft -c -f /etc/nftables.conf

Het derde commando parseert het bestand zonder het toe te passen, wat syntaxisfouten opvangt voordat ze een storing worden. Pas het toe met een terugdraaiplan, want een verkeerde regel in een forward-keten kan de tunnel doorknippen waarover u werkt.

Bestaande stromen trekken zich niets aan van uw nieuwe regel

Een conntrack-item dat is aangemaakt voordat de regel bestond, blijft overeenkomen met de eerdere accept. Daarom lijkt een nieuwe drop soms te werken voor nieuwe verbindingen en niets te doen voor degene die wordt getest.

Lees de state-match bovenaan de keten. Als die established en related verkeer accepteert vóór uw regel, blijft elke stroom die al loopt doorlopen tot hij sluit. Dat is meestal het gedrag dat u voor een noodregel wilt, en het is verwarrend wanneer u een onmiddellijke afsnijding verwacht. Bepaal welk effect u wilt voordat u uitrolt. Een test die een open verbinding hergebruikt, vertelt u het verkeerde verhaal.

sudo conntrack -L -s 10.90.0.14 -d 198.51.100.20
sudo nft list ruleset | grep -n -A3 'ct state'

Het eerste commando laat zien of er een stroom is, en het tweede of een vroege stateregel die nog accepteert. Beide zijn alleen-lezen en veilig om te draaien tijdens een incident.

Wat deze regel niet is

De regel is geen domeinblacklist, geen IPv6-beleid en geen beperking op een afzonderlijk applicatieaccount.

Elk daarvan vereist zijn eigen mechanisme. Een domeinblokkade moet namen oplossen, wat een packetfilter niet doet. IPv6-verkeer heeft zijn eigen match nodig, omdat een ip-expressie niets zegt over ip6-pakketten. Een beperking op applicatieniveau hoort bij de dienst of bij een geauthenticeerde proxy, niet bij een prefixmatch. Juist het gescheiden houden van die eisen voorkomt dat één smalle regel vier taken krijgt.

Het contract dat deze regel levert, is precies: verkeer van een toegestane pool naar één bestemmingsprefix wordt geweigerd, terwijl niet-gerelateerd verkeer van de gateway zijn bestaande beleid houdt. Schrijf die zin naast de regel, en de volgende persoon weet waarvoor hij diende.