Tinklo filtro taisyklės tik NEW neuždaro visų WAN kelių

Naujų išeinančių jungčių atmetimas WAN tinkle atrodo kaip politika, kuri užsidaro esant klaidai, tačiau tai siauresnis pažadas, nei atrodo. Paketai, priklausantys jau esamiems srautams, jai neatitinka, ir daugelis atsakymų taip pat. Šį tarpą lengva praleisti, nes taisyklė skaitoma taip, tarsi ji apimtų sąsają, o ne vieną jungties būseną joje. O būsenos atitikimo skaitymas kaip nuosprendžio ir sukuria klaidingą uždarumo jausmą.

Būsena yra atitikimo sąlyga, o ne nuosprendis

Jungčių sekimas klasifikuoja paketus pagal tai, ką ugniasienė jau matė, o ne pagal tai, ką mano programa. Srautas, stebimas abiem kryptimis, yra nustatytas, ir jo vėlesni paketai lieka nustatyti net tada, kai maršrutas po juo pasikeičia iš tunelio į įprastą išėjimo liniją. Atsakymas į įeinančią jungtį taip pat gali būti nustatytas srautas. Tie paketai niekada vėl netampa nauji.

Todėl taisyklė, apribota naujomis jungtimis, negali įrodyti, kad kiekvienas apsaugotas paketas blokuojamas. Ji palieka kitas būsenas tam, ką su jomis daro likusi taisyklių visuma, o tai gali būti leidimas, įdėtas anksčiau grandinėje.

Skaitykite taisyklę jos aplinkoje

Platus leidimas nustatytam ir susijusiam srautui, įdėtas prieš blokavimą, praleidžia paketą anksčiau, nei blokavimas apskritai įvertinamas. Būsenos sąlygos pašalinimas iš vėlesnės taisyklės to nepakeis, nes vertinimas jos niekada nepasiekia. Rezultatą lemia tvarka, o tai, kurie paketai pasiekia tą tvarką, lemia būsenos atitikimas.

Tikrinkite veikiančią taisyklių visumą, o ne failą, kurį redagavote, įskaitant šuolius į kitas grandines ir viską, ką generuoja platforma. Maršrutizatoriuje, valdomame iptables, grandinės išvardijimas parodo taisyklių apibrėžimus, o grandines, į kurias ji nurodo, taip pat reikia sekti. Vietinė nftables sistema reikalauja patikrinti savo taisyklių visumą ir kabliukų prioritetus, nes programinė įranga retai generuoja identiškas grandines.

Skaitikliai parodo, kuri taisyklė iš tikrųjų atitiko, ir paprastai jie informatyvesni už paketų įrašymą, atliktą po sprendimo. Taisyklė su nuliniu skaitikliu nebuvo pasiekta, ką bebūtų galima spręsti iš jos padėties.

Išreikškite draudimą nepriklausomai nuo būsenos

Jei klientų grupė niekada neturi pasiekti interneto už tunelio ribų, pasakykite tai tiesiogiai, o ne apytikriai viena būsena. Taisyklė turi atrinkti pagal šaltinį, išėjimą ir paskirties vietą nepriklausomai nuo jungties būsenos ir turi stovėti ten, kur joks ankstesnis leidimas negali jos apeiti. Tada valdymo prieiga ir vietinio tinklo išimtys gauna savo aiškias taisykles, todėl ketinimas matomas politikoje.

Pasirinkus reject vietoj drop, keičiasi tai, kaip nepavyksta atitinkantis srautas, ir tai nepadidina paketų, kuriuos taisyklė atrenka, aibės. Atmesta jungtis ir tylus laukimo laikas yra skirtingi simptomai, rodantys į tą patį pasirinkimą.

Politika, kuri sąmoningai leidžia atsakymus į nuotoliniu būdu pradėtą prieigą per WAN, yra apginama. Tiesiog ją reikia taip apibūdinti, o ne pateikti kaip visišką izoliaciją vien tik per tunelį.

Patikrinkite, kas iš tikrųjų yra grupėje

Pavyzdys apima persiunčiamą IPv4 srautą iš vieno prefikso per vieną sąsają. Jis nieko nesako apie IPv6, antrą išėjimo liniją ar srautą, kurį sukuria pats maršrutizatorius. Maršrutizatorius, veikiantis kaip DNS sprendėjas, siunčia savo užklausas į viršų, ir jos visai neina per forward grandinę.

Patvirtinkite, kad apsaugoti klientai vis dar turi adresus pasirinktame prefikse, nes įrenginys, kuris iš jo išsikėlė, yra tiesioginis atsitiktinai, o ne pagal politiką. Blokavimo išplėtimas visam LAN neperžiūrėjus išimčių dizaino taip pat linkęs pašalinti jūsų pačių administravimo kelią.

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

Tada išbandykite seną srautą šalia naujo. Naujas jungties bandymas ir jau aktyvus dvikryptis perdavimas elgiasi skirtingai pagal šią taisyklę, ir tik abiejų išbandymas parodo, kokią politiką iš tikrųjų turite.