Endring av brannmurregel verkar ikkje: regelrekkjefølgje og tilkoplingsstatus

Du redigerte regelen, lasta regelsettet på nytt, og tunnelen oppfører seg nøyaktig som før. Det resultatet har to vanlege årsaker, og dei krev ulike testar. Anten ligg den nye regelen etter ein tidlegare regel som allereie har godteke pakken, eller så er utvekslinga du ser på ei spora tilkopling som endringa aldri vurderer på nytt. Ein regel i ei fil uttrykkjer hensikt; det som avgjer pakken, er den aktive vegen han møter. Gå gjennom kontrollane nedanfor i rekkjefølgje, og hald ein veg tilbake medan du gjer det.

Regelrekkjefølgje og tilkoplingsstatus er ulike feil

Ordna kjeder blir vurderte ovanfrå og ned, og den første regelen som når eit endeleg vedtak, avsluttar gjennomgangen av den kjeda. Set ei brei godkjenning over ein nøye skriven låseregel, og låseregelen blir dokumentasjon: han står i regelsettet, teljaren er null, og ingen pakke vil nokon gong nå han. Den same teksten brukt på ei anna kjede provar heller ikkje noko. I nftables blir grunnkjeder feste til krokar etter prioriteringar, så ei godkjenning i éi kjede hindrar ikkje ei anna kjede på ein annan krok eller prioritering i å sjå den same pakken.

Tilkoplingssporing gir det andre symptomet, og utanfrå ser det identisk ut. Når ein flyt først er i tilstandstabellen, returnerer ei godkjenning for etablert-eller-relatert nær toppen av kjeda før den nye regelen din i det heile blir konsultert. NAT-mappingar har same eigenskap: omsetjinga vart fastsett då flyten starta, så ein redigert postrouting-regel skriv ikkje om ei økt som allereie køyrer. Derfor ser ei endring ut til å verke kl. 09:00 for ei ny tilkopling og ser ut til å gjere ingenting for økta nokon opna kl. 08:55.

Skysikkerheitsgrupper legg til ein tredje modell som fangar folk som lærte på iptables. Innkommande reglar er ei tillatingsliste som blir vurdert som eit sett i staden for ein gjennomgang etter første treff, dei er stateful, og å fjerne ein tillatingsregel avsluttar ikkje flytar som allereie blir spora. Å anta første-treff-semantikk på ein plattform som ikkje har han, fører til sjølvsikre, gale slutningar.

Les det aktive regelsettet, ikkje fila du redigerte

Byrja med det kjernen handhevar akkurat no. Ein lagra konfigurasjon som aldri vart brukt, forklarar overraskande mange uendra åtferder, og det kostar éin kommando å utelukke han:

nft list ruleset
iptables-save

Spør så om regelen din i det heile blir nådd. Pakketeljarar svarar direkte på det, og dei svarar betre enn noko resonnement om hensikt:

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

Ein låseregel med null pakkar etter eit reelt testforsøk er ikkje eit politikkproblem, det er eit posisjonsproblem. Å flytte han er ei endring på éi linje, og syntaksen er nøyaktig det som årsaka den opphavlege feilen. Med iptables -I set inn, og -A legg til på slutten; med nftables insert plasserer ein regel i starten av kjeda medan add legg til på slutten. Når ein regel må vinne, sei det eksplisitt i staden for å stole på rekkjefølgja som tilfeldigvis vart lasta.

Prov om flyten blir spora

Før du klandrar regelen, sjekk om trafikken i det heile er ei spora tilkopling. Spør tilstandstabellen om den konkrete flyten i staden for å dumpe heile:

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

Lista viser tilstanden og gjenståande tidsavbrot, og slik skil du ei etablert økt frå eit ferskt forsøk; hendingsmodus skriv ut oppdateringar etter kvart som dei skjer, noko som er nyttig medan du koplar til ein klient på nytt. Viss flyten er til stades med etablert tilstand før du rørte noko, vil inga endring av filterreglane endre lagnaden hans. Det er ikkje ein feil i brannmuren, det er kontrakten for stateful filtrering.

Motstå snarvegen med å tømme heile tabellen på ein produksjonsgateway. conntrack -F er tilgjengeleg, og det øydelegg òg kvar spora flyt på maskinen, inkludert administrasjonsøkta du arbeider frå og tunnelen som ber skalet ditt. Enkeltoppføringar kan slettast når du verkeleg treng det, men ein fersk flyt frå ein ny kjeldeport er vanlegvis eit reinare eksperiment.

Nokre vegar blir ikkje spora, og dei oppfører seg motsett. Trafikk merkt notrack i raw-tabellen, nokre tunnelar som går utanom dei vanlege krokane, og asymmetrisk ruting som deler ein flyt mellom to gatewayar gir alle pakkar som blir vurderte éin om gongen, eller tilstand som aldri blir oppretta i begge endar. Viss teljarane flyttar seg for kvar pakke, mistenk den slags veg før du mistenk rekkjefølgja.

Test frå ein fersk flyt med ein veg tilbake

Før du testar ein regel som kan kutte fjernåtkomst, etabler ein gjenopprettingsveg: konsollen til leverandøren, ein seriell konsoll, ei administrasjonsadresse utanfor bandet eller eit andre grensesnitt som regelen ikkje kan treffe. Ein tilbakerullingstimar er ein rimeleg følgjesvein, sidan han gjenopprettar det førre regelsettet sjølv om økta di døyr midt i testen.

Test deretter med ei utveksling som tilstanden ikkje allereie kunne ha dekt. Kople frå og kople til klienten på nytt slik at ein ny femling blir oppretta, og følg med på begge endar medan det skjer:

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

Køyr testen i begge retningar. Ein regel som blokkerer den nye innkommande handtrykket, kan framleis tillate svarvegen, eller omvendt, og eit einvegs resultat er den vanlege grunnen til at ein lås berre verkar halvvegs. Kople til på nytt éin gong etter testen for å stadfeste den stabile tilstanden, og kontroller at legitim administrasjonstilgang overlevde; ein regel skriven for éin port har for vane å treffe eit breiare område enn tenkt.

Noter formål og posisjon saman med regelen

Ein regel utan eit notert formål er ein regel ingen tør fjerne. Ved kvar låseoppføring held du flyten han vernar, kjeda og kroken han lever i, posisjonen han må halde overfor breiare godkjenningar, og testen som prova det. Når nokon redigerer det omkringliggjande regelsettet seks månader seinare, er den nota den einaste åtvaringa om at posisjonen var medviten.

Før du lukkar endringa, stadfest fire ting: det køyrande regelsettet samsvarar med fila, den nye regelen har teljarar ulike null etter eit ferskt forsøk, motsett retning og administrasjonstilgang verkar framleis, og du har kopla til på nytt éin gong for å prove den stabile tilstanden i staden for tilstanden til ei økt som er eldre enn endringa. Viss noko av dette er ustadfesta, er endringa ikkje ferdig, same kva tunnelen gjer.