VPS-fajroŝirmilo: malfermu nur la VPN-pordon kaj poste pruvu ĝin

Unu pordo devas resti publika, alie neniu kliento konektiĝas. Rifuzu la ceterajn, tenu la plusendadon aparte de la enigo, kaj lasu reakiran vojon, kiun vi provis antaŭe.

Fajroŝirmilo, kiu permesas nur la VPN-pordon, ne estas unu regulo. Ĝi estas tri apartaj decidoj, kiuj hazarde temas pri la sama pordnumero: la eniga ĉeno decidas, kio povas atingi lokan procezon, la plusenda ĉeno decidas, kio povas pasi tra la gastiganto nome de tunelaj klientoj, kaj la NAT-tabelo reskribas la fontan adreson survoje eksteren. Se vi eraras pri unu el ili, la rezulto malofte estas pura interrompo. Vi ricevas gastiganton, kiu akceptas klientojn sed ŝargas nenion, aŭ gastiganton, kiu aspektas ŝlosita ĝis iu legas la ordon de la ĉenoj.

La sola pordo, kiu ne povas esti fermita

La VPN-aŭskultanto devas akcepti konektojn el adresoj, kiujn vi ne povas antaŭvidi, do ĝi estas publika servo laŭdifine. Tio estas la sola escepto, ĉirkaŭ kiu la dezajno estas konstruita: unu UDP-pordon por OpenVPN, unu UDP-pordon por WireGuard, unu TCP-pordon por SSL VPN. Ĉio alia apartenas malantaŭ la tunelo, kio signifas, ke aplikaj servoj ligu sin al la tunela adreso aŭ al loopback, ne al ĉiu interfaco.

Ligado tamen ne estas devigado. Procezo ligita al 0.0.0.0 estas atingebla nur se regulo permesas ĝin, kaj la apriora politiko estas la rezervaĵo por trafiko, kiun neniu regulo trafis, ne la regulo, kiu regas la pordon. Permeso metita super via forĵeto restas permeso, kaj movi servon for de la publika adreso estas sendependa plibonigo, ne anstataŭaĵo por la ĉeno.

Enigo, plusendado kaj NAT respondas malsamajn demandojn

Eniga trafiko estas destinita al la gastiganto mem, do tie loĝas la VPN-aŭskultanto kaj la administra vojo. Plusenda trafiko pasas tra la gastiganto, kaj tunelaj klientoj bezonas ĝin plus net.ipv4.ip_forward=1. La klasika duone rompita agordo permesas la eliran fluon kaj forgesas la revenan direkton, tiel ke la kliento finas sian manpremon kaj poste ŝargas nenion; regulo conntrack por establita kaj rilata trafiko kovras tiun direkton.

NAT estas la tria demando. Sen reskribo en postrouting, plusenditaj pakaĵoj eliras kun la privata tunela fonto kaj estas forĵetitaj pli supre, ĉar neniu reto preter la gastiganto scias, kiel marsruti la naĝejon reen. La fontprefikso en tiu regulo devas kongrui kun la VPN-naĝejo, ne kun la propra adreso de la gastiganto, kaj same validas por la plusenda regulo, kiu nomas la klientan subreton.

IPv6 estas dua politiko, ne postpenso. Gastiganto kun severa IPv4-ĉeno kaj malfermita ip6tables-politiko fermis nenion; la servoj restas atingeblaj per la alia familio. Aŭ spegulu la regulkompleton per ip6tables, aŭ intence malŝaltu IPv6 sur la publika interfaco, kaj skribu, kiun vi elektis.

Baza linio, kiun oni povas legi en unu fojo

Komencu per forĵeto, poste aldonu nur tion, kion la gastiganto bezonas. Unue loopback kaj respondoj, poste la administra vojo, poste la tunela aŭskultanto, poste la plusenda politiko por klientoj:

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

Interfacaj nomoj, la pordo kaj la naĝejo estas lokokupiloj; legu ilin el la servilo anstataŭ kopii ilin. Konservi la rezulton estas same grave kiel skribi ĝin, ĉar regulkompleto, kiu vivas nur en memoro, malaperas ĉe la sekva restartigo kaj kviete remalfermas la gastiganton. Daŭrigu ĝin per la mekanismo de la distribuo, kaj tenu kopion ekster la maŝino por la tago, kiam la maŝino ne startos.

Fermi la lastan pordon sen perdi la gastiganton

Estas kaptilo en la dezajno. Se SSH ekzistas nur tra la tunelo, malsukcesa VPN-servo forportas SSH kun si, kaj la sola vojo reen povas esti konzolo, kiun vi neniam malfermis. Antaŭ ol fermi la lastan publikan pordon, konfirmu, ke tiu konzolo ekzistas kaj ke vi vere povas uzi ĝin, aŭ tenu unu mallarĝan administran vojon, kiu ne dependas de la tunelo: SSH el fiksa adreso, nur ŝlosiloj, pasvorta aŭtentigo malŝaltita.

Apliku la ŝanĝon el jam establita seanco, ne tra la konekto, kiun vi estas filtronta. Planu restarigon, por ke eraro eksvalidiĝu anstataŭ fariĝi daŭra, ekzemple tasko systemd-run --on-active=10min, kiu restarigas la antaŭan regulkompleton, kaj tenu duan SSH-seancon malfermita dum vi testas la unuan. Poste kontrolu, ĉu la restariga tasko vere ekvalidas, ĉar netestita reakirado egalas al neniu reakirado.

Kontrolu la vojon, ne la skripton

Legu la ŝarĝitajn regulojn, ne la dosieron, kiu laŭplane ŝargu ilin. El rajtigita ekstera gastiganto, konfirmu, ke nur la celitaj pordoj respondas; el la interno de la tunelo, konfirmu, ke la servoj, kiujn vi intencis publikigi, estas atingeblaj. Apriora rifuza politiko, kiu ankaŭ blokas tunelan trafikon, aspektas identa al funkcianta ŝlosado ĝis iu provas uzi ĝin.

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

Notu la permesitan pordon, la klientan naĝejon, la tunelan interfacon, la administran fonton kaj la konzolan proceduron apud la agordo. La sekva ŝanĝo al la naĝejo aŭ la interfaca nomo devas kongrui kaj en la filtrilo kaj en la NAT-regulo, alie la gastiganto revenas al duone malfermita stato sen ke iu rimarkas.

Unu kutimo valoras pli ol la regulkompleto: post ĉiu ŝanĝo, pruvu la plusendan vojon per klienta peto kaj la reakiran vojon per dua seanco. Ŝlosado, kiun vi ne uzis, estas hipotezo.

Rilataj artikoloj