Limi OpenVPN-enirejon al unu LAN per UFW-reguloj

Decidu la permeson antaŭ ol malfermi fajroŝirman dosieron: aŭtentigitaj klientoj rajtas malfermi konektojn al unu specifa subreto, kaj la enirejo devas rifuzi ĉiun alian transitan vojon eĉ kiam kliento instalas pliajn vojojn. Tiu frazo estas la dezajno, kaj ĉiu regulo sube ekzistas por plenumi ĝin. Io pli vasta, kiel la tuta privata adresspaco, interreta eliro tra la tunelo aŭ samtavola trafiko, estas alia dezajno kiu bezonas sian propran decidon. La reguloj ankaŭ estas intence enuaj, ĉar lerta fajroŝirmilo estas tiu, kiun neniu povas poste revizii.

Unue skribu la topologion kaj la permeson

La ekzemplo uzas Community OpenVPN servilon kun TUN-aparato en uzantospaco nomata tun0, klienta baseno 10.77.0.0/24, kaj unu konektita subreto 192.168.60.0/24 sur lan0. IPv4-plusendado jam funkcias kaj la LAN jam havas revenan vojon al la baseno, do nenio ĉi tie dependas de tradukado inter ili.

UFW posedas la fajroŝirmilon sur ĉi tiu gastiganto, kaj neniu ujuja regularo nek aparta nftables-tabelo rajtas instali pli fruan akceptan vojon. Senpaga trafik-ellasiga vojeto kiu preteriras la filtrilon farus la gardsinjerojn ornamaj, do konfirmu ke neniu estas aktiva. Lasu la propran client-to-client plusendadon de OpenVPN malŝaltita, ĉar samtavola trafiko kiu neniam trapasas la filtrilon de la operaciumo ne povas esti limigita de ĝi. La ekstera aŭskultanto kaj la administraj reguloj restas kiel ili estas, ĉar ĉi tiu ŝanĝo regas malĉifritan tunelan trafikon anstataŭ anstataŭigi la fajroŝirmilon.

Metu la gardistojn antaŭ la fruaj akceptoj de UFW

Vojpermeso sekvata de rifuzo ne sufiĉas por strikta limo. La normaj before-reguloj akceptas establitajn trafikojn kaj elektitajn ICMP antaŭ ol konsulti iun ajn uzantregulon, do trafiko permesita pasintsemajne povas resti ekster la nova celolimo sole ĉar ĝi ankoraŭ havas staton. Faru sekurkopion de la UFW-dosieroj kaj tenu eksterbandan konzolon malfermita antaŭ redaktado.

En la sekcio *filter de la dosiero /etc/ufw/before.rules, deklaru du sinjorojn apud la ekzistantaj deklaroj kaj antaŭ iu ajn regula linio.

:vpn-src-guard - [0:0]
:vpn-reply-guard - [0:0]

Tuj post la deklaroj, kaj antaŭ la permesoj por enigo kaj plusendado, saltu en ilin kaj difinu kion ili permesas.

-A ufw-before-input -i tun0 -j DROP
-A ufw-before-forward -i tun0 -j vpn-src-guard
-A ufw-before-forward -o tun0 -j vpn-reply-guard

-A vpn-src-guard -o lan0 -d 192.168.60.0/24 -s 10.77.0.0/24 -m conntrack --ctdir ORIGINAL -j RETURN
-A vpn-src-guard -j DROP

-A vpn-reply-guard -i lan0 -d 10.77.0.0/24 -s 192.168.60.0/24 -m conntrack --ctstate RELATED,ESTABLISHED --ctdir REPLY -j RETURN
-A vpn-reply-guard -j DROP

Konservu la reston de la sekcio kaj ĝian linion COMMIT. Alglui duan filtran tabelon aŭ forigi nerilatajn regulojn estas la maniero kiel fajroŝirma ŝanĝo fariĝas interrompo, kaj la dosiero estas unu restartigo for de tio esti la sola kopio kiu gravas.

