VPS ugunsmūris: atveriet tikai VPN portu un pēc tam to pierādiet

Ugunsmūris, kas ielaiž tikai VPN portu, nav viens noteikums. Tie ir trīs atsevišķi lēmumi, kas nejauši attiecas uz to pašu porta numuru: ievades ķēde nosaka, kas var sasniegt lokālu procesu, pāradresācijas ķēde nosaka, kas var iziet caur resursdatoru tuneļa klientu vārdā, un NAT tabula pārraksta avota adresi izejot. Kļūdieties vienā no tiem, un rezultāts reti ir tīrs pārtraukums. Jūs iegūstat resursdatoru, kas pieņem klientus, bet neko neielādē, vai resursdatoru, kas izskatās aizvērts, līdz kāds izlasa ķēžu secību.

Vienīgais ports, ko nevar aizvērt

VPN klausītājam jāpieņem savienojumi no adresēm, kuras nevarat paredzēt, tāpēc tas pēc definīcijas ir publisks pakalpojums. Šis ir vienīgais izņēmums, uz kura balstīts dizains: viens UDP ports OpenVPN, viens UDP ports WireGuard, viens TCP ports SSL VPN. Viss pārējais pieder aiz tuneļa, tas nozīmē, ka lietojumprogrammu pakalpojumiem jāsaistās ar tuneļa adresi vai loopback, nevis ar visām saskarnēm.

Tomēr saistīšana nav izpilde. Process, kas saistīts ar 0.0.0.0, ir sasniedzams tikai tad, ja noteikums to ielaiž, un noklusējuma politika ir rezerves variants trafikam, kam neatbilda neviens noteikums, nevis portu vadības noteikums. Virs jūsu drop novietots accept joprojām ir accept, un pakalpojuma pārvietošana prom no publiskās adreses ir patstāvīgs uzlabojums, nevis ķēdes aizstājējs.

Ievade, pāradresācija un NAT atbild uz dažādiem jautājumiem

Ievades trafiks ir adresēts pašam resursdatoram, tāpēc tur dzīvo VPN klausītājs un administratīvais ceļš. Pāradresācijas trafiks iet caur resursdatoru, un tuneļa klientiem tas nepieciešams kopā ar net.ipv4.ip_forward=1. Klasiskā pa pusei salauztā konfigurācija atļauj izejošo plūsmu un aizmirst atgriešanās virzienu, tāpēc klients pabeidz roku saspaidīšanu un pēc tam nekas neielādējas; noteiktā un saistītā trafika conntrack noteikums nosedz šo virzienu.

NAT ir trešais jautājums. Bez pārrakstīšanas postrouting pāradresētie paketi iziet ar tuneļa privāto avotu un tiek izmesti augstāk, jo neviens tīkls aiz resursdatora nezina, kā maršrutēt baseinu atpakaļ. Avota prefiksam šajā noteikumā jāatbilst VPN baseinam, nevis paša resursdatora adresei, un tas pats attiecas uz pāradresācijas noteikumu, kas nosauc klientu apakštīklu.

IPv6 ir otra politika, nevis vēlāka doma. Resursdators ar stingru IPv4 ķēdi un atvērtu ip6tables politiku neko nav aizvēris; pakalpojumi joprojām ir sasniedzami caur otru saimi. Vai nu atspoguļojiet noteikumu kopu ar ip6tables, vai arī apzināti izslēdziet IPv6 publiskajā saskarnē, un pierakstiet, kuru izvēlējāties.

Pamatlīnija, ko nolasa vienā piegājienā

Sāciet ar noraidīšanu, pēc tam pievienojiet tikai to, kas resursdatoram nepieciešams. Vispirms loopback un atbildes, tad administratīvais ceļš, tad tuneļa klausītājs, tad pāradresācijas politika klientiem:

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

Saskarņu nosaukumi, ports un baseins ir vietturi; lasiet tos no servera, nevis kopējiet. Rezultāta saglabāšana ir tikpat svarīga kā tā rakstīšana, jo noteikumu kopa, kas dzīvo tikai atmiņā, pazūd nākamajā pārstartēšanā un klusi atkal atver resursdatoru. Padariet to noturīgu ar distribūcijas mehānismu un glabājiet kopiju ārpus mašīnas tai dienai, kad mašīna neieslēgsies.

Aizvērt pēdējo portu, nezaudējot resursdatoru

Dizainā ir slazds. Ja SSH pastāv tikai caur tuneli, neizdevies VPN pakalpojums aiznes līdzi SSH, un vienīgais ceļš atpakaļ var būt konsole, kuru nekad neesat atvēris. Pirms aizverat pēdējo publisko portu, pārliecinieties, ka šī konsole pastāv un ka to tiešām varat izmantot, vai paturiet vienu šauru administratīvo ceļu, kas nav atkarīgs no tuneļa: SSH no fiksētas adreses, tikai atslēgas, paroles autentifikācija izslēgta.

Piemērojiet izmaiņas no jau izveidotas sesijas, nevis caur savienojumu, kuru grasāties filtrēt. Ieplānojiet atritināšanu, lai kļūda beigtos, nevis kļūtu pastāvīga, piemēram, systemd-run --on-active=10min uzdevumu, kas atjauno iepriekšējo noteikumu kopu, un turiet atvērtu otru SSH sesiju, kamēr testējat pirmo. Pēc tam pārbaudiet, vai atritināšanas uzdevums tiešām nostrādā, jo nepārbaudīta atjaunošana ir tas pats, kas tās neesamība.

Pārbaudiet ceļu, nevis skriptu

Lasiet ielādētos noteikumus, nevis failu, kuram tie bija jāielādē. No autorizēta ārēja resursdatora pārliecinieties, ka atbild tikai paredzētie porti; no tuneļa iekšpuses pārliecinieties, ka pakalpojumi, kurus gribējāt publicēt, ir sasniedzami. Noklusējuma aizlieguma politika, kas bloķē arī tuneļa trafiku, izskatās tieši tāpat kā strādājoša bloķēšana, līdz kāds mēģina to izmantot.

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

Pierakstiet atļauto portu, klientu baseinu, tuneļa saskarni, administratīvo avotu un konsoles procedūru līdzās konfigurācijai. Nākamā izmaiņa baseinā vai saskarnes nosaukumā jāsaskaņo gan filtrā, gan NAT noteikumā, citādi resursdators atgriežas daļēji atvērtā stāvoklī, un neviens to nepamana.

Viens paradums ir vērtīgāks par noteikumu kopu: pēc katras izmaiņas pierādiet pāradresācijas ceļu ar klienta pieprasījumu un atjaunošanas ceļu ar otru sesiju. Bloķēšana, ko neesat izmantojis, ir tikai hipotēze.