iptables-host ainult VPN-iga: nimeta tun-seade, mitte tun+

-o tun+ kirjutamine tundub täpse juhisena ja on tegelikult metamärk, mis haarab iga kerneli tunnelit. Teine VPN-klient, konteinerisild või kokkukukkunud sessioonist jäänud liides vastavad sellele kõik, ja siis lubab host liiklust, mille poliitika pidi takistama. Allolev juhend kinnitab ühe seadme nime, järjestab erandid nii, et tunnel saaks tegelikult tekkida, ja jätab sulle tagasitee, kui reeglid halvasti maanduvad. Iga samm on piisavalt lühike, et selle saaks eraldi tagasi võtta.

Samm 1: kirjuta üles reeglid, mis sul praegu on

Enne vaikepoliitika muutmist salvesta praegune olek, et tagasipööramine oleks käsk, mitte mälestus. iptables-save > /root/iptables.pre kirjutab iga tabeli faili, mille saad taastada, ja teine terminal avatud root-sessiooniga ei ole paranoia, kui poliitika, mida hakkad seadma, katkestab ühenduse, mis seda kannab. Kui töötad kaugelt, ajasta ka flush kui hädaseiskamisnupp.

Seejärel loetle liidesed, sest nimi, mida eeldasid, on nimi, mille oleksid pidanud lugema: ip -br link näitab, mis praegu olemas on, ja tunnel ei ilmu enne, kui see on üleval. Kirjuta seadmete nimed üles nii, nagu neid loed.

Samm 2: anna tunnelile oma nimi

OpenVPN võtab kliendi konfiguratsioonis vastu dev tun_work, ja siis loob Linux täpselt selle nimega liidese, selle asemel et eraldada tun0. Nimi püsib ühenduste vahel stabiilne seni, kuni miski muu seda ei nõua, ja just see teeb seadet nimetava reegli mõttekaks.

Kus nime ei saa kontrollida, sobi hoopis tunneli aadressi või paketimärgise järgi. Mõlemad töötavad, mõlemaid on raskem lugeda ja mõlemad ebaõnnestuvad vaiksemalt, kui tunnel ümber nummerdub. Igal juhul sobi ühe asja järgi ja ole selge, millise.

Samm 3: kirjuta poliitika nii, et endpoint-erand on esimene

Ainult VPN-iga host on vaikimisi keelav host lühikese erandite loendiga, ja kõige olulisem erand on see, mis laseb tunnelil olemas olla. Ehita see selles järjekorras, endpoint-reegel enne tunnelseadme reeglit, et käepigistusel oleks kuhu minna:

# 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

Sõnasõnaline endpoint-i aadress ja port kuuluvad sinu teenusepakkujale, mitte sellele lehele. Kui endpoint on hostinimi, lahenda see üks kord ja kinnita tulemus, sest reegel ei saa nime otsida ja pöörlev vastus rikub poliitika vaikselt järgmise DNS-i muudatuse järel. Kontrolli ka porti, sest pakkujad, kes viivad sind TCP 443 peale, vajavad muidu reeglit, mida keegi ei kirjutanud. Tunnel, mis töötab ainult ühe protokolliga, on tavaliselt just see puudujääk, mitte tulemüüri rike.

Ruuteril läheb sama kuju FORWARD-ahelasse selle taga olevate klientide jaoks, ja ruuteri enda liiklus vajab oma reegleid. Reeglistik, mis katab ainult edastatud paketid, jätab SSH ja DNS vanale teele, ja nii muutub ruuter kättesaamatuks hetkel, kui tunnel üles tuleb.

Samm 4: kontrolli järjekorda, mitte ainult olemasolu

Reegleid hinnatakse järjest, nii et varem tulev ACCEPT lihtsalt peidab hiljem lisatud REJECT-i. Just established ja related sobivus laseb vastustel sinu enda väljuvatele päringutele tagasi tulla, ilma et avataks üldine sissetulev tee, ja selle paigutamine tunneli vastuvõtu järele tähendab, et maha visatud tunnel laseb endiselt tagasiliiklust oma liidesel läbi.

Hoia reeglite arv piisavalt väike, et see ühele ekraanile mahuks. Reeglistik, mida sa ei suuda auditeerida, on see, mida hakkad lappima ülaossa erandeid lisades, ja nii omandavad vaikimisi keelavad poliitikad järk-järgult vaikimisi lubava serva. Loenda ACCEPT-id enne ja pärast muudatust.

Samm 5: tee nii, et see elab üle alglaadimise ja aadressiperekonna

Käsitsi sisestatud reeglid kaovad taaskäivitamisel, seega laadi need distributsiooni tulemüüriteenusest või unit-ist, mis käivitub pärast tunneli liidese olemasolu. Viidata tun_work-le skriptis, mis käivitub enne OpenVPN-i algust, on levinud viis tekitada äravisatud liiklusega alglaadimistsükkel.

Seejärel kontrolli IPv6 eraldi, sest hea IPv4 vaikimisi keelav poliitika ei ütle teise perekonna kohta midagi. ip -6 route ütleb sulle, kas hostil on marsruut, mis võiks kanda liiklust ümber tunneli, mis käsitleb ainult IPv4, ja ip6tables või nftables vajab omi samaväärseid reegleid. Testi IPv6-only sihtmärgiga, selle asemel et usaldada reeglistiku sümmeetriat.

Samm 6: kontrolli ja ole taastamiseks valmis

Tõsta tunnel üles, kinnita, et kavatsetud teenus töötab, ja proovi siis midagi, mida poliitika peaks keelduma. Taasta iptables-restore < /root/iptables.pre abil, kui vastus sind üllatab, ja alles siis alusta reeglite muutmist. Püsivus pluss testitud taastamistee on see, mis teeb sellest muudatuse, mille saad teha kaks korda.