At blokere IPv6 for at sikre WireGuard ødelægger værten

Målet er rimeligt: kun tunnelbrugere bør nå tjenesterne på denne maskine. Den løsning, folk griber efter, er en IPv6-inputkæde, der dropper alt undtagen WireGuard, og som dermed også dropper den trafik, der holder værten knyttet til sit eget link. Nabo-opdagelse og vedligeholdelsesbeskeder for stien er ikke tjenesteadgang, og at fjerne dem giver en maskine, der er uopnåelig af grunde, der intet har med din politik at gøre. Tunnelen kommer op, tjenesterne er korrekt afgrænset, og intet andet på linket virker.

Tre ansvarsområder, ét regelsæt

Det første ansvar er den ydre netværksdrift: værten skal blive på sit link, slå naboer op og lære stiens grænser for det link. Det andet er den krypterede lytter, som accepterer UDP på den adresse og port, du valgte. Det tredje er det sæt dekrypterede tjenester, som du vil have tunnelbrugere til at nå.

Det er tre forskellige politikker, og kun den anden og tredje handler om VPN. Et regelsæt, der behandler dem som ét, arver en fejltilstand, hvor en stramning af applikationsgrænsen lydløst bryder værtens tilknytning.

Hold dem i separate kæder eller i det mindste separate kommentarer, så den næste person kan se, hvilken linje der findes af hvilken grund.

Hvad ICMPv6 gør for værten

IPv6 afhænger af ICMPv6 for langt mere end echo. Naboanmodning og -annoncering erstatter ARP og er nødvendige for lokal levering. Packet Too Big bærer information om stiens MTU, og at ignorere den giver overførsler, der går i stå på store pakker. Routerannonceringer bærer standardruten og præfiksinformation, når linket bruger automatisk konfiguration.

RFC 4890 adskiller de beskeder, som et vært-filter skal tillade, fra dem der er et administrativt valg, og gør det i et vært-afsnit, der er forskelligt fra reglerne for en router, der videresender mellem netværk. Læser man kun videresendelsesafsnittet, får man en inputpolitik, der er for streng for den vært, den beskytter.

Den praktiske regel er at tillade de væsentlige fejl- og konfigurationsbeskeder på det interface, der har brug for dem, afgrænset efter type og kilde, hvor platformen tillader det, og at træffe en udtrykkelig beslutning om resten.

At erstatte det hele med en generel ICMPv6-tilladelse løser tilgængelighedsproblemet og opgiver filtreringen. At erstatte det med et generelt drop løser filtreringsproblemet og opgiver værten.

Luk tunnelen ind, derefter tjenesten

Accepter WireGuard-transporten på den tilsigtede ydre adresse og UDP-port, og accepter returtrafikken via forbindelsessporing. Tillad derefter applikationstjenesterne gennem tunnel-interfacet, fra de kilder du faktisk autoriserer.

En tilladelse til den ydre UDP-port autoriserer ikke de dekrypterede anmodninger indeni. Den forskel er hele grunden til, at tunnel-interfacet optræder i tjenestereglerne.

Læs regelsættet som det er, ikke som filen beskriver det:

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

En lytter på en fysisk adresse er en separat eksponering fra den samme tjeneste på tunneladressen. Hvis maskinen også videresender trafik til en anden maskine, er det en beslutning i videresendelseskæden og ikke denne inputpolitik, og den kræver sin egen begrundelse.

Test linket, ikke bare tunnelen

En tunnel, der virker efter ændringen, beviser mindre, end det ser ud som, fordi en eksisterende naboindgang og en etableret forbindelse kan skjule en kontrolbesked, som politikken nu dropper.

Kontroller tilknytningen direkte, og kontroller derefter, at den udelukkede sti stadig fejler:

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

En nabotabel, der forbliver komplet efter en genstart, er signalet om, at opdagelse stadig virker. En tabel, der tømmes og aldrig fyldes igen, er signalet om, at du har filtreret den væk. Den tredje kommando validerer regelsættets syntaks uden at anvende det, hvilket er værd at gøre, mens du stadig har en session.

Gendan en vært, du har låst dig ude af

Før du ændrer firewallregler, der bærer din egen administrationssession, skal du have en anden kanal: en konsol, en seriel forbindelse eller en planlagt tilbagerulning, der fjerner de nye regler, hvis du ikke annullerer den.

Hvis en ændring låser dig ude, sker gendannelsen gennem den kanal og ikke gennem det netværk, du netop fjernede. Gendan det forrige regelsæt fra en gemt kopi, bekræft at værten kan nås igen, og anvend først derefter den tilsigtede politik i mindre stykker.

Den endelige politik er ikke universel. Adressering, routing og firewallimplementering er input til udrulningen, men grænsen er den samme overalt: afvis utilsigtet applikationsadgang, mens den kontrolltrafik, der bærer den autoriserede tunnel, bevares.