iptables-vert berre med VPN: nemn tun-eininga, ikkje tun+

Å skrive -o tun+ kjennest som ein presis instruks og er eigentleg eit jokerteikn som treff kvar tunnel kjernen har. Ein ekstra VPN-klient, ei containerbru eller eit grensesnitt som ein krasja økt har late etter seg oppfyller det alle, og verten slepp då gjennom trafikk som policyen var meint å hindre. Framgangsmåten nedanfor festar eitt einingarnamn, ordnar unntaka slik at tunnelen faktisk kan danast, og lèt deg ha ein veg tilbake om reglane fell uheldig ut. Kvart steg er kort nok til å rullast tilbake åleine.

Steg 1: skriv ned reglane du har no

Før du endrar ein standardpolicy, lagra gjeldande tilstand slik at tilbakerulleringa er ein kommando og ikkje ei minning. iptables-save > /root/iptables.pre skriv kvar tabell til ei fil du kan gjenopprette, og ein ekstra terminal med open root-økt er ikkje paranoia når policyen du er i ferd med å setje, droppar sambandet som ber han. Viss du jobbar eksternt, planlegg òg ein flush som naudstopp.

List deretter opp grensesnitta, for eit namn du antok er eit namn du burde ha lese: ip -br link viser kva som finst akkurat no, og tunnelen viser seg ikkje før han er oppe. Skriv ned einingarnamna medan du les dei.

Steg 2: gje tunnelen sitt eige namn

OpenVPN godtek dev tun_work i klientkonfigurasjonen, og Linux opprettar då eit grensesnitt med nøyaktig det namnet i staden for å tildele tun0. Namnet held seg stabilt gjennom gjenoppkoplingar så lenge ingenting anna gjer krav på det, og det er dette som gjer ein regel som nemner eininga meiningsfull.

Der namnet ikkje kan kontrollerast, match i staden på tunneladressa eller ei pakkemarkering. Begge verkar, begge er vanskelegare å lese, og begge feilar meir lydlaust når tunnelen omnummererer. Uansett, match éin ting og ver tydeleg på kva.

Steg 3: skriv policyen med unntaket for endpoint fyrst

Ein vert berre med VPN er ein vert med standardavvising og ei kort unntaksliste, og unntaket som tyder mest er det som lèt tunnelen eksistere. Bygg han i denne rekkjefølgja, med endpoint-regelen før tunnelregelen, slik at handtrykket har ein stad å 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 bokstavelege endpoint-adressa og porten høyrer til leverandøren din, ikkje denne sida. Viss endepunktet er eit vertsnamn, slå det opp éin gong og fest resultatet, for ein regel kan ikkje slå opp eit namn, og eit roterande svar vil lydlaust bryte policyen etter neste DNS-endring. Sjekk porten òg, for leverandørar som flyttar deg til TCP 443 treng elles ein regel ingen har skrive ned. Ein tunnel som berre verkar på éin protokoll er vanlegvis nettopp denne utelatinga og ikkje ein feil i brannmuren.

På ein ruter går same form inn i FORWARD-kjeda for klientane bak han, og ruterens eigen trafikk treng eigne reglar. Eit regelsett som berre dekkjer vidaresende pakkar lèt SSH og DNS bli på den gamle vegen, og slik blir ein ruter utilgjengeleg i det augneblinken tunnelen kjem opp.

Steg 4: sjekk rekkjefølgja, ikkje berre tilstadeværet

Reglar blir vurderte i rekkjefølgje, så ein ACCEPT som kjem tidlegare skjuler berre REJECT-en du la til etterpå. Matchinga av established og related er det som lèt svar på dine eigne utgåande førespurnader kome tilbake utan å opne ein generell inngangsveg, og å plassere henne etter tunnel-aksepten betyr at ein droppa tunnel framleis slepp returtrafikk på sitt eige grensesnitt.

Hald talet på reglar lite nok til å lesast på éin skjerm. Eit regelsett du ikkje kan revidere er eit du vil lappe ved å leggje til unntak øvst, og slik får standardavvisingspolicyar gradvis ein standardtillatingskant. Tel ACCEPT-ane før og etter endringa.

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

Reglar skrivne inn for hand forsvinn ved omstart, så last dei frå brannmuretenesta til distribusjonen eller frå ein unit som køyrer etter at tunnelgrensesnittet finst. Å referere til tun_work i eit skript som køyrer før OpenVPN startar, er ein vanleg måte å lage ei oppstartslykkje med droppa trafikk.

Sjekk deretter IPv6 separat, for ein god standardavvisingspolicy for IPv4 seier ingenting om den andre familien. ip -6 route fortel deg om verten har ei rute som kan bere trafikk rundt ein tunnel som berre handterer IPv4, og ip6tables eller nftables treng sine eigne tilsvarande reglar. Test med ein IPv6-only-destinasjon i staden for å stole på symmetrien til regelsettet.

Steg 6: verifiser og ver klar til å gjenopprette

Ta tunnelen opp, stadfest at tenesta du er ute etter verkar, og prøv så noko policyen skal avvise. Gjenopprett med iptables-restore < /root/iptables.pre viss svaret overraskar deg, og byrja først då å redigere reglar. Vedhald pluss ein testa gjenopprettingsveg er det som gjer dette til ei endring du kan gjere to gonger.