iptables-vært kun med VPN: navngiv tun-enheden, ikke tun+

At skrive -o tun+ føles som en præcis instruktion og er i virkeligheden et jokertegn, der dækker hver tunnel, kernen har. En ekstra VPN-klient, en containerbro eller et interface, som en nedbrudt session har efterladt, opfylder alle sammen kravet, og værten tillader derefter trafik, som politikken skulle forhindre. Proceduren nedenfor fastlåser ét enhedsnavn, ordner undtagelserne, så tunnelen faktisk kan dannes, og efterlader dig en vej tilbage, hvis reglerne falder uheldigt ud. Hvert trin er kort nok til at blive rullet tilbage alene.

Trin 1: noter de regler, du har nu

Før du ændrer en standardpolitik, skal du gemme den aktuelle tilstand, så tilbagerulningen er en kommando og ikke en erindring. iptables-save > /root/iptables.pre skriver hver tabel til en fil, du kan gendanne, og en ekstra terminal med en åben root-session er ikke paranoia, når den politik, du er ved at sætte, dropper den forbindelse, der bærer den. Hvis du arbejder eksternt, skal du også planlægge en flush som dødmandskontakt.

List derefter interfaceene, for et navn, du antog, er et navn, du burde have læst: ip -br link viser, hvad der findes lige nu, og tunnelen vises ikke, før den er oppe. Skriv enhedsnavnene ned, mens du læser dem.

Trin 2: giv tunnelen sit eget navn

OpenVPN accepterer dev tun_work i klientkonfigurationen, og Linux opretter derefter et interface med præcis det navn i stedet for at tildele tun0. Navnet forbliver stabilt gennem genopkoblinger, så længe intet andet gør krav på det, og det er det, der gør en regel, som navngiver enheden, meningsfuld.

Hvor navnet ikke kan styres, skal du i stedet matche på tunneladressen eller et pakkemærke. Begge virker, begge er sværere at læse, og begge fejler mere lydløst, når tunnelen omnummererer. Under alle omstændigheder, match én ting og vær tydelig om hvilken.

Trin 3: skriv politikken med undtagelsen for endpoint først

En vært kun med VPN er en vært med standardafvisning og en kort undtagelsesliste, og den undtagelse, der betyder mest, er den, der lader tunnelen eksistere. Byg den i denne rækkefølge, med endpoint-reglen før tunnelreglen, så håndtrykket har et sted at gå hen:

# 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 bogstavelige endpoint-adresse og port tilhører din udbyder, ikke denne side. Hvis endpointet er et værtsnavn, skal du slå det op én gang og fastlåse resultatet, for en regel kan ikke slå et navn op, og et skiftende svar vil lydløst bryde politikken efter den næste DNS-ændring. Tjek også porten, for udbydere, der flytter dig til TCP 443, har ellers brug for en regel, som ingen har skrevet ned. En tunnel, der kun virker på én protokol, er normalt netop denne udeladelse og ikke en fejl i firewallen.

På en router går samme form ind i FORWARD-kæden for klienterne bag den, og routerens egen trafik har brug for sine egne regler. Et regelsæt, der kun dækker videresendte pakker, lader SSH og DNS blive på den gamle vej, og det er sådan en router bliver utilgængelig i det øjeblik, tunnelen kommer op.

Trin 4: tjek rækkefølgen, ikke kun tilstedeværelsen

Regler evalueres i rækkefølge, så en ACCEPT, der kommer tidligere, skjuler blot den REJECT, du tilføjede bagefter. Matchningen af established og related er det, der lader svar på dine egne udgående anmodninger vende tilbage uden at åbne en generel indgående vej, og at placere den efter tunnel-accept betyder, at en droppet tunnel stadig fører returtrafik på sit eget interface.

Hold antallet af regler lille nok til at blive læst på én skærm. Et regelsæt, du ikke kan revidere, er et, du vil lappe ved at tilføje undtagelser i toppen, og det er sådan standardafvisningspolitikker gradvist får en standardtilladelseskant. Tæl ACCEPT'erne før og efter ændringen.

Trin 5: sørg for, at det overlever opstarten og adressefamilien

Regler indtastet i hånden forsvinder ved genstart, så indlæs dem fra distributionens firewall-tjeneste eller fra en unit, der kører, efter tunnelinterfacet findes. At referere til tun_work i et script, der kører, før OpenVPN starter, er en almindelig måde at frembringe en opstartsloop med droppet trafik.

Tjek derefter IPv6 separat, for en god standardafvisningspolitik for IPv4 siger intet om den anden familie. ip -6 route fortæller dig, om værten har en rute, der kunne bære trafik uden om en tunnel, der kun håndterer IPv4, og ip6tables eller nftables har brug for sine egne tilsvarende regler. Test med en IPv6-only-destination i stedet for at stole på regelsættets symmetri.

Trin 6: verificer og vær klar til at gendanne

Bring tunnelen op, bekræft, at den tilsigtede tjeneste virker, og prøv så noget, som politikken bør afvise. Gendan med iptables-restore < /root/iptables.pre, hvis svaret overrasker dig, og begynd først derefter at redigere regler. Vedholdenhed plus en testet gendannelsesvej er det, der gør dette til en ændring, du kan lave to gange.