Palomuurisäännön muutos ei toimi: sääntöjen järjestys ja yhteyden tila

Muokkasit sääntöä, latasit sääntökokoelman uudelleen, ja tunneli käyttäytyy täsmälleen kuten ennenkin. Tällä tuloksella on kaksi tavallista syytä, ja ne vaativat erilaiset testit. Joko uusi sääntö on aiemman säännön jälkeen, joka on jo hyväksynyt paketin, tai tarkkailemasi vaihto on seurattu yhteys, jota muutos ei koskaan arvioi uudelleen. Tiedostossa oleva sääntö ilmaisee aikomuksen; paketin kohtalosta päättää aktiivinen polku, jonka se kohtaa. Käy alla olevat tarkistukset läpi järjestyksessä ja pidä samalla paluutie auki.

Sääntöjen järjestys ja yhteyden tila ovat eri vikoja

Järjestetyt ketjut arvioidaan ylhäältä alas, ja ensimmäinen sääntö, joka päätyy lopulliseen ratkaisuun, lopettaa kulun kyseisessä ketjussa. Aseta laaja hyväksyntä huolellisesti kirjoitetun lukitussäännön yläpuolelle, ja lukitussäännöstä tulee dokumentaatiota: se on sääntökokoelmassa, sen laskuri on nolla, eikä yksikään paketti koskaan saavuta sitä. Sama teksti toiseen ketjuun sovellettuna ei todista mitään. Nftablesissa perusketjut kiinnittyvät koukkuihin prioriteeteilla, joten yhden ketjun hyväksyntä ei estä toista ketjua toisella koukulla tai prioriteetilla näkemästä samaa pakettia.

Yhteyksien seuranta tuottaa toisen oireen, ja ulkopuolelta se näyttää identtiseltä. Kun virta on tilataulukossa, ketjun yläpään lähellä oleva established-or-related-hyväksyntä palaa ennen kuin uutta sääntöäsi edes tarkastellaan. NAT-kartoituksilla on sama ominaisuus: käännös kiinnitettiin virran alkaessa, joten muokattu postrouting-sääntö ei kirjoita uudelleen jo käynnissä olevaa istuntoa. Siksi muutos näyttää toimivan kello 09:00 uuden yhteyden kohdalla ja näyttää tekevän ei mitään istunnolle, jonka joku avasi kello 08:55.

Pilven suojausryhmät lisäävät kolmannen mallin, joka nappaa iptablesin opetelleet. Niiden saapuvat säännöt ovat sallittujen lista, joka arvioidaan joukkona eikä ensimmäisen osuman kuluna, ne ovat tilallisia, eikä sallintasäännön poistaminen lopeta virtoja, joita jo seurataan. Ensimmäisen osuman semantiikan olettaminen alustalla, jolla sitä ei ole, johtaa itsevarmoihin, vääriin johtopäätöksiin.

Lue aktiivinen sääntökokoelma, älä muokkaamaasi tiedostoa

Aloita siitä, mitä ydin parhaillaan toteuttaa. Tallennettu kokoonpano, jota ei koskaan sovellettu, selittää hämmästyttävän monta muuttumatonta käyttäytymistä, ja sen poissulkeminen maksaa yhden komennon:

nft list ruleset
iptables-save

Kysy sitten, saavutetaanko sääntösi ylipäätään. Pakettilaskurit vastaavat siihen suoraan ja vastaavat paremmin kuin mikään aikomuksesta käyty päättely:

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

Lukitussääntö, jolla on nolla pakettia todellisen testiyrityksen jälkeen, ei ole politiikkaongelma vaan sijaintiongelma. Sen siirtäminen on yhden rivin muutos, ja syntaksi on täsmälleen se, mikä aiheutti alkuperäisen virheen. Iptablesilla -I lisää alkuun ja -A lisää loppuun; nftablesilla insert sijoittaa säännön ketjun alkuun, kun taas add lisää loppuun. Kun säännön on pakko voittaa, sano se suoraan sen sijaan että luottaisit järjestykseen, joka sattui latautumaan.

Todista, seurataanko virtaa

