IPv6 blokkeren om WireGuard dicht te zetten sloopt de host

Het doel is redelijk: alleen tunnelgebruikers zouden de diensten op deze machine moeten bereiken. De implementatie waar mensen naar grijpen is een IPv6-inputketen die alles behalve WireGuard laat vallen, en daarmee ook het verkeer dat de host aan zijn eigen link verbonden houdt. Buurontdekking en berichten voor padonderhoud zijn geen diensttoegang, en ze verwijderen levert een machine op die onbereikbaar is om redenen die niets met je beleid te maken hebben. De tunnel komt op, de diensten zijn correct afgebakend, en niets anders op de link werkt.

Drie verantwoordelijkheden, één regelset

De eerste verantwoordelijkheid is de werking van het buitenste netwerk: de host moet aan zijn link verbonden blijven, buren oplossen en de padgrenzen van die link kennen. De tweede is de versleutelde luisteraar, die UDP accepteert op het adres en de poort die je koos. De derde is de set ontsleutelde diensten die tunnelgebruikers moeten bereiken.

Dat zijn drie verschillende beleidsregels, en alleen de tweede en derde gaan over de VPN. Een regelset die ze als één behandelt, erft een faalmodus waarin het aanscherpen van de applicatiegrens de hostverbinding stil sloopt.

Houd ze in aparte ketens of ten minste aparte commentaren, zodat de volgende persoon ziet welke regel bestaat en waarom.

Wat ICMPv6 voor de host doet

IPv6 leunt voor veel meer dan echo op ICMPv6. Buurverzoek en -aankondiging vervangen ARP en zijn nodig voor lokale aflevering. Packet Too Big draagt MTU-informatie van het pad, en die negeren levert overdrachten op die bij grote pakketten vastlopen. Routeraankondigingen dragen de standaardroute en prefixinformatie wanneer de link automatische configuratie gebruikt.

RFC 4890 scheidt de berichten die een hostfilter moet toestaan van die welke een administratieve keuze zijn, en doet dat in een hostgedeelte dat verschilt van de regels voor een router die tussen netwerken doorstuurt. Alleen het doorstuurgedeelte lezen levert een inputbeleid op dat te streng is voor de host die het beschermt.

De praktische regel is de essentiële fout- en configuratieberichten toe te staan op de interface die ze nodig heeft, beperkt naar type en bron waar het platform dat toelaat, en een expliciete beslissing over de rest te nemen.

Alles vervangen door een algemene ICMPv6-toestemming lost het beschikbaarheidsprobleem op en geeft het filteren op. Het vervangen door een algemene drop lost het filterprobleem op en geeft de host op.

Laat de tunnel toe, dan de dienst

Accepteer het WireGuard-transport op het bedoelde buitenadres en de UDP-poort, en accepteer het retourverkeer via verbindingstracking. Sta daarna de applicatiediensten toe via de tunnelinterface, vanaf de bronnen die je werkelijk autoriseert.

Een toestemming voor de buitenste UDP-poort autoriseert de ontsleutelde verzoeken daarbinnen niet. Dat onderscheid is de hele reden dat de tunnelinterface in de dienstregels voorkomt.

Lees de regelset zoals hij is, niet zoals het bestand hem beschrijft:

sudo nft list ruleset
ip -6 addr show
ip -6 route show default

Een luisteraar op een fysiek adres is een aparte blootstelling ten opzichte van dezelfde dienst op het tunneladres. Als de machine ook verkeer naar een andere machine doorstuurt, is dat een beslissing van de doorstuurketen en niet dit inputbeleid, en die vraagt een eigen afweging.

Test de link, niet alleen de tunnel

Een tunnel die na de wijziging werkt, bewijst minder dan het lijkt, omdat een bestaande buurvermelding en een opgezette verbinding een controleboodschap kunnen verbergen die het beleid nu laat vallen.

Controleer de verbinding rechtstreeks en controleer daarna dat het uitgesloten pad nog steeds faalt:

ip -6 neigh show
ping -6 -c 3 2001:db8:1::1
sudo nft -c -f /etc/nftables.conf

Een buurtabel die na een herstart volledig blijft, is het signaal dat ontdekking nog werkt. Een tabel die leegloopt en nooit meer volloopt, is het signaal dat je hem wegfilterde. Het derde commando valideert de syntaxis van de regelset zonder hem toe te passen, wat de moeite waard is zolang je nog een sessie hebt.

Herstel een host waar je jezelf buiten sloot

Voordat je firewallregels wijzigt die je eigen beheersessie dragen, houd een tweede kanaal: een console, een seriële verbinding of een geplande terugrol die de nieuwe regels verwijdert als je die niet annuleert.

Als een wijziging je toch buiten sluit, verloopt het herstel via dat kanaal en niet via het netwerk dat je net verwijderde. Herstel de vorige regelset uit een bewaarde kopie, bevestig dat de host weer bereikbaar is, en pas daarna het bedoelde beleid in kleinere stukken toe.

Het uiteindelijke beleid is niet universeel. Adressering, routing en de implementatie van de firewall zijn invoer voor de uitrol, maar de grens is overal dezelfde: weiger ongewenste applicatietoegang en behoud het controleverkeer dat de geautoriseerde tunnel draagt.