iptables-värd endast med VPN: namnge tun-enheten, inte tun+

Att skriva -o tun+ känns som en exakt instruktion och är egentligen ett jokertecken som träffar varje tunnel som kärnan har. En extra VPN-klient, en containerbrygga eller ett gränssnitt som en kraschad session lämnat efter sig uppfyller det alla, och värden släpper då igenom trafik som policyn skulle förhindra. Rutinen nedan låser ett enhetsnamn, ordnar undantagen så att tunneln faktiskt kan bildas och lämnar en väg tillbaka om reglerna faller illa ut. Varje steg är kort nog att ångras för sig.

Steg 1: skriv ned reglerna du har nu

Innan du ändrar en standardpolicy, spara nuvarande tillstånd så att återrullningen är ett kommando och inte ett minne. iptables-save > /root/iptables.pre skriver varje tabell till en fil du kan återställa, och en extra terminal med öppen root-session är inte paranoia när policyn du är på väg att sätta släpper anslutningen som bär den. Om du arbetar på distans, schemalägg även en flush som nödstopp.

Lista sedan gränssnitten, för ett namn du antog är ett namn du borde ha läst: ip -br link visar vad som finns just nu, och tunneln syns inte förrän den är uppe. Skriv ned enhetsnamnen medan du läser dem.

Steg 2: ge tunneln sitt eget namn

OpenVPN accepterar dev tun_work i klientkonfigurationen, och Linux skapar då ett gränssnitt med exakt det namnet i stället för att tilldela tun0. Namnet förblir stabilt mellan återanslutningar så länge inget annat gör anspråk på det, och det är vad som gör en regel som namnger enheten meningsfull.

Där namnet inte kan kontrolleras, matcha i stället tunneladressen eller en paketmarkering. Båda fungerar, båda är svårare att läsa, och båda misslyckas mer tyst när tunneln numreras om. Matcha hur som helst en sak och var tydlig med vilken.

Steg 3: skriv policyn med undantaget för endpoint först

En värd endast med VPN är en värd med standardavvisning och en kort undantagslista, och undantaget som betyder mest är det som låter tunneln existera. Bygg den i den här ordningen, med endpoint-regeln före tunnelregeln, så att handskakningen har någonstans att ta vägen:

# allow the tunnel to be built, then everything the tunnel carries
iptables -P INPUT DROP
iptables -P OUTPUT DROP
iptables -A INPUT  -i lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT
iptables -A OUTPUT -d 198.51.100.7 -p udp --dport 1194 -j ACCEPT
iptables -A OUTPUT -o tun_work -j ACCEPT
iptables -A INPUT  -i tun_work -j ACCEPT
iptables -A INPUT  -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

Den bokstavliga endpoint-adressen och porten tillhör din leverantör, inte den här sidan. Om endpoint är ett värdnamn, slå upp det en gång och lås resultatet, för en regel kan inte slå upp ett namn och ett roterande svar kommer tyst att bryta policyn efter nästa DNS-ändring. Kontrollera porten också, för leverantörer som flyttar dig till TCP 443 behöver annars en regel som ingen skrivit ned. En tunnel som bara fungerar på ett protokoll är oftast just denna utelämning och inte ett fel i brandväggen.

På en router går samma form in i FORWARD-kedjan för klienterna bakom den, och routerns egen trafik behöver egna regler. En regeluppsättning som bara täcker vidarebefordrade paket lämnar SSH och DNS på den gamla vägen, och så blir en router oåtkomlig i samma ögonblick som tunneln kommer upp.

Steg 4: kontrollera ordningen, inte bara förekomsten

Regler utvärderas i ordning, så en ACCEPT som kommer tidigare döljer helt enkelt den REJECT du lade till efteråt. Matchningen av established och related är det som låter svar på dina egna utgående förfrågningar komma tillbaka utan att öppna en allmän ingående väg, och att placera den efter tunnel-accepten betyder att en tappad tunnel fortfarande släpper igenom returtrafik på sitt eget gränssnitt.

Håll antalet regler litet nog att läsas på en skärm. En regeluppsättning du inte kan granska är en du kommer att lappa genom att lägga till undantag högst upp, och så får standardavvisningspolicyer gradvis en standardtillståndskant. Räkna ACCEPT före och efter ändringen.

Steg 5: se till att det överlever uppstarten och adressfamiljen

Regler som skrivs in för hand försvinner vid omstart, så ladda dem från distributionens brandväggstjänst eller från en unit som körs efter att tunnelgränssnittet finns. Att referera till tun_work i ett skript som körs innan OpenVPN startar är ett vanligt sätt att skapa en uppstartsloop med tappad trafik.

Kontrollera sedan IPv6 separat, för en bra standardavvisningspolicy för IPv4 säger ingenting om den andra familjen. ip -6 route berättar om värden har en rutt som kan bära trafik runt en tunnel som bara hanterar IPv4, och ip6tables eller nftables behöver sina egna motsvarande regler. Testa med en IPv6-only-destination i stället för att lita på regeluppsättningens symmetri.

Steg 6: verifiera och var redo att återställa

Ta upp tunneln, bekräfta att tjänsten du avser fungerar och prova sedan något som policyn ska avvisa. Återställ med iptables-restore < /root/iptables.pre om svaret överraskar dig, och börja först då redigera regler. Envishet plus en testad återställningsväg är det som gör detta till en ändring du kan göra två gånger.