Правила на защитната стена само за NEW не затварят всеки път през WAN
Отхвърлянето на NEW връзки оставя установените потоци и отговорите непокътнати. Прочетете състоянието в conntrack, реда на правилата и изключенията, преди да наречете дадена политика затворена.
Отхвърлянето на нови изходящи връзки по WAN изглежда като политика на затворен отказ, но е по-тясно обещание, отколкото изглежда. Пакетите, принадлежащи на вече съществуващи потоци, не ѝ съответстват, както и много отговори. Тази празнина лесно се пропуска, защото правилото се чете така, сякаш покрива интерфейса, а не едно състояние на връзката върху него. А четенето на съвпадението по състояние като присъда поражда фалшиво усещане за затвореност.
Състоянието е условие за съвпадение, не присъда
Проследяването на връзки класифицира пакетите по това, което защитната стена вече е видяла, а не по това, което приложението смята. Поток, наблюдаван в двете посоки, е установен и следващите му пакети остават установени, дори когато маршрутът под него се смени от тунел към обичайната изходяща линия. Отговор на входяща връзка също може да е установен трафик. Тези пакети никога не стават отново нови.
Затова правило, ограничено до нови връзки, не може да докаже, че всеки защитен пакет е блокиран. То оставя другите състояния на каквото друго прави наборът от правила с тях, което може да е разрешение, поставено по-рано във веригата.
Четете правилото в неговата среда
Широко разрешение за установен и свързан трафик, поставено преди блокирането, пропуска пакет, преди блокирането изобщо да бъде оценено. Премахването на условието за състояние от по-късно правило няма да промени това, защото оценката никога не стига до него. Редът решава изхода, а съвпадението по състояние решава кои пакети стигат до въпросния ред.
Прегледайте действащия набор от правила, а не файла, който сте редактирали, включително преходите към други вериги и всичко, което платформата генерира. На маршрутизатор, управляван от iptables, изброяването на веригата показва дефинициите на правилата и веригите, към които сочи, също трябва да бъдат проследени. Нативната система с nftables изисква преглед на собствения набор от правила и приоритетите на куките, тъй като фърмуерът рядко генерира идентични вериги.
Броячите показват кое правило действително е съвпаднало и обикновено са по-информативни от снемане на пакети, направено след решението. Правило с нулев брояч не е достигнато, каквото и да подсказва позицията му.
Изразете забраната независимо от състоянието
Ако група клиенти никога не бива да достига интернет извън тунела, кажете го директно, вместо да го приближавате с едно състояние. Правилото трябва да избира по източник, изход и дестинация, без да зависи от състоянието на връзката, и трябва да стои там, където никое по-ранно разрешение не може да го заобиколи. Тогава административният достъп и изключенията за локалната мрежа получават свои изрични правила и намерението става видимо в политиката.
Изборът на reject вместо drop променя как се проваля съвпадащият трафик и не разширява набора от пакети, които правилото избира. Отказана връзка и тихо изчакване са различни симптоми, сочещи към един и същ избор.
Политика, която умишлено разрешава отговори на отдалечено иницииран достъп през WAN, е защитима. Просто трябва да бъде описана точно така, а не представена като пълна изолация само през тунела.
Проверете кой всъщност е в групата
Примерът обхваща препратен трафик IPv4 от един префикс през един интерфейс. Той не казва нищо за IPv6, втора изходяща линия или трафик, който самият маршрутизатор генерира. Маршрутизатор, който действа като DNS резолвер, изпраща собствените си заявки нагоре и те изобщо не минават през веригата forward.
Потвърдете, че защитените клиенти все още имат адреси в избрания префикс, защото устройство, излязло извън него, е директно по случайност, а не по политика. Разширяването на блокирането към цялата LAN без преглед на дизайна на изключенията също е склонно да премахне собствения ви административен път.
iptables -S FORWARD
iptables -L FORWARD -v -n
cat /proc/net/nf_conntrack | grep -c ESTABLISHED
След това изпробвайте стар поток до нов. Нов опит за връзка и вече активен двупосочен трансфер се държат различно под това правило и само проверката и на двете показва каква политика имате в действителност.