Firewall i VPS: hapni vetëm portën VPN, pastaj provojeni

Një firewall që lejon vetëm portën VPN nuk është një rregull i vetëm. Janë tre vendime të ndara që rastësisht prekin të njëjtin numër porte: zinxhiri i hyrjes vendos çfarë mund të arrijë një proces lokal, zinxhiri i përcjelljes vendos çfarë mund të kalojë përmes hostit në emër të klientëve të tunelit, dhe tabela NAT rishkruan adresën burimore në dalje. Gaboni njërën prej tyre dhe rezultati rrallë është një ndërprerje e pastër. Merrni një host që pranon klientë por nuk ngarkon asgjë, ose një host që duket i mbyllur derisa dikush të lexojë rendin e zinxhirëve.

Porta e vetme që nuk mund të mbyllet

Dëgjuesi i VPN duhet të pranojë lidhje nga adresa që nuk mund t’i parashikoni, prandaj është shërbim publik sipas përkufizimit. Ky është përjashtimi i vetëm mbi të cilin është ndërtuar dizajni: një portë UDP për OpenVPN, një portë UDP për WireGuard, një portë TCP për një VPN SSL. Gjithçka tjetër i përket pas tunelit, që do të thotë se shërbimet e aplikacioneve duhet të lidhen me adresën e tunelit ose me loopback, jo me të gjitha ndërfaqet.

Lidhja megjithatë nuk është zbatim. Një proces i lidhur me 0.0.0.0 është i arritshëm vetëm nëse një rregull e lejon, dhe politika e parazgjedhur është zëvendësimi për trafikun që nuk u përputh me asnjë rregull, jo rregulli që drejton portën. Një leje e vendosur mbi refuzimin tuaj mbetet leje, dhe zhvendosja e një shërbimi nga adresa publike është përmirësim i pavarur, jo zëvendësim i zinxhirit.

Hyrja, përcjellja dhe NAT përgjigjen pyetjeve të ndryshme

Trafiku i hyrjes është i destinuar për vetë hostin, prandaj atje jetojnë dëgjuesi i VPN dhe rruga administrative. Trafiku i përcjelljes kalon përmes hostit, dhe klientët e tunelit kanë nevojë për të së bashku me net.ipv4.ip_forward=1. Konfigurimi klasik gjysmë i prishur lejon rrjedhën dalëse dhe harron drejtimin e kthimit, kështu që klienti përfundon shtrëngimin e duarve dhe pastaj nuk ngarkohet asgjë; një rregull conntrack për trafikun e vendosur dhe të lidhur mbulon atë drejtim.

NAT është pyetja e tretë. Pa rishkrim në postrouting, paketat e përcjella dalin me burimin privat të tunelit dhe hidhen më lart, sepse asnjë rrjet përtej hostit nuk di të rrugëzojë pishinën prapa. Parashtesa e burimit në atë rregull duhet të përputhet me pishinën e VPN, jo me adresën e vetë hostit, dhe e njëjta gjë vlen për rregullin e përcjelljes që emërton nënrrjetin e klientëve.

IPv6 është një politikë e dytë, jo mendim i mëvonshëm. Një host me zinxhir të rreptë IPv4 dhe politikë të hapur në ip6tables nuk ka mbyllur asgjë; shërbimet janë ende të arritshme përmes familjes tjetër. Ose pasqyroni grupin e rregullave me ip6tables, ose çaktivizoni IPv6 me qëllim në ndërfaqen publike, dhe shkruani cilën zgjodhët.

Një bazë e lexueshme në një kalim

Filloni me refuzim, pastaj shtoni vetëm atë që i nevojitet hostit. Së pari loopback dhe përgjigjet, pastaj rruga administrative, pastaj dëgjuesi i tunelit, pastaj politika e përcjelljes për klientët:

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

Emrat e ndërfaqeve, porta dhe pishina janë vendmbajtëse; lexojini nga serveri në vend që t’i kopjoni. Ruajtja e rezultatit është po aq e rëndësishme sa shkrimi i tij, sepse një grup rregullash që jeton vetëm në memorie zhduket në rindezjen tjetër dhe e rihap hostin në heshtje. Bëjeni të përhershëm me mekanizmin e shpërndarjes dhe mbani një kopje jashtë makinës për ditën kur makina nuk do të niset.

Mbyllja e portës së fundit pa humbur hostin

Në dizajn ka një grackë. Nëse SSH ekziston vetëm përmes tunelit, një shërbim VPN që dështon e merr SSH me vete, dhe e vetmja rrugë kthimi mund të jetë një konsolë që nuk e keni hapur kurrë. Përpara se të mbyllni portën e fundit publike, konfirmoni se ajo konsolë ekziston dhe se vërtet mund ta përdorni, ose mbani një rrugë të ngushtë administrative që nuk varet nga tuneli: SSH nga një adresë fikse, vetëm çelësa, autentikimi me fjalëkalim i fikur.

Zbatojeni ndryshimin nga një sesion i krijuar tashmë, jo përmes lidhjes që po e filtroni. Planifikoni një kthim prapa që gabimi të skadojë në vend që të bëhet i përhershëm, për shembull një detyrë systemd-run --on-active=10min që rikthen grupin e mëparshëm të rregullave, dhe mbani një sesion të dytë SSH të hapur ndërsa provoni të parin. Pastaj verifikoni se detyra e kthimit prapa vërtet aktivizohet, sepse një rikuperim i paprovuar është njësoj si asnjë rikuperim.

Verifikoni rrugën, jo skriptin

Lexoni rregullat e ngarkuara, jo skedarin që duhej t’i ngarkonte. Nga një host i jashtëm i autorizuar, konfirmoni se përgjigjen vetëm portat e synuara; nga brenda tunelit, konfirmoni se shërbimet që donit të publikoni janë të arritshme. Një politikë refuzimi e parazgjedhur që bllokon edhe trafikun e tunelit duket identike me një mbyllje funksionale derisa dikush të përpiqet ta përdorë.

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

Shënoni portën e lejuar, pishinën e klientëve, ndërfaqen e tunelit, burimin administrativ dhe procedurën e konsolës pranë konfigurimit. Ndryshimi i ardhshëm i pishinës ose i emrit të ndërfaqes duhet të pasqyrohet si në filtër ashtu edhe në rregullin NAT, përndryshe hosti kthehet në një gjendje gjysmë të hapur pa e vënë re askush.

Një zakon vlen më shumë se grupi i rregullave: pas çdo ndryshimi, provoni rrugën e përcjelljes me një kërkesë klienti dhe rrugën e rikuperimit me një sesion të dytë. Një mbyllje që nuk e keni përdorur është thjesht hipotezë.