Hindi gumagana ang pagbabago sa firewall rule: pagkakasunod-sunod ng mga rule at estado ng koneksyon

In-edit mo ang rule, ni-reload ang set ng mga rule, at ganoon pa rin ang kilos ng tunnel tulad ng dati. May dalawang karaniwang dahilan ang resultang ito, at kailangan nila ng magkaibang pagsubok. Maaaring ang bagong rule ay pagkatapos ng naunang rule na tumanggap na sa packet, o ang palitan na sinusubaybayan mo ay isang sinusubaybayang koneksyon na hindi muling sinusuri ng pagbabago. Ang rule sa isang file ay nagpapahayag ng layunin; ang nagpapasya sa packet ay ang aktibong landas na nakakasalubong nito. Dumaan sa mga pagsusuring nasa ibaba nang sunod-sunod, at habang ginagawa ito ay panatilihing bukas ang daan pabalik.

Ang pagkakasunod-sunod ng rule at estado ng koneksyon ay magkaibang sira

Ang mga nakaayos na chain ay sinusuri mula itaas pababa, at ang unang rule na umabot sa huling hatol ang nagtatapos sa pagdaan sa chain na iyon. Maglagay ng malawak na pagtanggap sa itaas ng maingat na naisulat na lockdown rule, at ang lockdown rule ay nagiging dokumentasyon: nasa set ito, sero ang counter nito, at walang packet na makakarating dito kahit kailan. Ang parehong teksto na inilapat sa ibang chain ay wala ring pinapatunayan. Sa nftables, ang mga base chain ay nakakabit sa mga hook ayon sa prayoridad, kaya ang pagtanggap sa isang chain ay hindi pumipigil sa ibang chain sa ibang hook o prayoridad na makita ang parehong packet.

Ang pagsubaybay sa koneksyon ay gumagawa ng ikalawang sintomas, at mula sa labas ay mukhang pareho ito. Kapag ang isang daloy ay nasa talahanayan ng estado, ang pagtanggap para sa established-or-related malapit sa tuktok ng chain ay bumabalik bago pa man isaalang-alang ang bago mong rule. Ang mga NAT mapping ay may parehong katangian: ang pagsasalin ay itinakda noong nagsimula ang daloy, kaya ang na-edit na postrouting rule ay hindi nagsusulat muli ng session na tumatakbo na. Ito ang dahilan kung bakit ang pagbabago ay tila gumagana sa 09:00 para sa bagong koneksyon at tila walang ginagawa para sa session na binuksan ng isang tao sa 08:55.

Ang mga cloud security group ay nagdadagdag ng ikatlong modelo na humuhuli sa mga natuto sa iptables. Ang kanilang inbound rule ay listahan ng pahintulot na sinusuri bilang set at hindi bilang pagdaan sa unang tugma, may estado sila, at ang pag-alis ng rule ng pahintulot ay hindi nagtatapos sa mga daloy na sinusubaybayan na. Ang pagpapalagay ng semantika ng unang tugma sa isang plataporma na wala nito ay humahantong sa tiwala ngunit maling konklusyon.

Basahin ang aktibong set ng rule, hindi ang file na in-edit mo

Magsimula sa kung ano ang ipinapatupad ng kernel ngayon. Ang naka-save na configuration na hindi kailanman inilapat ay nagpapaliwanag ng nakakagulat na dami ng hindi nagbabagong pag-uugali, at ang pagbubukod dito ay isang utos lamang:

nft list ruleset
iptables-save

Pagkatapos ay itanong kung naaabot ba ang rule mo. Ang mga counter ng packet ay direktang sumasagot diyan, at mas mahusay silang sumagot kaysa sa anumang pangangatwiran tungkol sa layunin:

iptables -L FORWARD -v -n --line-numbers
nft list chain inet filter forward

Ang lockdown rule na may sero packet pagkatapos ng tunay na pagsubok ay hindi problema sa patakaran, problema ito sa posisyon. Ang paglipat nito ay isang linyang pagbabago, at ang sintaks ay eksaktong dahilan ng orihinal na bug. Sa iptables, -I ay naglalagay sa unahan at -A ay nagdadagdag sa dulo; sa nftables, insert ay naglalagay ng rule sa simula ng chain habang add ay nagdadagdag sa dulo. Kapag kailangang manalo ng isang rule, sabihin ito nang malinaw sa halip na umasa sa pagkakasunod-sunod na nagkataong na-load.

