Blokku unu celan gamon por ĉiu VPN-klienta baseno

Unu regulo povas teni akceptitan VPN-basenon for de cela gamo sen ĝeni ion alian, kion la enirejo faras. La regulo mem estas mallonga; la partoj, kiuj decidas ĉu ĝi funkcias, estas la hoko, en kiu ĝi loĝas, kaj ĝia pozicio en la ĉeno. Se vi maltrafas tiujn du, vi ricevas fajroŝirmilon, kiu aspektas ĝusta kaj kondutas sin malkonsekvence. Komencu de tio, kion la pakaĵo faras, kiam la regulo vidas ĝin.

Kion la regulo efektive kongruas

La regulo kongruas tri aferojn samtempe: enigan interfacon, fontan prefikson kaj celan prefikson. Ĉiuj tri devas esti veraj antaŭ ol la drop aplikiĝas, kaj tio tenas ĝin mallarĝa. Legi ĝin kiel unu esprimon estas pli facile ol legi ĝin kiel tri apartajn politikojn.

La interfaca kongruo estas tio, kio distingas plusenditan klientan trafikon de la propraj konektoj de la enirejo. Sen ĝi, regulo nomanta nur la fontan basenon ankaŭ tuŝus pakaĵojn, kiujn la enirejo mem generas el tiu adreso, se ĝi iam faras tion. La fonta prefikso limigas la politikon al akceptitaj klientoj, kaj la cela prefikso limigas ĝin al unu gamo. Legu la regulon kiel komunaĵon, ne kiel liston.

Skribu la tri valorojn antaŭ ol redakti ion ajn: la nomon de la tunela interfaco, la basenon, kiun la servilo disdonas, kaj la prefikson, kiun vi intencas rifuzi. Tajperaro en iu ajn el ili produktas regulon, kiu parseblas pure kaj protektas nenion. Konservu tiujn tri valorojn en la ŝanĝprotokolo apud la regulo.

La hoko decidas, al kiu la regulo aplikiĝas

netfilter-ĉeno estas alkroĉita al hoko, kaj la hoko decidas, kiujn pakaĵojn la ĉeno iam ajn vidas. La hoko forward vidas trafikon enkursigitan tra la enirejo, kaj tio estas ĝuste la trafiko de kliento al celo. Ĉio alia en la ĉeno celas alian publikon.

La hoko input vidas trafikon adresitan al la enirejo mem, do regulo metita tie regas aliron al ĝiaj propraj servoj anstataŭ trairon. La hoko output vidas trafikon, kiun la enirejo mem originas, kio estas la malo de tio, kion bezonas klientbasena politiko. Ĉennomoj estas arbitraj etikedoj elektitaj de tiu, kiu skribis la regularon, do ne deduktu la hokon el la nomo. Kontrolu, kie la ĉeno estas alkroĉita, antaŭ ol supozi, kion ĝi povas kongrui.

Legi la alkroĉon estas unulinia kontrolo, kiu malhelpas regulon surteriĝi en ĉeno, kiu neniam vidas la pakaĵon.

Metu la regulon antaŭ la larĝa akcepto

Reguloj estas taksataj laŭvice, kaj la unua verdikto venkas. Larĝa akcepto pli frue en la ĉeno finas la taksadon por la pakaĵoj, kiujn ĝi kongruas, do drop aldonita poste neniam ruliĝas por ili. Tiu ordiga regulo estas la tuta kialo, kial ĝustaspekta regulo povas havi neniun efikon.

Enmetu la regulon antaŭ la akcepto anstataŭ aldoni ĝin ĉe la fino. Se la ĉeno jam enhavas ĝeneralan akcepton por la tunela interfaco, la nova regulo devas antaŭi ĝin, alie ĝi estas nur ornama. Kontrolu la rezultan ordon, ne la dosieron, kiun vi redaktis, ĉar regularo kunmetita el pluraj dosieroj eble ne kongruas kun iu unu el ili. Poste konfirmu per testa pakaĵo el la baseno.

sudo nft list chain inet filter forward
sudo nft insert rule inet filter forward iifname "tun0" ip saddr 10.90.0.0/24 ip daddr 198.51.100.0/24 drop
sudo nft -c -f /etc/nftables.conf

La tria komando parses la dosieron sen apliki ĝin, kio kaptas sintaksajn erarojn antaŭ ol ili fariĝu interrompo. Apliku kun replana plano, ĉar erara regulo en forward-ĉeno povas tranĉi la tunelon, super kiu vi laboras.

Ekzistantaj fluoj ne zorgas pri via nova regulo

conntrack-enskribo kreita antaŭ ol la regulo ekzistis daŭre kongruas la pli fruan akcepton. Tial nova drop foje ŝajnas funkcii por freŝaj konektoj kaj fari nenion por tiu, kiu estas testata.

Legu la statan kongruon ĉe la supro de la ĉeno. Se ĝi akceptas established kaj related trafikon antaŭ via regulo, ĉiu jam fluanta fluo daŭre fluas ĝis ĝi fermiĝas. Tio kutime estas la konduto, kiun vi volas por urĝa regulo, kaj ĝi konfuzas, kiam vi atendas tujan tranĉon. Decidu, kiun efikon vi volas, antaŭ ol disloki. Testo, kiu reuzas malfermitan konekton, rakontos al vi malĝustan historion.

sudo conntrack -L -s 10.90.0.14 -d 198.51.100.20
sudo nft list ruleset | grep -n -A3 'ct state'

La unua komando montras, ĉu fluo ekzistas, kaj la dua montras, ĉu frua stata regulo daŭre akceptas ĝin. Ambaŭ estas nurlegaj kaj sekuraj dum incidento.

Kio ĉi tiu regulo ne estas

La regulo ne estas domajna nigra listo, IPv6-politiko, nek limigo de unuopa aplikaĵa konto.

Ĉiu el tiuj bezonas sian propran mekanismon. Domajna blokado devas solvi nomojn, kion pakaĵa filtrilo ne faras. IPv6-trafiko bezonas sian propran kongruon, ĉar esprimo ip diras nenion pri ip6-pakaĵoj. Limigo je aplikaĵa nivelo apartenas al la servo aŭ al aŭtentigita prokuro, ne al prefiksa kongruo. Teni tiujn postulojn apartaj estas tio, kio malhelpas peti de unu mallarĝa regulo kvar taskojn.

La kontrakto, kiun ĉi tiu regulo liveras, estas preciza: trafiko de akceptita baseno al unu cela prefikso estas rifuzata, dum nerilata enireja trafiko konservas sian ekzistantan politikon. Skribu tiun frazon apud la regulo, kaj la sekva persono scios, por kio ĝi estis.