Promjena pravila vatrozida ne radi: redoslijed pravila i stanje veze
Izmijenjeno pravilo može stajati iza ranijeg dopuštanja ili ga praćenje veza može preskočiti. Razdvojite dva testa, upotrijebite nov tok i zadržite put natrag.
Uredili ste pravilo, ponovno učitali skup pravila, a tunel se ponaša točno kao prije. Taj ishod ima dva česta uzroka i oni traže različite testove. Ili novo pravilo stoji iza ranijeg pravila koje je već prihvatilo paket, ili je razmjena koju promatrate praćena veza koju promjena nikada ne vrednuje ponovno. Pravilo u datoteci izražava namjeru; o sudbini paketa odlučuje aktivni put na koji naiđe. Prođite provjere u nastavku redom i pritom držite otvoren put natrag.
Redoslijed pravila i stanje veze dvije su različite greške
Uređeni lanci vrednuju se odozgo prema dolje i prvo pravilo koje dođe do konačne presude završava prolaz kroz taj lanac. Umetnite široko dopuštanje iznad pažljivo napisanog pravila za zaključavanje i to pravilo postaje dokumentacija: ono je u skupu pravila, brojač mu je nula i nijedan paket ga nikada neće dosegnuti. Isti tekst primijenjen na drugi lanac također ništa ne dokazuje. U nftablesu se osnovni lanci pričvršćuju na kuke s prioritetima, pa dopuštanje u jednom lancu ne sprječava drugi lanac na drugoj kuki ili prioritetu da vidi isti paket.
Praćenje veza stvara drugi simptom i izvana izgleda jednako. Kad je tok u tablici stanja, dopuštanje za uspostavljene ili povezane pri vrhu lanca vraća se prije nego što se vaše novo pravilo uopće razmotri. NAT preslikavanja imaju isto svojstvo: prijevod je bio fiksiran kad je tok počeo, pa izmijenjeno pravilo u postroutingu ne prepisuje sesiju koja već radi. Zato promjena izgleda da radi u 09:00 za novu vezu, a izgleda da ne radi ništa za sesiju koju je netko otvorio u 08:55.
Cloud sigurnosne grupe dodaju treći model koji hvata ljude koji su učili na iptablesu. Njihova ulazna pravila popis su dopuštenja koji se vrednuje kao skup, a ne kao prolaz po prvom podudaranju, ona čuvaju stanje i uklanjanje pravila dopuštenja ne prekida tokove koji se već prate. Pretpostavka semantike prvog podudaranja na platformi koja je nema vodi do uvjerenih, pogrešnih zaključaka.
Čitajte aktivni skup pravila, a ne datoteku koju ste uredili
Počnite s onim što jezgra primjenjuje upravo sada. Spremljena konfiguracija koja nikada nije primijenjena objašnjava iznenađujuće mnogo nepromijenjenih ponašanja i isključivanje košta jednu naredbu:
nft list ruleset
iptables-saveZatim pitajte doseže li se vaše pravilo uopće. Brojači paketa odgovaraju izravno i odgovaraju bolje od bilo kakvog razmišljanja o namjeri:
iptables -L FORWARD -v -n --line-numbers
nft list chain inet filter forwardPravilo za zaključavanje s nula paketa nakon stvarnog pokušaja testa nije problem politike, nego problem položaja. Premještanje je promjena u jednom retku, a sintaksa je upravo ono što je uzrokovalo izvornu grešku. S iptablesom -I umeće, a -A dodaje na kraj; s nftablesom insert stavlja pravilo na početak lanca, a add dodaje na kraj. Kad pravilo mora pobijediti, recite to izričito umjesto da vjerujete redoslijedu koji se slučajno učitao.
Dokažite prati li se tok
Prije nego okrivite pravilo, provjerite je li promet uopće praćena veza. Pitajte tablicu stanja za konkretan tok umjesto da je cijelu izlijevate:
conntrack -L -p tcp --dport 1194
conntrack -E -p tcp --dport 1194Ispis pokazuje stanje i preostali rok i tako razlikujete uspostavljenu sesiju od novog pokušaja; način događaja ispisuje ažuriranja dok se događaju, što je korisno dok ponovno povezujete klijenta. Ako je tok prisutan s uspostavljenim stanjem prije nego što ste išta dotakli, nijedna izmjena filtarskih pravila neće promijeniti njegovu sudbinu. To nije greška u vatrozidu, to je ugovor filtriranja sa stanjem.
Oduprite se prečici pražnjenja cijele tablice na produkcjskom pristupniku. conntrack -F je dostupno i ono uništava i svaki praćeni tok na stroju, uključujući upravljačku sesiju iz koje radite i tunel koji nosi vašu ljusku. Pojedinačni unosi mogu se brisati kad stvarno trebate, ali nov tok s novog izvornog porta obično je čišći eksperiment.
Neki putovi se ne prate i oni se ponašaju obrnuto. Promet označen s notrack u tablici raw, neki tuneli koji zaobilaze uobičajene kuke i asimetrično usmjeravanje koje dijeli tok između dva pristupnika svi daju pakete koji se vrednuju jedan po jedan ili stanje koje se nikada ne stvara na oba kraja. Ako se brojači pomiču za svaki paket, sumnjajte na takav put prije nego na redoslijed.
Testirajte iz novog toka s putem natrag
Prije nego testirate pravilo koje može odrezati daljinski pristup, uspostavite put oporavka: konzolu pružatelja, serijsku konzolu, izvanpojasnu adresu upravljanja ili drugo sučelje koje pravilo ne može pogoditi. Vremenski ograničeno vraćanje razuman je pratilac jer će vratiti prethodni skup pravila čak i ako vaša sesija umre usred testa.
Zatim testirajte razmjenom koju stanje nije već moglo pokriti. Odspojite i ponovno spojite klijenta da se stvori nova petorka i promatrajte oba kraja dok se to događa:
tcpdump -ni eth0 'tcp port 1194'
journalctl -k -n 50 --no-pagerProvedite test u oba smjera. Pravilo koje blokira novo dolazno rukovanje još može dopuštati put odgovora ili obrnuto, a jednosmjeran rezultat uobičajen je razlog zašto zaključavanje radi napola. Ponovno se spojite nakon testa da potvrdite stabilno stanje i provjerite je li legitimni pristup upravljanju preživio; pravilo napisano za jedan port ima naviku podudarati se sa širim rasponom no što je namjeravano.
Zabilježite svrhu i položaj uz pravilo
Pravilo bez zabilježene svrhe pravilo je koje se nitko ne usudi ukloniti. Uz svaki zapis za zaključavanje držite tok koji štiti, lanac i kuku u kojoj živi, položaj koji mora držati prema širim dopuštenjima i test koji ga je dokazao. Kad netko za šest mjeseci uredi okolni skup pravila, ta je bilješka jedino upozorenje da je položaj bio namjeran.
Prije nego zatvorite promjenu, potvrdite četiri stvari: aktivni skup pravila odgovara datoteci, novo pravilo ima brojače različite od nule nakon svježeg pokušaja, obrnuti smjer i pristup upravljanju još rade i jednom ste se ponovno spojili da dokažete stabilno stanje, a ne stanje sesije starije od promjene. Ako bilo što od toga nije provjereno, promjena nije završena, što god tunel radio.