Ennen kuin syytät sääntöä, tarkista, onko liikenne ylipäätään seurattu yhteys. Kysy tilataulukolta tiettyä virtaa sen sijaan että tyhjentäisit sen kokonaan:

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

Listaus näyttää tilan ja jäljellä olevan aikakatkaisun, ja niin erotat vakiintuneen istunnon tuoreesta yrityksestä; tapahtumatila tulostaa päivitykset sitä mukaa kun ne tapahtuvat, mikä on hyödyllistä kun yhdistät asiakasta uudelleen. Jos virta on vakiintuneessa tilassa jo ennen kuin koskit mihinkään, mikään suodatinsääntöjen muokkaus ei muuta sen kohtaloa. Tämä ei ole palomuurin vika, se on tilallisen suodatuksen sopimus.

Vastusta kiusausta tyhjentää koko taulukko tuotantoyhdyskäytävässä. conntrack -F on saatavilla, ja se tuhoaa myös jokaisen seuratun virran koneella, mukaan lukien hallintaistunnon, josta työskentelet, ja tunnelin, joka kuljettaa kuortasi. Yksittäisiä merkintöjä voi poistaa, kun todella tarvitset, mutta tuore virta uudesta lähdeportista on yleensä puhtaampi koe.

Joitakin polkuja ei seurata, ja ne käyttäytyvät päinvastoin. Liikenne, joka on merkitty notrack raw-taulukossa, jotkin tunnelit, jotka ohittavat tavalliset koukut, ja epäsymmetrinen reititys, joka jakaa virran kahden yhdyskäytävän kesken, tuottavat kaikki paketteja, jotka arvioidaan yksi kerrallaan, tai tilan, jota ei koskaan synny kummassakaan päässä. Jos laskurit liikkuvat jokaisen paketin kohdalla, epäile sellaista polkua ennen kuin epäilet järjestystä.

Testaa tuoreesta virrasta paluutien kanssa

Ennen kuin testaat sääntöä, joka voisi katkaista etäkäytön, luo palautumispolku: palveluntarjoajan konsoli, sarjakonsoli, kaistan ulkopuolinen hallintaosoite tai toinen liitäntä, johon sääntö ei voi osua. Peruutusajastin on järkevä kumppani, koska se palauttaa edellisen sääntökokoelman vaikka istuntosi kuolisi kesken testin.

Testaa sitten vaihdolla, jota tila ei olisi voinut jo kattaa. Irrota ja yhdistä asiakas uudelleen, jotta muodostuu uusi viisikko, ja seuraa molempia päitä sen tapahtuessa:

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

Suorita testi molempiin suuntiin. Sääntö, joka estää uuden saapuvan kättelyn, voi silti sallia vastauspolun tai päinvastoin, ja yksisuuntainen tulos on tavallinen syy siihen, että lukitus toimii puoliksi. Yhdistä vielä kerran testin jälkeen vahvistaaksesi vakaan tilan ja tarkista, että laillinen hallintayhteys säilyi; yhdelle portille kirjoitetulla säännöllä on tapana osua aiottua laajempaan alueeseen.

Kirjaa tarkoitus ja sijainti säännön yhteyteen

Sääntö ilman kirjattua tarkoitusta on sääntö, jota kukaan ei uskalla poistaa. Pidä jokaisen lukitusmerkinnän rinnalla virta, jota se suojaa, ketju ja koukku, jossa se elää, sijainti, joka sen on pidettävä laajempiin hyväksyntöihin nähden, ja testi, joka sen todisti. Kun joku muokkaa ympäröivää sääntökokoelmaa kuuden kuukauden päästä, se muistiinpano on ainoa varoitus siitä, että sijainti oli tarkoituksellinen.

Ennen kuin suljet muutoksen, vahvista neljä asiaa: käynnissä oleva sääntökokoelma vastaa tiedostoa, uudella säännöllä on nollasta poikkeavat laskurit tuoreen yrityksen jälkeen, vastasuunta ja hallintayhteys toimivat edelleen, ja olet yhdistänyt kerran uudelleen todistaaksesi vakaan tilan etkä muutosta vanhemman istunnon tilaa. Jos jokin näistä on vahvistamatta, muutos ei ole valmis, mitä ikinä tunneli tekeekään.