Att blockera IPv6 för att säkra WireGuard slår sönder värden

Målet är rimligt: bara tunnelanvändare ska nå tjänsterna på den här maskinen. Lösningen folk griper efter är en IPv6-indatakedja som släpper allt utom WireGuard, och därmed också släpper trafiken som håller värden kopplad till sin egen länk. Granndetektering och meddelanden för vägunderhåll är inte tjänståtkomst, och att ta bort dem ger en maskin som är onåbar av skäl som inte har med din policy att göra. Tunneln kommer upp, tjänsterna är korrekt avgränsade, och inget annat på länken fungerar.

Tre ansvarsområden, en regeluppsättning

Det första ansvaret är drift av det yttre nätet: värden måste stanna på sin länk, lösa grannar och lära sig väggränserna för den länken. Det andra är den krypterade lyssnaren, som tar emot UDP på adressen och porten du valde. Det tredje är uppsättningen dekrypterade tjänster som tunnelanvändare ska nå.

Det är tre olika policyer, och bara den andra och tredje handlar om VPN. En regeluppsättning som behandlar dem som en ärver ett felläge där en åtstramning av applikationsgränsen tyst slår sönder värdens anslutning.

Håll dem i separata kedjor eller åtminstone separata kommentarer, så att nästa person ser vilken rad som finns och varför.

Vad ICMPv6 gör för värden

IPv6 är beroende av ICMPv6 för långt mer än eko. Granndförfrågan och -annonsering ersätter ARP och krävs för lokal leverans. Packet Too Big bär information om länkens MTU, och att ignorera den ger överföringar som stannar vid stora paket. Routerannonseringar bär standardrutten och prefixinformation när länken använder automatisk konfiguration.

RFC 4890 skiljer de meddelanden som ett värdilter måste tillåta från dem som är ett administrativt val, och gör det i ett värdsavsnitt som skiljer sig från reglerna för en router som vidarebefordrar mellan nät. Läser man bara vidarebefordransavsnittet får man en indatapolicy som är för strikt för värden den skyddar.

Den praktiska regeln är att tillåta de väsentliga fel- och konfigurationsmeddelandena på det gränssnitt som behöver dem, avgränsade efter typ och källa där plattformen tillåter det, och att fatta ett uttryckligt beslut om resten.

Att ersätta allt detta med ett generellt ICMPv6-tillstånd löser tillgänglighetsproblemet och ger upp filtreringen. Att ersätta det med en generell dropp löser filterproblemet och ger upp värden.

Släpp in tunneln, sedan tjänsten

Acceptera WireGuard-transporten på den avsedda yttre adressen och UDP-porten, och acceptera returtrafiken via anslutningsspårning. Tillåt sedan applikationstjänsterna genom tunnelgränssnittet, från de källor du faktiskt auktoriserar.

Ett tillstånd för den yttre UDP-porten auktoriserar inte de dekrypterade förfrågningarna inuti den. Den skillnaden är hela anledningen till att tunnelgränssnittet dyker upp i tjänstereglerna.

Läs regeluppsättningen som den är, inte som filen beskriver den:

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

En lyssnare på en fysisk adress är en separat exponering från samma tjänst på tunneladressen. Om maskinen också vidarebefordrar trafik till en annan maskin är det ett beslut i vidarebefordranskedjan och inte denna indatapolicy, och det kräver sin egen motivering.

Testa länken, inte bara tunneln

En tunnel som fungerar efter ändringen bevisar mindre än det ser ut som, eftersom en befintlig granne-post och en upprättad anslutning kan dölja ett kontrollmeddelande som policyn nu släpper.

Kontrollera anslutningen direkt och kontrollera sedan att den uteslutna vägen fortfarande misslyckas:

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

En grannetabell som förblir komplett efter omstart är signalen att detekteringen fortfarande fungerar. En tabell som töms och aldrig fylls igen är signalen att du filtrerade bort den. Det tredje kommandot validerar regeluppsättningens syntax utan att tillämpa den, vilket är värt att göra medan du fortfarande har en session.

Återställ en värd du låste dig ute från

Innan du ändrar brandväggsregler som bär din egen administrationssession, håll en andra kanal: en konsol, en seriell anslutning eller en schemalagd återställning som tar bort de nya reglerna om du inte avbryter den.

Om en ändring verkligen låser dig ute sker återställningen genom den kanalen och inte genom nätet du just tog bort. Återställ föregående regeluppsättning från en sparad kopia, bekräfta att värden är nåbar igen, och tillämpa först då den avsedda policyn i mindre delar.

Den slutliga policyn är inte universell. Adressering, routing och brandväggens implementering är indata för driftsättningen, men gränsen är densamma överallt: neka oavsiktlig applikationsåtkomst och behåll kontrolltrafiken som bär den auktoriserade tunneln.