iptables-vert kun med VPN: navngi tun-enheten, ikke tun+

Å skrive -o tun+ føles som en presis instruks og er egentlig et jokertegn som treffer hver tunnel kjernen har. En ekstra VPN-klient, en containerbro eller et grensesnitt en krasjet økt har etterlatt seg oppfyller det alle, og verten slipper da gjennom trafikk som policyen var ment å hindre. Fremgangsmåten nedenfor fester ett enhetsnavn, ordner unntakene slik at tunnelen faktisk kan dannes, og lar deg ha en vei tilbake hvis reglene faller uheldig ut. Hvert trinn er kort nok til å rulles tilbake alene.

Trinn 1: skriv ned reglene du har nå

Før du endrer en standardpolicy, lagre gjeldende tilstand slik at tilbakerullingen er en kommando og ikke en erindring. iptables-save > /root/iptables.pre skriver hver tabell til en fil du kan gjenopprette, og en ekstra terminal med åpen root-økt er ikke paranoia når policyen du er i ferd med å sette, dropper forbindelsen som bærer den. Hvis du jobber eksternt, planlegg også en flush som nødstopp.

List deretter opp grensesnittene, for et navn du antok er et navn du burde ha lest: ip -br link viser hva som finnes akkurat nå, og tunnelen vises ikke før den er oppe. Skriv ned enhetsnavnene mens du leser dem.

Trinn 2: gi tunnelen sitt eget navn

OpenVPN godtar dev tun_work i klientkonfigurasjonen, og Linux oppretter da et grensesnitt med nøyaktig det navnet i stedet for å tildele tun0. Navnet holder seg stabilt gjennom gjenoppkoblinger så lenge ingenting annet gjør krav på det, og det er det som gjør en regel som navngir enheten meningsfull.

Der navnet ikke kan kontrolleres, match i stedet på tunneladressen eller en pakkemarkering. Begge virker, begge er vanskeligere å lese, og begge feiler mer lydløst når tunnelen omnummereres. Uansett, match én ting og vær tydelig på hvilken.

Trinn 3: skriv policyen med unntaket for endpoint først

En vert kun med VPN er en vert med standardavvisning og en kort unntaksliste, og unntaket som betyr mest er det som lar tunnelen eksistere. Bygg den i denne rekkefølgen, med endpoint-regelen før tunnelregelen, slik at håndtrykket har et sted å gå:

# 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 bokstavelige endpoint-adressen og porten tilhører leverandøren din, ikke denne siden. Hvis endepunktet er et vertsnavn, slå det opp én gang og fest resultatet, for en regel kan ikke slå opp et navn, og et roterende svar vil lydløst bryte policyen etter neste DNS-endring. Sjekk porten også, for leverandører som flytter deg til TCP 443 trenger ellers en regel ingen har skrevet ned. En tunnel som bare virker på én protokoll er vanligvis nettopp denne utelatelsen og ikke en feil i brannmuren.

På en ruter går samme form inn i FORWARD-kjeden for klientene bak den, og ruterens egen trafikk trenger egne regler. Et regelsett som bare dekker videresendte pakker lar SSH og DNS bli på den gamle veien, og slik blir en ruter utilgjengelig i det øyeblikket tunnelen kommer opp.

Trinn 4: sjekk rekkefølgen, ikke bare tilstedeværelsen

Regler vurderes i rekkefølge, så en ACCEPT som kommer tidligere skjuler bare REJECT-en du la til etterpå. Matchingen av established og related er det som lar svar på dine egne utgående forespørsler komme tilbake uten å åpne en generell inngangsvei, og å plassere den etter tunnel-aksepten betyr at en droppet tunnel fortsatt slipper returtrafikk på sitt eget grensesnitt.

Hold antallet regler lite nok til å leses på én skjerm. Et regelsett du ikke kan revidere er ett du vil lappe ved å legge til unntak øverst, og slik får standardavvisningspolicyer gradvis en standardtillatelseskant. Tell ACCEPT-ene før og etter endringen.

Trinn 5: sørg for at det overlever oppstarten og adressefamilien

Regler skrevet inn for hånd forsvinner ved omstart, så last dem fra distribusjonens brannmurtjeneste eller fra en unit som kjører etter at tunnelgrensesnittet finnes. Å referere til tun_work i et skript som kjører før OpenVPN starter, er en vanlig måte å lage en oppstartsloop med droppet trafikk.

Sjekk deretter IPv6 separat, for en god standardavvisningspolicy for IPv4 sier ingenting om den andre familien. ip -6 route forteller deg om verten har en rute som kan bære trafikk rundt en tunnel som bare håndterer IPv4, og ip6tables eller nftables trenger sine egne tilsvarende regler. Test med en IPv6-only-destinasjon i stedet for å stole på regelsettets symmetri.

Trinn 6: verifiser og vær klar til å gjenopprette

Ta tunnelen opp, bekreft at tjenesten du er ute etter virker, og prøv så noe policyen skal avvise. Gjenopprett med iptables-restore < /root/iptables.pre hvis svaret overrasker deg, og begynn først da å redigere regler. Vedholdenhet pluss en testet gjenopprettingsvei er det som gjør dette til en endring du kan gjøre to ganger.