Var VPN-NAT hör hemma i UFW:s before.rules och hur du testar det

En NAT-regel som fungerar när den skrivs i ett skal misslyckas när den klistras in i before.rules, eftersom filen inte är ett skript. Det är ett dokument i återställningsformat med tabellavsnitt, kedjedeklarationer och en COMMIT-markör för varje tabell. En rad på fel ställe avbryter antingen hela återställningen eller släpper tyst regler som du trodde fanns där. Runbooken nedan placerar fragmentet där ramverket förväntar sig det och bevisar resultatet före nästa omladdning.

Ett skalkommando är inte en återställningsfil

En rad som börjar med iptables -t nat är en instruktion till iptables-binären, medan filen som UFW läser är en beskrivning av en komplett regeluppsättning. Skillnaden är inte kosmetisk: återställningsformatet måste veta vilken tabell det befinner sig i, vilka kedjor som finns och var tabellen slutar. Ett kommando som klistras in i det dokumentet är antingen ett syntaxfel eller, värre, en regel fäst vid fel tabell. Ramverket laddar dessa filer via återställningsverktyg just därför att de är deklarativa och inte sekventiella.

Dokumentet laddas också som en helhet, så ett enda felaktigt avsnitt kan stoppa resten av filen från att tillämpas. Ett litet fel i ett NAT-fragment tar därför med sig filterreglerna ned, och så blir en brandväggsändring ett avbrott.

Sätt fragmentet i det befintliga tabellavsnittet

Ett NAT-fragment har en form, och formen betyder mer än regeltexten inuti. Tabellhuvudet öppnar avsnittet, kedjedeklarationerna sätter upp räknarna, reglerna följer och en COMMIT stänger avsnittet.

*nat
:POSTROUTING ACCEPT [0:0]
-A POSTROUTING -s 10.55.0.0/24 -o ens3 -j MASQUERADE
COMMIT

Poolen och gränssnittet ovan är platshållare för dina egna värden; strukturen är den del som är värd att kopiera. Om filen redan innehåller ett *nat-avsnitt lägger du till regeln i det avsnittet i stället för att öppna ett andra, eftersom formatet förväntar sig en COMMIT per tabell och två avsnitt för samma tabell är en reparation som väntar på att inträffa. Behåll distributionens kedjedefinitioner intakta, inklusive dem som leverantören lagt till för sin egen integration. UFW-ramverkets handbok dokumenterar filerna before, user och after tillsammans med kravet på en matchande COMMIT.

Om filen visar sig vara tom ska du inte fylla den från en handledning. Bekräfta vilket paket som äger den och vad den aktiva policyn faktiskt är, eftersom en tom beständig fil inte bevisar att kärnan inte har några regler, och en laddad regeluppsättning bevisar inte att nästa omladdning har en komplett fil att läsa. Återställ först den stödda baslinjen och tillämpa sedan webbplatsändringarna ovanpå den.

Testa kandidaten utan att tillämpa den

Återställningsverktyget kan parsa och bygga en regeluppsättning utan att tillämpa den, och det är det billigaste tillgängliga testet. Kör det mot en skyddad kopia i stället för den aktiva filen, och läs feltexten i stället för bara utgångsstatusen. Ett parsningsfel namnger en rad och vanligtvis en tabell, vilket är mer än en misslyckad omladdning berättar.

sudo cp /etc/ufw/before.rules /root/before.rules.bak
sudo iptables-restore --test < /root/before.rules.bak
echo "exit: 0"

Att klara den kontrollen bevisar att dokumentet parsas, och ingenting annat. Det bevisar inte att kandidaten fortfarande innehåller varje kedja som UFW är beroende av, att den bara tillåter de källor du avsåg, eller att fjärradministration förblir nåbar. Det är separata granskningar, och den sista förtjänar en andra session som öppnas innan du börjar.

Välj det verktyg som passar den installerade backendens och adressfamiljen. En värd som kör nft-backenden genom kompatibilitetslagret behöver motsvarande kommando, och IPv6-regler bor i en helt annan fil.

Håll vidarebefordran, NAT och åtkomstpolicy åtskilda

Källöversättning löser ett adresseringsproblem och ger ingenting. Vidarebefordran är ett separat tillstånd som styrs av en sysctl och av filtertabellen, och det är den folk glömmer när en tunnel routar men inte släpper igenom trafik. Åtkomstpolicy är ett tredje beslut om vilka källor som kan nå vilka tjänster, och ingen NAT-regel uttrycker den. Att hålla de tre åtskilda är det som gör ett fel diagnosticerbart i stället för ett enda vagt symptom.

sysctl net.ipv4.ip_forward
sudo iptables -t nat -S POSTROUTING
sudo iptables -S FORWARD

Läs dessa tre utdata tillsammans i stället för ett i taget. En masquerade-regel med vidarebefordran avstängd ger en klient som ansluter och inte når något, vilket från klientsidan ser ut precis som ett routningsfel och skickar folk till fel fil. Filtertabellen är också där ett för brett accept gömmer sig, så kontrollera dess standardpolicy medan du är där.

Verifiera en omladdning, en avvisning och en VPN-förlust

Tre observationer utgör ett komplett acceptanstest: omladdningen lyckas, en tillåten klientoperation fungerar och en begäran som borde avvisas avvisas faktiskt. Den tredje är den som hoppas över, och den är det enda beviset på att policyn gör något alls.

sudo ufw reload
sudo ufw status verbose
sudo iptables -t nat -L POSTROUTING -n -v

Testa sedan felet du designade för. Släpp tunneln och observera vad värden gör, eftersom en policy som bara fungerar medan VPN:et är uppe är en policy med ett outtalat beroende. Ladda om en gång till efteråt för att bevisa att det är filen, och inte ett kvarvarande körtillstånd, som ger det fungerande resultatet.

IPv4-NAT säger ingenting om IPv6, så ange den avsedda täckningen för båda familjerna i samma anteckning som regeln. Målet är en sammanhängande hanterad policy, och ett fragment som råkade parsas är inte bevis för en.