Patunayan kung sinusubaybayan ang daloy

Bago sisihin ang rule, tingnan kung ang trapiko ay talagang sinusubaybayang koneksyon. Itanong sa talahanayan ng estado ang partikular na daloy sa halip na ibuhos ito lahat:

conntrack -L -p tcp --dport 1194
conntrack -E -p tcp --dport 1194

Ipinapakita ng listahan ang estado at natitirang timeout, at sa ganoong paraan mo nakikilala ang matatag nang session mula sa bagong pagtatangka; ang mode ng kaganapan ay naglilimbag ng mga update habang nangyayari, na kapaki-pakinabang habang muling kinokonekta mo ang isang client. Kung ang daloy ay naroroon na sa matatag na estado bago mo hawakan ang kahit ano, walang pag-edit sa mga filter rule ang magbabago sa kapalaran nito. Hindi ito bug sa firewall, ito ang kontrata ng stateful filtering.

Labanan ang shortcut na buhusan ang buong talahanayan sa isang production gateway. conntrack -F ay magagamit, at wawasakin din nito ang bawat sinusubaybayang daloy sa makina, kasama ang management session na pinagtatrabahuhan mo at ang tunnel na nagdadala ng shell mo. Ang mga indibidwal na entry ay maaaring tanggalin kapag talagang kailangan mo, ngunit ang bagong daloy mula sa bagong source port ay karaniwang mas malinis na eksperimento.

Ang ilang landas ay hindi sinusubaybayan, at kumikilos sila nang kabaligtaran. Ang trapikong minarkahan bilang notrack sa talahanayang raw, ang ilang tunnel na lumalampas sa mga normal na hook at ang asymmetric routing na naghahati ng daloy sa dalawang gateway ay gumagawa ng mga packet na sinusuri nang isa-isa, o estado na hindi kailanman nabubuo sa magkabilang dulo. Kung gumagalaw ang mga counter sa bawat packet, hinala ang ganitong landas bago hinala ang pagkakasunod-sunod.

Subukan mula sa bagong daloy na may daan pabalik

Bago subukan ang isang rule na maaaring pumutol ng remote access, magtatag ng daan ng pagbangon: console ng provider, serial console, out-of-band management address, o ikalawang interface na hindi matugma ng rule. Ang rollback timer ay makatwirang kasama, dahil ibabalik nito ang dating set ng rule kahit mamatay ang session mo sa gitna ng pagsubok.

Pagkatapos ay subukan sa isang palitan na hindi pa kayang saklawin ng estado. Idiskonekta at ikonekta muli ang client upang makabuo ng bagong limang-upla, at panoorin ang magkabilang dulo habang nangyayari ito:

tcpdump -ni eth0 'tcp port 1194'
journalctl -k -n 50 --no-pager

Isagawa ang pagsubok sa dalawang direksyon. Ang rule na humaharang sa bagong inbound handshake ay maaari pa ring payagan ang landas ng sagot, o kabaligtaran, at ang resultang isang-direksyon ang karaniwang dahilan kung bakit kalahati lang gumagana ang lock. Kumonekta muli pagkatapos ng pagsubok upang kumpirmahin ang matatag na estado, at tingnan kung nakaligtas ang lehitimong management access; ang rule na isinulat para sa isang port ay may ugali na tumugma sa mas malawak na saklaw kaysa nilayon.

Itala ang layunin at posisyon kasama ang rule

Ang rule na walang naitalang layunin ay rule na walang nangangahas na tanggalin. Sa tabi ng bawat lockdown entry, itago ang daloy na pinoprotektahan nito, ang chain at hook kung saan ito nakatira, ang posisyon na dapat nitong hawakan kaugnay ng mas malawak na pagtanggap, at ang pagsubok na nagpatunay nito. Kapag may nag-edit sa nakapaligid na set ng rule makalipas ang anim na buwan, ang tala na iyon ang tanging babala na sinadya ang posisyon.

Bago isara ang pagbabago, kumpirmahin ang apat na bagay: tumutugma ang tumatakbong set ng rule sa file, ang bagong rule ay may counter na hindi sero pagkatapos ng bagong pagtatangka, gumagana pa rin ang kabaligtarang direksyon at management access, at nakakonekta kang muli nang isang beses upang patunayan ang matatag na estado at hindi ang estado ng session na mas luma kaysa sa pagbabago. Kung may hindi na-verify sa mga ito, hindi pa tapos ang pagbabago, anuman ang ginagawa ng tunnel.