VPS užkarda: atidarykite tik VPN prievadą ir tada tai įrodykite

Vienas prievadas turi likti viešas, kitaip ne vienas klientas neprisijungs. Atmeskite likusius, laikykite persiuntimą atskirai nuo įėjimo ir palikite iš anksto išbandytą atkūrimo kelią.

Užkarda, kuri praleidžia tik VPN prievadą, nėra viena taisyklė. Tai trys atskiri sprendimai, kurie atsitiktinai liečia tą patį prievado numerį: įėjimo grandinė nusprendžia, kas gali pasiekti vietinį procesą, persiuntimo grandinė nusprendžia, kas gali pereiti per šeimininką tunelio klientų vardu, o NAT lentelė perrašo šaltinio adresą išeinant. Suklyskite viename ir rezultatas retai būna švarus nutrūkimas. Gaunate šeimininką, kuris priima klientus, bet nieko neįkelia, arba šeimininką, kuris atrodo uždarytas, kol kas nors perskaito grandinių tvarką.

Vienintelis prievadas, kurio negalima uždaryti

VPN klausytojas turi priimti ryšius iš adresų, kurių negalite numatyti, todėl pagal apibrėžimą tai vieša paslauga. Tai vienintelė išimtis, kuria grindžiamas dizainas: vienas UDP prievadas OpenVPN, vienas UDP prievadas WireGuard, vienas TCP prievadas SSL VPN. Visa kita priklauso už tunelio, vadinasi, programų paslaugos turėtų jungtis prie tunelio adreso arba loopback, o ne prie visų sąsajų.

Tačiau susiejimas nėra vykdymas. Procesas, susietas su 0.0.0.0, pasiekiamas tik jei taisyklė jį praleidžia, o numatytoji politika yra atsarginis variantas srautui, kurio neatitiko jokia taisyklė, o ne prievadą valdanti taisyklė. Virš jūsų drop padėtas accept vis tiek lieka accept, o paslaugos perkėlimas nuo viešo adreso yra savarankiškas pagerinimas, o ne grandinės pakaitalas.

Įėjimas, persiuntimas ir NAT atsako į skirtingus klausimus

Įėjimo srautas skirtas pačiam šeimininkui, todėl ten gyvena VPN klausytojas ir administravimo kelias. Persiuntimo srautas praeina per šeimininką, ir tunelio klientams jo reikia kartu su net.ipv4.ip_forward=1. Klasikinė pusiau sugedusi konfigūracija leidžia išeinantį srautą ir pamiršta grįžimo kryptį, todėl klientas baigia rankos paspaudimą ir tada nieko neįkelia; nustatyto ir susijusio srauto conntrack taisyklė padengia tą kryptį.

NAT yra trečias klausimas. Be perrašymo postrouting, persiųsti paketai išeina su privačiu tunelio šaltiniu ir yra metami aukščiau, nes joks tinklas už šeimininko ribų nemoka nukreipti baseino atgal. Tos taisyklės šaltinio priešdėlis turi atitikti VPN baseiną, o ne paties šeimininko adresą, ir tas pats galioja persiuntimo taisyklei, kuri įvardija klientų potinklį.

IPv6 yra antra politika, o ne vėlesnė mintis. Šeimininkas su griežta IPv4 grandine ir atvira ip6tables politika nieko neuždarė; paslaugos vis dar pasiekiamos per kitą šeimą. Arba veidrodiškai atkartokite taisyklių rinkinį su ip6tables, arba sąmoningai išjunkite IPv6 viešoje sąsajoje, ir užsirašykite, ką pasirinkote.

Bazė, kurią perskaitote vienu kartu

Pradėkite nuo atmetimo, tada pridėkite tik tai, ko reikia šeimininkui. Pirma loopback ir atsakymai, tada administravimo kelias, tada tunelio klausytojas, tada persiuntimo politika klientams:

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

Sąsajų pavadinimai, prievadas ir baseinas yra vietos žymekliai; skaitykite juos iš serverio, o ne kopijuokite. Rezultato išsaugojimas yra toks pat svarbus kaip jo parašymas, nes taisyklių rinkinys, gyvenantis tik atmintyje, dingsta per kitą paleidimą ir tyliai vėl atidaro šeimininką. Padarykite jį ilgaamžį paskirstymo mechanizmu ir laikykite kopiją už mašinos ribų dienai, kai mašina neįsibootins.

Uždaryti paskutinį prievadą neprarandant šeimininko

Dizaine yra spąstai. Jei SSH egzistuoja tik per tunelį, sugedusi VPN paslauga pasiima ir SSH, o vienintelis kelias atgal gali būti konsolė, kurios niekada neatidarėte. Prieš uždarydami paskutinį viešą prievadą patvirtinkite, kad ta konsolė egzistuoja ir kad ja tikrai galite naudotis, arba palikite vieną siaurą administravimo kelią, nepriklausantį nuo tunelio: SSH iš fiksuoto adreso, tik raktai, slaptažodžio autentifikavimas išjungtas.

Taikykite pakeitimą iš jau nustatytos sesijos, o ne per ryšį, kurį ketinate filtruoti. Suplanuokite atstatymą, kad klaida pasibaigtų, o netaptų nuolatine, pavyzdžiui, systemd-run --on-active=10min užduotį, kuri atkuria ankstesnį taisyklių rinkinį, ir laikykite antrą SSH sesiją atvirą, kol bandote pirmą. Tada patikrinkite, ar atstatymo užduotis tikrai paleidžiama, nes neišbandytas atkūrimas yra tas pats, kas jo nebuvimas.

Tikrinkite kelią, o ne scenarijų

Skaitykite įkeltas taisykles, o ne failą, kuris turėjo jas įkelti. Iš įgalioto išorinio šeimininko patvirtinkite, kad atsako tik numatyti prievadai; iš tunelio vidaus patvirtinkite, kad paslaugos, kurias norėjote paskelbti, yra pasiekiamos. Numatytoji draudimo politika, kuri blokuoja ir tunelio srautą, atrodo lygiai taip pat kaip veikiantis užrakinimas, kol kas nors pabando juo naudotis.

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

Užrašykite leidžiamą prievadą, klientų baseiną, tunelio sąsają, administravimo šaltinį ir konsolės procedūrą šalia konfigūracijos. Kitas baseino ar sąsajos pavadinimo pakeitimas turi būti suderintas ir filtre, ir NAT taisyklėje, kitaip šeimininkas grįš į pusiau atvirą būseną, ir niekas nepastebės.

Vienas įprotis vertas daugiau nei taisyklių rinkinys: po kiekvieno pakeitimo įrodykite persiuntimo kelią kliento užklausa, o atkūrimo kelią – antrąja sesija. Užrakinimas, kuriuo nesinaudojote, tėra hipotezė.

Susiję straipsniai