Tulemüür, mis lubab ainult VPN-i porta, ei ole üks reegel. See on kolm eraldi otsust, mis juhtumisi puudutavad sama pordi numbrit: sisendkett otsustab, mida võib jõuda kohaliku protsessini, edastuskett otsustab, mida võib tunneli klientide nimel hostist läbi minna, ja NAT-tabel kirjutab väljareljel lähteaadressi ümber. Kui eksid ühes neist, on tulemus harva puhas katkestus. Saad hosti, mis võtab kliente vastu, aga ei laadi midagi, või hosti, mis näib suletud, kuni keegi loeb kettide järjekorda.

Ainus port, mida ei saa sulgeda

VPN-i kuulaja peab vastu võtma ühendusi aadressidelt, mida ei saa ette näha, seega on see definitsiooni järgi avalik teenus. See on ainus erand, mille ümber disain on ehitatud: üks UDP-port OpenVPN jaoks, üks UDP-port WireGuardi jaoks, üks TCP-port SSL VPN-i jaoks. Kõik muu kuulub tunneli taha, mis tähendab, et rakendusteenused peaksid siduma end tunneli aadressi või loopbackiga, mitte kõigi liidestega.

Sidumine ei ole aga jõustamine. 0.0.0.0-ga seotud protsess on kättesaadav ainult siis, kui reegel seda lubab, ja vaikepoliitika on tagatis liiklusele, millele ükski reegel ei vastanud, mitte porti juhtiv reegel. Sinna kohale pandud luba on ikka luba, ja teenuse avalikult aadressilt eemale viimine on iseseisev parendus, mitte keti asendus.

Sisend, edastamine ja NAT vastavad eri küsimustele

Sisendliiklus on suunatud hostile endale, nii et seal elavad VPN-i kuulaja ja haldustee. Edastusliiklus läbib hosti ja tunneli kliendid vajavad seda koos net.ipv4.ip_forward=1-ga. Klassikaline poolikult töötav seadistus lubab väljuvat voogu ja unustab tagasisuuna, nii et klient lõpetab käepigistuse ja siis ei laeta midagi; conntrack-reegel loodud ja seotud liikluse jaoks katab selle suuna.

NAT on kolmas küsimus. Ilma postroutingi ümberkirjutuseta lahkuvad edastatud paketid tunneli privaatse lähtega ja visatakse ülalpool ära, sest ükski hostist kaugemal asuv võrk ei tea, kuidas basseini tagasi suunata. Selle reegli lähteprefiks peab vastama VPN-i basseinile, mitte hosti enda aadressile, ja sama kehtib edastusreegli kohta, mis nimetab kliendi alamvõrku.

IPv6 on teine poliitika, mitte järelmõte. Host, millel on range IPv4-kett ja avatud ip6tables poliitika, ei ole midagi sulgenud; teenused on teise perekonna kaudu endiselt kättesaadavad. Kas peegelda reeglistikku ip6tables-ga või lülita IPv6 avalikul liidesel teadlikult välja, ja pane kirja, kumma valisid.

Baasjoon, mida saab ühe pilguga lugeda

Alusta keelamisega ja lisa siis ainult see, mida host vajab. Kõigepealt loopback ja vastused, siis haldustee, siis tunneli kuulaja, siis klientide edastuspoliitika:

iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -A INPUT -i lo -j ACCEPT
iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -p tcp --dport 22 -m conntrack --ctstate NEW -j ACCEPT
iptables -A INPUT -p udp --dport 1194 -m conntrack --ctstate NEW -j ACCEPT
sysctl -w net.ipv4.ip_forward=1
iptables -A FORWARD -i tun0 -o eth0 -s 10.8.0.0/24 -j ACCEPT
iptables -A FORWARD -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE

Liideste nimed, port ja bassein on kohahoidjad; loe need serverist, mitte ära kopeeri. Tulemuse salvestamine on sama oluline kui selle kirjutamine, sest ainult mälus elav reeglistik kaob järgmisel taaskäivitusel ja avab hosti vaikselt uuesti. Tee see püsivaks distributsiooni mehhanismiga ja hoia koopiat väljaspool masinat selleks päevaks, mil masin ei käivitu.

Viimase pordi sulgemine hosti kaotamata

Disainis on konks. Kui SSH on olemas ainult tunneli kaudu, võtab ebaõnnestunud VPN-teenus SSH endaga kaasa ja ainus tee tagasi võib olla konsool, mida sa pole kunagi avanud. Enne viimase avaliku pordi sulgemist veendu, et see konsool on olemas ja et saad seda tõesti kasutada, või jäta üks kitsas haldustee, mis ei sõltu tunnelist: SSH fikseeritud aadressilt, ainult võtmed, parooli autentimine väljas.

Rakenda muudatus juba loodud sessioonist, mitte ühenduse kaudu, mida kavatsed filtreerida. Kavanda tagasipööramine, et viga aeguks, mitte ei muutuks püsivaks, näiteks systemd-run --on-active=10min töö, mis taastab eelmise reeglistiku, ja hoia teist SSH-sessiooni avatuna, kuni esimest testid. Seejärel kontrolli, et tagasipööramise töö tõesti käivitub, sest testimata taaste on sama mis taaste puudumine.

Kontrolli teed, mitte skripti

Loe laaditud reegleid, mitte faili, mis pidi need laadima. Volitatud välisest hostist veendu, et vastavad ainult ettenähtud pordid; tunneli seest veendu, et teenused, mida tahtsid avaldada, on kättesaadavad. Vaikimisi keelav poliitika, mis blokeerib ka tunneli liikluse, näeb välja täpselt nagu toimiv lukustus, kuni keegi proovib seda kasutada.

iptables -S
iptables -t nat -S
ss -lntup
ip -4 addr show

Kirjuta lubatud port, kliendibassein, tunneli liides, haldusallikas ja konsooli protseduur konfiguratsiooni kõrvale. Järgmine muudatus basseinis või liidese nimes tuleb sobitada nii filtris kui ka NAT-reeglis, muidu naaseb host poolavatud olekusse, ilma et keegi märkaks.

Üks harjumus on väärt rohkem kui reeglistik: pärast igat muudatust tõesta edastustee kliendi päringuga ja taastetee teise sessiooniga. Lukustus, mida sa pole kasutanud, on hüpotees.

Seotud artiklid