Legu kion ĉiu gardisto permesas kaj rifuzas

La unua sinjoro daŭrigas prilaboradon nur kiam la fonto estas en la baseno, la celo estas la unu subreto, la elira interfaco estas la LAN kaj la paketo vojaĝas en la origina direkto de sia trafiko. Ĉio alia alvenanta el la tunelo estas forĵetata, inkluzive fonton ekster la baseno kaj iun celon preter la permesita subreto.

Samtavola paketo eniras kaj eliras tun0, do ĝi malsukcesas la LAN-interfacan teston antaŭ ol cela kontrolo eĉ atingiĝas. Novaj konektoj de la LAN al klientoj ankaŭ malsukcesas la responddirektan teston, kio implicite fermas la inversan revokvojon.

La celo RETURN tenas ordinaran UFW-politikon en ludo. Ĉi tiuj sinjoroj filtras, kaj la vojpermeso kiun vi aldonas poste ankoraŭ decidas ĉu travivinta paketo akceptiĝos. Ĝuste tiu apartigo ebligas al vi poste ŝanĝi la permesitan subreton en unu loko. Se la gardistoj akceptus paketojn rekte, ĉiu estonta regulo devus esti aldonita dufoje.

Rajtigu la subreton kaj fermu la flankajn pordojn

Unue antaŭrigardu la vojpermeson, poste forigu la antaŭrigardan flagon por apliki ĝin: sudo ufw --dry-run route allow in on tun0 out on lan0 from 10.77.0.0/24 to 192.168.60.0/24. Poste reviziu la ordon de la uzantreguloj, ĉar pli frua rifuzo ankoraŭ venkas pli postan permeson. Permeso por la tuta subreto ankaŭ estas malĝusta formo kiam nur la HTTPS-pordo de unu gastiganto devas esti atingebla.

Rimarku kion faras la eniga forĵeto: tunelklientoj ne povas atingi iun servon sur la enirejo mem, inkluzive DNS-aŭskultanton ligitan al ĝia LAN-adreso. Gastigi DNS tie postulas intencan escepton antaŭ la forĵeto kaj reviziitan permeskontrakton. Se UFW administras IPv6, aldonu kongruajn forĵetojn por tun0 en before6.rules ankaŭ, ĉar IPv4-cela listo diras nenion pri IPv6-paketoj.

Kontrolu la ŝarĝitan politikon, ne la antaŭrigardon

Antaŭrigardu la reŝargon, apliku ĝin en prizorga fenestro, kaj legu la vivan regularon.

sudo ufw --dry-run reload
sudo ufw show raw

Konfirmu ke la tunelgardistoj aperas antaŭ la implicitaj statpermesoj kaj ICMP-permesoj. Ordinara ufw status ne montras permane redaktitajn before-regulojn, pro kio operatoroj konkludas ke regulo mankas kiam ĝi fakte estas ŝarĝita. Legu la krudan liston de supre malsupren anstataŭ serĉi fragmenton. Se la gardistoj aperas post statpermeso, la limo ne faras tion kion la dosiero sugestas.

Poste testu konduton anstataŭ tekston. Malfermu freŝan konekton al permesita gastiganto kaj observu la respondon, direktu sendanĝeran peton al celo ekster la subreto kaj konfirmu ke ĝi mortas, provu samtavolan konekton, provu servon lokan al la enirejo, kaj provu nepetitan LAN-al-klientan konekton. Inkluzivu unu eksteran trafikon kiu ekzistis antaŭ la ŝanĝo, kaj viŝu nur tiun trafikon anstataŭ malplenigi la tutan spurtabelon de la maŝino.

Notu la limojn apud la reguloj: ĉi tio limigas transiton kaj nenion alian. Ĝi ne malhelpas klienton uzi sian propran interretan konekton, ne malhelpas permesitan LAN-gastiganton plusendi trafikon plu, kaj ne anstataŭigas aŭtentikigon ene de la permesitaj servoj.