Fajroŝirmilaj reguloj nur por NEW ne fermas ĉiun WAN-vojon

Rifuzi novajn elirajn konektojn sur la WAN aspektas kiel fermita politiko, sed ĝi estas pli mallarĝa promeso ol ĝi ŝajnas. Paketoj apartenantaj al fluoj jam ekzistantaj ne kongruas kun ĝi, kaj same multaj respondoj. La manko estas facile preteratentebla, ĉar la regulo legeblas kvazaŭ ĝi kovrus la interfacon anstataŭ unu konektostaton sur ĝi. Kaj legi la statan kongruon kiel verdikton estas tio, kio kreas falsan senton de fermiteco.

Stato estas kongrua kondiĉo, ne verdikto

Konekta spurado klasifikas paketojn laŭ tio, kion la fajroŝirmilo jam vidis, ne laŭ tio, kion la aplikaĵo kredas. Fluo observata en ambaŭ direktoj estas establita, kaj ĝiaj postaj paketoj restas establitaj eĉ kiam la vojo sub ĝi ŝanĝiĝas de tunelo al la ordinara suprenligo. Respondo al envenanta konekto ankaŭ povas esti establita trafiko. Tiuj paketoj neniam denove fariĝas novaj.

Tial regulo limigita al novaj konektoj ne povas pruvi, ke ĉiu protektita paketo estas blokita. Ĝi lasas la aliajn statojn al tio, kion la resto de la regularo faras kun ili, kio povas esti permeso lokita pli frue en la ĉeno.

Legu la regulon en ĝia ĉirkaŭaĵo

Vasta permeso por establita kaj rilata trafiko lokita antaŭ la bloko ellasas paketon antaŭ ol la bloko entute taksiĝas. Forigi la statan kondiĉon el posta regulo tion ne ŝanĝos, ĉar la taksado neniam atingas ĝin. Ordo decidas la rezulton, kaj la stata kongruo decidas, kiuj paketoj atingas tiun ordon.

Ekzamenu la efikan regularon anstataŭ la dosieron, kiun vi redaktis, inkluzive saltojn en aliajn ĉenojn kaj ĉion, kion la platformo generas. Sur iptables-administrata enkursigilo, listigo de la ĉeno montras la regulajn difinojn, kaj la ĉenojn, al kiuj ĝi referencas, ankaŭ endas spuri. Denaska nftables-sistemo bezonas ekzamenon de sia propra regularo kaj de ĝiaj hokaj prioritatoj, ĉar firmvaro malofte generas identajn ĉenojn.

Nombriloj montras, kiu regulo efektive kongruis, kaj ili kutime pli informas ol paketa kapto prenita post la decido. Regulo kun nula nombrilo ne estis atingita, kion ajn ĝia pozicio sugestas.

Esprimu la malpermeson sendepende de stato

Se grupo de klientoj neniam rajtas atingi la interreton ekster la tunelo, diru tion rekte anstataŭ proksimumigi ĝin per unu stato. La regulo devas elekti laŭ fonto, eliro kaj celo sen dependi de konektostato, kaj ĝi devas stari tie, kie neniu pli frua permeso povas preteriri ĝin. Tiam administra aliro kaj lokretaj esceptoj ricevos proprajn eksplicitajn regulojn, do la intenco videblos en la politiko.

Elekti reject anstataŭ drop ŝanĝas kiel malsukcesas la kongrua trafiko, kaj ĝi ne pligrandigas la aron de paketoj, kiujn la regulo elektas. Rifuzita konekto kaj silenta tempolimo estas malsamaj simptomoj montrantaj al la sama elekto.

Politiko, kiu intence permesas respondojn al distance iniciatita aliro tra la WAN, estas defendebla. Ĝi simple devas esti priskribita tiel, anstataŭ prezentiĝi kiel totala izolado nur per la tunelo.

Kontrolu, kiu efektive estas en la grupo

La ekzemplo kovras plusenditan IPv4-trafikon el unu prefikso tra unu interfaco. Ĝi diras nenion pri IPv6, dua suprenligo, aŭ trafiko, kiun la enkursigilo mem originas. Enkursigilo aganta kiel DNS-rizolvilo sendas siajn proprajn suprajn demandojn, kaj tiuj tute ne pasas tra la forward-ĉeno.

Konfirmu, ke la protektitaj klientoj ankoraŭ havas adresojn ene de la elektita prefikso, ĉar aparato, kiu moviĝis ekster ĝin, estas rekta hazarde, ne laŭ politiko. Larĝigi la blokon al la tuta LAN sen revizii la esceptan dezajnon ankaŭ emas forigi vian propran administran vojon.

iptables -S FORWARD
iptables -L FORWARD -v -n
cat /proc/net/nf_conntrack | grep -c ESTABLISHED

Poste provu malnovan fluon apud nova. Freŝa konektoprovo kaj jam aktiva dudirekta transigo kondutas malsame sub ĉi tiu regulo, kaj nur testado de ambaŭ montras, kiun politikon vi vere havas.