iptables host samo s VPN-om: imenujte tun uređaj, ne tun+

Pisanje -o tun+ izgleda kao precizna instrukcija, a zapravo je zamjenski znak koji odgovara svakom tunelu koji kernel ima. Drugi VPN klijent, kontejnerski most ili interfejs koji je ostavila srušena sesija, svi ga zadovoljavaju, i host tada propušta saobraćaj koji je politika trebalo da spriječi. Procedura ispod fiksira jedno ime uređaja, poreda izuzetke tako da se tunel zaista može formirati i ostavlja vam put nazad ako pravila loše legnu. Svaki korak je dovoljno kratak da se poništi sam.

Korak 1: zabilježite pravila koja sada imate

Prije promjene zadane politike, sačuvajte trenutno stanje da vraćanje bude komanda, a ne sjećanje. iptables-save > /root/iptables.pre upisuje svaku tabelu u fajl koji možete vratiti, a drugi terminal s otvorenom root sesijom nije paranoja kada politika koju ćete postaviti prekine vezu koja je nosi. Ako radite daljinski, zakažite i flush kao prekidač za slučaj nužde.

Zatim izlistajte interfejse, jer ime koje ste pretpostavili je ime koje ste trebali pročitati: ip -br link pokazuje šta postoji upravo sada, a tunel se neće pojaviti dok ne bude podignut. Zapisujte imena uređaja dok ih čitate.

Korak 2: dajte tunelu njegovo ime

OpenVPN prihvata dev tun_work u konfiguraciji klijenta, i Linux tada stvara interfejs s točno tim imenom umjesto da dodijeli tun0. Ime ostaje stabilno kroz ponovna povezivanja dok god ga ništa drugo ne traži, i to je ono što pravi pravilo koje imenuje uređaj smislenim.

Gdje se imenom ne može upravljati, umjesto toga podudarajte po adresi tunela ili po oznaci paketa. Oba rade, oba se teže čitaju i oba tiše otkazuju kada tunel promijeni numeraciju. U svakom slučaju, podudarajte po jednoj stvari i budite jasni kojoj.

Korak 3: napišite politiku s izuzetkom za endpoint prvim

Host samo s VPN-om je host sa zadanim odbijanjem i kratkom listom izuzetaka, a izuzetak koji je najvažniji je onaj koji dopušta da tunel postoji. Gradite ga ovim redom, s pravilom za endpoint prije pravila za uređaj tunela, da rukovanje ima kuda otići:

# 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

Doslovna adresa endpointa i port pripadaju vašem provajderu, ne ovoj stranici. Ako je endpoint ime hosta, razriješite ga jednom i fiksirajte rezultat, jer pravilo ne može tražiti ime, a odgovor koji se mijenja tiho će slomiti politiku nakon sljedeće promjene DNS-a. Provjerite i port, jer provajderi koji vas premjeste na TCP 443 inače će trebati pravilo koje niko nije zapisao. Tunel koji radi samo na jednom protokolu obično je upravo ovaj propust, a ne kvar firewall-a.

Na ruteru isti oblik ide u FORWARD lanac za klijente iza njega, a ruterov vlastiti saobraćaj traži vlastita pravila. Skup pravila koji pokriva samo proslijeđene pakete ostavlja SSH i DNS na starom putu, i tako ruter postaje nedostupan u trenutku kada se tunel podigne.

Korak 4: provjerite redoslijed, ne samo prisustvo

Pravila se ocjenjuju redom, pa ACCEPT koji dolazi ranije jednostavno skriva REJECT koji ste dodali kasnije. Podudaranje established i related je ono što pušta odgovore na vaše vlastite odlazne zahtjeve da se vrate bez otvaranja općeg ulaznog puta, a postavljanje nakon prihvata tunela znači da srušeni tunel još uvijek propušta povratni saobraćaj na svom interfejsu.

Držite broj pravila dovoljno malim da se pročita na jednom ekranu. Skup pravila koji ne možete revidirati je onaj koji ćete krpiti dodavanjem izuzetaka na vrh, i tako politike zadanog odbijanja postepeno dobijaju ivicu zadanog dopuštanja. Prebrojite ACCEPT-e prije i poslije promjene.

Korak 5: neka preživi podizanje i adresnu familiju

Pravila unesena ručno nestaju pri restartu, pa ih učitajte iz distribucijske firewall usluge ili unit-a koji se izvršava nakon što interfejs tunela postoji. Pozivanje na tun_work u skripti koja se izvršava prije nego OpenVPN krene čest je način da se proizvede petlja podizanja s odbačenim saobraćajem.

Zatim provjerite IPv6 odvojeno, jer dobra politika zadanog odbijanja za IPv4 ne govori ništa o drugoj familiji. ip -6 route će vam reći ima li host rutu koja bi mogla nositi saobraćaj oko tunela koji obrađuje samo IPv4, a ip6tables ili nftables traži svoja ekvivalentna pravila. Testirajte s odredištem IPv6-only umjesto da vjerujete simetriji skupa pravila.

Korak 6: provjerite i budite spremni za vraćanje

Podignite tunel, potvrdite da željena usluga radi, pa probajte nešto što bi politika trebalo da odbije. Vratite pomoću iptables-restore < /root/iptables.pre ako vas odgovor iznenadi, i tek tada počnite uređivati pravila. Trajnost plus testirana putanja vraćanja je ono što ovo čini promjenom koju možete napraviti dvaput.