Gostitelj iptables samo z VPN: poimenujte napravo tun, ne tun+

Pisanje -o tun+ se zdi natančno navodilo, v resnici pa je nadomestni znak, ki se ujema z vsakim tunelom, ki ga ima jedro. Drug odjemalec VPN, most kontejnerjev ali vmesnik, ki ga je pustila sesija, ki se je sesula, vsi ga izpolnjujejo, in gostitelj nato spusti promet, ki naj bi ga politika preprečila. Postopek spodaj določi eno ime naprave, razporedi izjeme tako, da lahko tunel res nastane, in vam pusti pot nazaj, če pravila padejo slabo. Vsak korak je dovolj kratek, da ga lahko razveljavite sami.

Korak 1: zapišite pravila, ki jih imate zdaj

Preden spremenite privzeto politiko, shranite trenutno stanje, da bo vrnitev ukaz in ne spomin. iptables-save > /root/iptables.pre zapiše vsako tabelo v datoteko, ki jo lahko obnovite, in drug terminal z odprto sejo root ni paranoja, ko politika, ki jo boste nastavili, prekine povezavo, ki jo nosi. Če delate na daljavo, načrtujte tudi flush kot zasilno stikalo.

Nato naštejte vmesnike, ker je ime, ki ste ga predpostavili, ime, ki bi ga morali prebrati: ip -br link pokaže, kaj obstaja prav zdaj, in tunel se ne bo pojavil, dokler ne bo dvignjen. Zapisujte imena naprav, ko jih berete.

Korak 2: dajte tunelu njegovo ime

OpenVPN v konfiguraciji odjemalca sprejme dev tun_work, in Linux nato ustvari vmesnik s točno tem imenom, namesto da bi dodelil tun0. Ime ostane stabilno med ponovnimi povezavami, dokler si ga nič drugega ne lasti, in prav zato je pravilo, ki poimenuje napravo, smiselno.

Kjer imena ni mogoče nadzorovati, se ujemajte z naslovom tunela ali oznako paketa. Oba delujeta, oba se težje bereta in oba odpovedujeta tiše, ko se tunel preštevilči. V vsakem primeru se ujemajte z eno stvarjo in jasno povejte katero.

Korak 3: napišite politiko z izjemo za endpoint na prvem mestu

Gostitelj samo z VPN je gostitelj s privzeto zavrnitvijo in kratkim seznamom izjem, najpomembnejša izjema pa je tista, ki tunelu dovoli obstajati. Zgradite jo v tem vrstnem redu, s pravilom za endpoint pred pravilom za napravo tunela, da bo imela rokovanje kam iti:

# 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

Dobesedni naslov endpointa in vrata pripadajo vašemu ponudniku, ne tej strani. Če je endpoint ime gostitelja, ga razrešite enkrat in rezultat določite, ker pravilo ne more iskati imena in vrteči se odgovor bo tiho pokvaril politiko po naslednji spremembi DNS. Preverite tudi vrata, ker bodo ponudniki, ki vas prestavijo na TCP 443, sicer potrebovali pravilo, ki ga ni nihče zapisal. Tunel, ki deluje samo na enem protokolu, je običajno prav ta izpustitev in ne okvara požarnega zidu.

Na usmerjevalniku enaka oblika gre v verigo FORWARD za odjemalce za njim, lastni promet usmerjevalnika pa potrebuje lastna pravila. Nabor pravil, ki pokriva samo posredovane pakete, pusti SSH in DNS na stari poti, in tako usmerjevalnik postane nedosegljiv v trenutku, ko se tunel dvigne.

Korak 4: preverite vrstni red, ne le prisotnosti

Pravila se vrednotijo po vrsti, zato ACCEPT, ki pride prej, preprosto skrije REJECT, ki ste ga dodali pozneje. Ujemanje established in related je tisto, ki odgovorom na vaše lastne odhodne zahteve omogoči vrnitev, ne da bi odprlo splošno vhodno pot, in če ga postavite za sprejemom tunela, to pomeni, da padli tunel še vedno spusti povratni promet na svojem vmesniku.

Držite število pravil dovolj majhno, da jih preberete na enem zaslonu. Nabor pravil, ki ga ne morete revidirati, je tisti, ki ga boste zakrpali z dodajanjem izjem na vrhu, in tako politike privzete zavrnitve postopoma dobijo rob privzete dovolitve. Preštejte ACCEPT pred spremembo in po njej.

Korak 5: poskrbite, da bo preživel zagon in družino naslovov

Pravila, vnesena ročno, ob ponovnem zagonu izginejo, zato jih naložite iz storitve požarnega zidu distribucije ali iz enote, ki se zažene po tem, ko vmesnik tunela obstaja. Sklicevanje na tun_work v skriptu, ki se izvede pred zagonom OpenVPN, je pogost način za ustvarjanje zagonske zanke z zavrženim prometom.

Nato preverite IPv6 ločeno, ker dobra politika privzete zavrnitve za IPv4 ne pove ničesar o drugi družini. ip -6 route vam bo povedal, ali ima gostitelj pot, ki bi lahko nosila promet okoli tunela, ki obravnava samo IPv4, ip6tables ali nftables pa potrebuje svoja enakovredna pravila. Preizkusite s ciljem IPv6-only, namesto da bi zaupali simetriji nabora pravil.

Korak 6: preverite in bodite pripravljeni obnoviti

Dvignite tunel, potrdite, da predvidena storitev deluje, nato preizkusite nekaj, kar bi politika morala zavrniti. Obnovite z iptables-restore < /root/iptables.pre, če vas odgovor preseneti, in šele nato začnite urejati pravila. Vztrajnost skupaj s preizkušeno potjo obnovitve je tisto, kar iz tega naredi spremembo, ki jo lahko naredite dvakrat.